This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: nightmares with biased stack pointers
- To: law at cygnus dot com
- Subject: Re: nightmares with biased stack pointers
- From: "David S. Miller" <davem at jenolan dot rutgers dot edu>
- Date: Sat, 13 Sep 1997 22:45:51 -0400
- CC: egcs at cygnus dot com
Date: Sat, 13 Sep 1997 19:22:26 -0600
From: Jeffrey A Law <law@hurl.cygnus.com>
Weird, but I understand how it could be useful. The mn10300 cpu
handles this slightly differently -- memory references from the
stack pointer are unsigned, thus doubling the the effective memory
referencing range for SP accesses.
Of course SP isn't a general register, so this hackery is pretty
simple.
Interesting.
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.
The real problem is that gcc in these cases cannot distinguish the
difference between:
1) %sp is aligned, and slots relative to %sp are aligned
and
2) %sp is opaque and nothing can be assumed about it, but offsets
calculated from it by the port are aligned (ie. via
STACK_POINTER_OFFSET or similar)
Nearly everything else in the port works fine, it's just this strange
case with dynamic stack space allocations that has the problem.
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.
Something along the lines of:
1) Before aligning a stack pointer offset, subtract offset to base
of stack from (some value similar to, but perhaps not exactly,
STACK_POINTER_OFFSET), if the target has such a thing, from the
offset.
2) Perform constant alignment on resulting value.
3) Add the offset to base back into the aligned constant offset just
calculated.
And use that. Choppy wording, but you get the general idea.
Really the issue on sparc64 is that it is "%sp + STACK_BIAS" which has
known alignment properties, not "%sp" all by itself.
Later,
David "Sparc" Miller
davem@caip.rutgers.edu