This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [lno] tree loop optimization causes a problem in RTL alias analysis


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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]