Re: [PATCH] Look at restrict disambiguation in tree-ssa-alias.c unconditionally (PR tree-optimization/50522)

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Sep 26, 2011 at 05:50:40PM +0200, Jakub Jelinek wrote:
> On Mon, Sep 26, 2011 at 04:56:20PM +0200, Richard Guenther wrote:
> > Let's see what kind of fallout we get ;)  For example, if the
> > following is valid C code I expect we will vectorize the second
> > loop (disambiguating p[i] and q[i]) bogously:
> > 
> > void foo (int *p)
> > {    
> >   int * __restrict p1 = p;
> >   int * __restrict p2 = p + 32;
> >   int *q;
> >   int i;
> >   for (i = 0; i < 32; ++i)
> >     p1[i] = p2[i];
> >   p = p1;
> >   q = p2 - 31;
> >   for (i = 0; i < 32; ++i)
> >     p[i] = q[i];
> > }
> > 
> > because p and q base on different restrict qualified pointers
> > (p1 and p2 respective).  At the moment we are safe from this
> > because of the TYPE_RESTRICT checks.
> > 
> > Any opinion on the above?  Is it valid to base non-restrict
> > pointers on restrict ones?  It would be sort-of weird at least,
> > but at least I don't think the first loop use is bogus (even
> > though the pointed-to objects are the same).
> 
> based on p1.  In the above testcase all modifications are made through
> lvalues whose addresses are p1 based though, so it is less clear.

I think I've missed the by any means there.  For
int a[64];
foo (a);

In the above function with this e.g. a[4] object is modified during
the extecution of the foo block B, thus the 6.7.3.1/4 rules should apply.
And within that block a[4] is accessed through lvalues whose address
is p1 based as well as through lvalues whose address is not p1 based
(is p2 based), therefore it is invalid.

	Jakub