* bug in aliasing
@ 2001-10-10 15:56 reza
2001-10-10 17:06 ` Richard Henderson
0 siblings, 1 reply; 2+ messages in thread
From: reza @ 2001-10-10 15:56 UTC (permalink / raw)
To: gcc; +Cc: Reza Yazdani
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: bug in aliasing
2001-10-10 15:56 bug in aliasing reza
@ 2001-10-10 17:06 ` Richard Henderson
0 siblings, 0 replies; 2+ messages in thread
From: Richard Henderson @ 2001-10-10 17:06 UTC (permalink / raw)
To: reza; +Cc: gcc
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~
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2001-10-10 17:06 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-10-10 15:56 bug in aliasing reza
2001-10-10 17:06 ` Richard Henderson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).