RE: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask by using new optabs [PR108583]

[Tamar Christina <Tamar.Christina@arm.com>]

> -----Original Message-----
> From: Andrew MacLeod <amacleod@redhat.com>
> Sent: Friday, February 10, 2023 8:59 PM
> To: Richard Biener <rguenther@suse.de>; Richard Sandiford
> <Richard.Sandiford@arm.com>
> Cc: Tamar Christina <Tamar.Christina@arm.com>; Tamar Christina via Gcc-
> patches <gcc-patches@gcc.gnu.org>; nd <nd@arm.com>;
> jlaw@ventanamicro.com
> Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of div-bitmask
> by using new optabs [PR108583]
> 
> 
> On 2/10/23 13:34, Richard Biener wrote:
> >
> >>> In any case, if you disagree I don’t' really see a way forward aside
> >>> from making this its own pattern running it before the overwidening
> pattern.
> >> I think we should look to see if ranger can be persuaded to provide
> >> the range of the 16-bit addition, even though the statement that
> >> produces it isn't part of a BB.  It shouldn't matter that the
> >> addition originally came from a 32-bit one: the range follows
> >> directly from the ranges of the operands (i.e. the fact that the
> >> operands are the results of widening conversions).
> > I think you can ask ranger on operations on names defined in the IL,
> > so you can work yourself through the sequence of operations in the
> > pattern sequence to compute ranges on their defs (and possibly even
> > store them in the SSA info).  You just need to pick the correct ranger
> > API for this…. Andrew CCed
> >
> >
> Its not clear to me whats being asked...
> 
> Expressions don't need to be in the IL to do range calculations.. I believe we
> support arbitrary tree expressions via range_of_expr.
> 
> if you have 32 bit ranges that you want to do 16 bit addition on, you can also
> cast those ranges to a 16bit type,
> 
> my32bitrange.cast (my16bittype);
> 
> then invoke range-ops directly via getting the handler:
> 
> handler = range_op_handler (PLUS_EXPR, 16bittype_tree); if (handler)
>     handler->fold (result, my16bittype, mycasted32bitrange,
> myothercasted32bitrange)
> 
> There are higher level APIs if what you have on hand is closer to IL than
> random ranges
> 
> Describe exactly what it is you want to do... and I'll try to direct you to the
> best way to do it.

The vectorizer has  a pattern matcher that runs at startup on the scalar code.
This pattern matcher can replace one or more statements with alternative ones,
these can be either existing tree_code or new internal functions.

One of the patterns here is a overwidening detection pattern which reduces the
precision that an operation is to be done in during vectorization.

Another one is widening multiplication, which replaced PLUS_EXPR with WIDEN_PLUS_EXPR.

These can be chained, so e.g. a widening addition done on ints can be reduced to a widen addition
done on shorts.

The question is whether given the new expression that the vectorizer has
created whether ranger can tell what the precision is.  get_range_query fails because presumably
it has no idea about the new operations created
 and also doesn't know about any new IFNs.

Thanks,
Tamar

> 
> Andrew
> 
>