nightmares with biased stack pointers

[Jeffrey A Law]

  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