This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: nightmares with biased stack pointers
- To: "David S. Miller" <davem at jenolan dot rutgers dot edu>
- Subject: Re: nightmares with biased stack pointers
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 15 Sep 1997 01:01:41 -0600
- cc: egcs at cygnus dot com
- Reply-To: law at cygnus dot com
In message <199709140245.WAA13369@jenolan.rutgers.edu>you write:
> Interesting problem; what would happen if you declared the stack
> was unaligned, and made sure in the backend prologue/epilogue
> routines (and parameter passing) to make sure that you always made
> frames that were multiples of the old alignment?
>
> I'm not sure that I follow.
Set STACK_BOUNDARY to 8 bits, which effectively describes what you know
about the alignment of "sp" -- ie nothing.
This is likely to have some undesirable effects; namely parameters might
not be put in the right spots in memory and frames created in prologues
might not keep the stack aligned properly, so you'd have to go back
and play with the macros & code which control this stuff.
> The issue is that GCC lacks knowledge of this peculiar property of the
> value in the %sp register, so it has no reason to not perform those
> optimizations during combine. What I was thinking was to provide some
> way for GCC to perform the optimization still, because it really can,
> yet correctly.
Exactly. Hence the suggestion to change STACK_BOUNDARY to disable these
optimizations -- with the consequence that you might have to fix other
parts of the sparc port.
Another way might be to emit some suitably complex and ugly rtl when
allocating dynamic space so that the combiner doesn't optimize important
stuff away. Kinda gross, but another approach if STACK_BOUNDARY doesn't work.
> Really the issue on sparc64 is that it is "%sp + STACK_BIAS" which has
> known alignment properties, not "%sp" all by itself.
Exactly.
jeff