bug in aliasing

bug in aliasing

[reza]

It seems gcc does not move an invariant local array element out of the 
loop. In the following test "str[2]" is
not moved out of the loop. I went through the interference analysis 
routines and it seems it assumes a store
into any stack variable (m1 array in this case) will interfere with all 
variables allocated on stack,  such as str
in this case.

I was going to find a solution for this problem, but I thought I  would 
ask the experts in the community before I take
a shot at it.

Thanks
Reza Yazdani

Apple Computer


void test()
{
   int str[27];
   int m1[100];
   int k3=0;
   int i;

     for(i='A';i<'Z';i++)
     {
       m1[k3++]=str[2];
     }
}

The assembly code is:

.text
         .align 2
         .globl _test
_test:
         li r2,25
         stwu r1,-560(r1)
         mtctr r2
         li r11,0
         addi r10,r1,144
L9:
         lwz r3,40(r1)       <-- loop invariant
         slwi r2,r11,2
         addi r11,r11,1
         stwx r3,r10,r2
         bdnz L9
         addi r1,r1,560
         blr

Re: bug in aliasing

[Richard Henderson]

On Wed, Oct 10, 2001 at 03:57:56PM -0700, reza@apple.com wrote:
> I went through the interference analysis 
> routines and it seems it assumes a store
> into any stack variable (m1 array in this case) will interfere with all 
> variables allocated on stack,

Not quite.  It assumes that a _varying_ store to a stack varaible
may interfere with another stack variable.  This is because we 
don't track individual stack objects this far into compilation,
so we can't tell that these two references are to different arrays.

Thus this is not a bug, but rather something that the current code
is not expected to handle.

Richard Kenner is doing work that will allow us to get at the 
original VAR_DECL from within these optimization passes.  At which
point we can notice that "m1" != "str".  I don't recall how far
along he is with this work.


r~