[lno] tree loop optimization causes a problem in RTL alias analysis
Mostafa Hagog
MUSTAFA@il.ibm.com
Mon May 10 13:58:00 GMT 2004
Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> wrote on 09/05/2004
17:52:52:
> Hello,
>
> > We have encountered a problem when the -ftree-loop-optimize flag is
> > specified. The problem causes bad schedules due to unnecessary memory
> > dependences. We compiled the below code example, and compared memory
> > attributes in the RTL with and without -ftree-loop-optimize. It turned
> > out that when -ftree-loop-optimize was enabled the memory attributes
> > (MEM_EXPR) were lost.
> >
> > int a[128];
> > int b[128];
> >
> > void f ()
> > {
> > int i;
> > for (i = 0; i < 128; i++)
> > a[i] = b[i];
> > }
> >
> > We used powerpc-apple-darwin7.2.0 with the following compiler flags:
> > "-O3 -ftree-loop-optimize -funroll-loops"
> > "-O3 -fno-tree-loop-optimize -funroll-loops"
> >
> > The following code from alias.c uses that information, and cannot
> > proceed if that information is not present:
>
> the problem (I think) is that the code above is strength-reduced to
>
> int *p, *q;
>
> p = a;
> q = b;
> for (i = 0; i < 128; i++)
> *p++ = *q++;
>
> Which does not contain the aliasing information accessible on rtl level.
> By a coincidence, I am just testing a patch that should fix the problem.
>
> Zdenek
I am not sure that this is the problem. Because in a different test case
where the arrays type is char alias.c gets a correct MEM_EXPR and generates
correct alias information. Following is the example I used:
char a[128];
char b[128];
void f ()
{
int i;
for (i = 0; i < 128; i++)
a[i] = b[i];
}
Mostafa
More information about the Gcc
mailing list