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.
Jakub
