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
