[Bug rtl-optimization/91137] [7/8/9/10 Regression] Wrong code with -O3

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91137

--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 15 Jul 2019, amker at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91137
> 
> --- Comment #8 from bin cheng <amker at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #7)
> > On Mon, 15 Jul 2019, amker at gcc dot gnu.org wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91137
> > > 
> > > --- Comment #6 from bin cheng <amker at gcc dot gnu.org> ---
> > > (In reply to Richard Biener from comment #2)
> > > > 
> > > > and I can very well imagine we're getting confused by find_base_term
> > > > logic here.
> > > > 
> > > > There's logic in IVOPTs to not generate IVs based on two different
> > > > objects but somehow it doesn't trigger here.
> > > 
> > > Hmm, it's because determine_base_object failed to identify the `base_object`
> > > for IV because it has non-pointer type:
> > > IV struct:
> > >   SSA_NAME:     _32
> > >   Type: unsigned long
> > >   Base: (unsigned long) &d + 19600
> > >   Step: 4
> > >   Biv:  N
> > >   Overflowness wrto loop niter: Overflow
> > > 
> > > And we have short-circuit in determine_base_object:
> > > 
> > > static tree
> > > determine_base_object (tree expr)
> > > {
> > >   enum tree_code code = TREE_CODE (expr);
> > >   tree base, obj;
> > > 
> > >   /* If this is a pointer casted to any type, we need to determine
> > >      the base object for the pointer; so handle conversions before
> > >      throwing away non-pointer expressions.  */
> > >   if (CONVERT_EXPR_P (expr))
> > >     return determine_base_object (TREE_OPERAND (expr, 0));
> > > 
> > >   if (!POINTER_TYPE_P (TREE_TYPE (expr)))
> > >     return NULL_TREE;
> > > 
> > > The IV is generated from inner loop ivopts as we rewrite using unsigned type.
> > > 
> > > Any suggestion how to fix this?
> > 
> > I think we need to elide this check and make the following code
> > more powerful which includes actually handling PLUS/MINUS_EXPR.
> > There's also ptr + (unsigned)&ptr to be considered for the
> > POINTER_PLUS_EXPR case - thus we cannot simply only search the
> > pointer chain.
> > 
> > Which then leads us into exponential behavior if this is asked
> > on SCEV results which may have tree sharing, thus we need some
> > 'visited' machinery.  In the end I think we should re-do
> Will work on a patch.  One thing I am unclear about is the ptr + (unsigned)&ptr
> stuff, when would we have this? Could you provide an example please?

Can't provide a complete example but maybe sth like

int a,b;
void foo (int *p, int *q)
{
 p += (uintptr_t)&a - (uintptr_t)&b;
 for (; p != q; ++p)
   *p = 1;
}

> > it like I re-did contains_abnormal_ssa_name_p, use
> > walk_tree_without_duplicates.  Btw, what should happen if the
> > walk discovers two bases are used in the expression?
> I guess it depends on why there are multiple bases in the first place?

See above, in reality there's only one base but later on RTL we
lose the distinction between pointers and integers and thus are
easily fooled.