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]

Re: nightmares with biased stack pointers


   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


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