> > >>> 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.
Hi, I have been trying to use ranger as requested. I've tried: gimple_ranger ranger; int_range_max r; /* Check that no overflow will occur. If we don't have range information we can't perform the optimization. */ if (ranger.range_of_expr (r, oprnd0, stmt)) { wide_int max = r.upper_bound (); .... Which works for non-patterns, but still doesn't work for patterns. On a stmt: patt_27 = (_3) w+ (level_15(D)); it gives me a range: $2 = { <wide_int_storage> = { val = {[0x0] = 0xffffffffffffffff, [0x1] = 0x7fff95bd8b00, [0x2] = 0x7fff95bd78b0, [0x3] = 0x3fa1dd0, [0x4] = 0x3fa1dd0, [0x5] = 0x344a706f832d4f00, [0x6] = 0x7fff95bd7950, [0x7] = 0x1ae7f11, [0x8] = 0x7fff95bd79f8}, len = 0x1, precision = 0x10 }, members of generic_wide_int<wide_int_storage>: static is_sign_extended = 0x1 } The precision is fine, but range seems to be -1? Should I use range_op_handler (WIDEN_PLUS_EXPR, ...) in this case? Thanks, Tamar > > Thanks, > Tamar > > > > > Andrew > > > >