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

[Richard Guenther <rguenther at suse dot de>]

On Tue, 4 Oct 2011, Jakub Jelinek wrote:

> On Tue, Oct 04, 2011 at 11:01:27AM +0200, Richard Guenther wrote:
> > > > > 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];
> > > > > }
> > > > > 
> 
> > In the above first loop the restrict pointers p1 and p2 access
> > distinct object pieces.  The second loop uses non-restrict qualified
> > pointers p and q (that are based on the restrict variants p1 and p2
> > though) to access overlapping pieces.  Is the second loop invalid
> > because p and q are based on p1 and p2 even though they are not
> > restrict qualified?
> 
> IMHO yes.  The standard doesn't seem to talk about the accesses being done
> through the restricted pointer, but about accesses that are based on
> the restricted pointer, and as soon as you access in the associated block
> (here the foo function) some object through an lvalue whose address is
> based on some restricted pointer and the value is modified by any means,
> then all accesses to that object need to be done through something
> based on that restricted pointer.

So when I change the above to

 /*p = p;*/
 q = (p + 32) - 31;

then the code will be valid?  When I obfuscate that enough I
can get GCC CSEing p + 32 and thus effectively q will look
like it is based on p2.

Richard.