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

[Andrew MacLeod <amacleod@redhat.com>]

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.

Andrew