This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Look at restrict disambiguation in tree-ssa-alias.c unconditionally (PR tree-optimization/50522)
- From: Richard Guenther <rguenther at suse dot de>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, gcc-patches at gcc dot gnu dot org, Jason Merrill <jason at redhat dot com>
- Date: Tue, 4 Oct 2011 11:01:27 +0200 (CEST)
- Subject: Re: [PATCH] Look at restrict disambiguation in tree-ssa-alias.c unconditionally (PR tree-optimization/50522)
- References: <20110926144651.GF2687@tyan-ft48-01.lab.bos.redhat.com> <alpine.LNX.2.00.1109261648520.2130@zhemvz.fhfr.qr> <20110926155040.GH2687@tyan-ft48-01.lab.bos.redhat.com> <Pine.LNX.4.64.1109301429370.15173@digraph.polyomino.org.uk>
On Fri, 30 Sep 2011, Joseph S. Myers wrote:
> On Mon, 26 Sep 2011, Jakub Jelinek wrote:
>
> > Hi!
> >
> > Adding Joseph and Jason to CC.
> >
> > 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).
> >
> > If the last loop was
> > for (i = 0; i < 32; i++)
> > q[i] = p[i];
> > then I believe the above would be clearly invalid C99, because
> > an object X (say incoming p[4]) would be modified in the same block
> > using a pointer based on p1 and using a pointer not based on p1
> > (q), which would violate the requirements that if the object is
> > modified through lvalue whose address is based on p1, all modifications
> > to B in that block should be done through lvalues whose address is
> > based on p1. In the above testcase all modifications are made through
> > lvalues whose addresses are p1 based though, so it is less clear.
> > Joseph?
>
> If an object that is accessed by a restricted pointer is also modified,
> then all accesses (not just all modifications) must be through pointers
> based on the restricted pointer. So in the original loop with p[i] =
> q[i], q[i] for i from 0 to 30 is an object that was previously modified
> through p1 and is now being accessed through p2. So this code appears
> invalid to me.
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? Or is the loop ok because p and q are not
restrict qualified?
Thanks,
Richard.
--
Richard Guenther <rguenther@suse.de>
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer