> -----Original Message----- > From: Andrew MacLeod <amacl...@redhat.com> > Sent: Friday, February 10, 2023 8:59 PM > To: Richard Biener <rguent...@suse.de>; Richard Sandiford > <richard.sandif...@arm.com> > Cc: Tamar Christina <tamar.christ...@arm.com>; Tamar Christina via Gcc- > patches <gcc-patches@gcc.gnu.org>; nd <n...@arm.com>; > j...@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 > >
