On Tue, 4 Oct 2011, Jakub Jelinek wrote:
> On Tue, Oct 04, 2011 at 12:17:30PM +0200, Richard Guenther wrote:
> > int *x;
> >
> > > void foo (int *p)
> > > {
> > > int * __restrict p1 = p;
> > > int * __restrict p2 = p + 32;
> > > int *q;
> > > int i;
> > x = p2;
> > > q = p + 32;
> > q = q - 31;
> > > for (i = 0; i < 32; ++i)
> > > p[i] = q[i];
> > > }
>
> Yes, this is valid and so is a modified version of the earlier
> testcase where all accesses in the first loop are biased
> (bar below, assuming y > 32 or y <= -32).
>
> int *x;
>
> void
> foo (int *p)
> {
> int *__restrict p1 = p;
> int *__restrict p2 = p + 32;
> int *q;
> int i;
> x = p2;
> q = p + 32;
> q = q - 31;
> for (i = 0; i < 32; ++i)
> p[i] = q[i];
> }
>
> void
> bar (int *p, int y)
> {
> int *__restrict p1 = p;
> int *__restrict p2 = p + 32;
> int *q;
> int i;
> for (i = 0; i < 32; ++i)
> p1[i + y] = p2[i + y];
> q = (p + 32) - 31;
> for (i = 0; i < 32; ++i)
> p[i] = q[i];
> }
>
> >
> > would be valid and we'd rely on CSE not to replace q = p + 32
> > with q = p2 (ignoring the fact that for a miscompile we need
> > similar tricks for p1). It doesn't do that at the moment
> > because we fold int * __restrict p2 = p + 32 to
> > ((int * __restrict)p) + 32 and thus see
> >
> > p.0_4 = (int * restrict) p_2(D);
> > p2_5 = p.0_4 + 128;
> >
> > vs.
> >
> > q_6 = p_2(D) + 128;
> >
> > but you are going to change that ;)
>
> But even with the "Restrict fixes" patch I've just checked in
> and with the TYPE_RESTRICT check removal patch I don't see anything
> wrong in the IL, the only thing that is PT (restr) is the stmt
> computing p2, which is just stored into x and nothing else, and
> in the second function only the first loop.
But that's by pure luck and not by design, no?
Richard.
