RE: [PATCH][ivopts]: use affine_tree when comparing IVs during candidate selection [PR114932]

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

> -----Original Message-----
> From: Michael Matz <matz@suse.de>
> Sent: Wednesday, June 19, 2024 3:46 PM
> To: Tamar Christina <Tamar.Christina@arm.com>
> Cc: Richard Biener <rguenther@suse.de>; gcc-patches@gcc.gnu.org; nd
> <nd@arm.com>; bin.cheng@linux.alibaba.com
> Subject: RE: [PATCH][ivopts]: use affine_tree when comparing IVs during candidate
> selection [PR114932]
> 
> Hello,
> 
> On Wed, 19 Jun 2024, Tamar Christina wrote:
> 
> > So this is where we compare different IV expressions to determine which
> > IVs compute the same thing and thus can be in the same group.
> >
> > The STRIP_NOPS don't work because while the incoming types are the same
> > the casts are different.  So:
> >
> > >>> p debug (ustep)
> > (unsigned long) stride.3_27 * 4
> > $3 = void
> > >>> p debug (cstep)
> > (unsigned long) (stride.3_27 * 4)
> > $4 = void
> >
> > Which is of course stripped to:
> >
> > >>> p debug (top)
> > (unsigned long) stride.3_27 * 4
> > $1 = void
> > >>> p debug (bot)
> > stride.3_27 * 4
> >
> > Both of these compute the same thing
> 
> In isolation these are _not_ computing the same when strides type is
> smaller than ulong, namely when stride is either negative or larger than
> its max-value/4.  I.e. when comparing IVs not only the overflow behaviour
> for the whole {base,+,step} revolution matters, but also the behaviour on
> the constituent expressions.  (It's possible that stride is known to be
> non-problematic here, I haven't checked.  I was just triggered by the
> claim of same-ness :) )

The only use of this method is to determine whether the two expressions
can possibly be the same.  After this IVops forcibly converts them to an
unsigned type though an affine fold in get_computation_aff_1.

So in the end it doesn't care about the sign and uses them all as unsigned.

Tamar
> 
> 
> Ciao,
> Michael.