nightmares with biased stack pointers

[Joern Rennecke]

> 
>   In message < 199709131024.GAA10195@jenolan.rutgers.edu >you write:
>   > The problem is that sparc64 is the only target which has whats called
>   > a 'biased' stack pointer.  %sp really doesn't point to the stack, it
>   > points to the stack minus 2,047 bytes.
> 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.
> 
>   > (STACK_BIAS is the aforementioned 2047 byte bias %sp has,
>   >  FIRST_PARM_OFFSET is a known aligned offset from that frame)
>   > 
>   > That code is correct and unoptimized.  If I turn on any optimizations,
>   > the combiner looks at that and determines something along these lines:
>   > 
>   > 1) Hey, I know how %sp must be aligned
>   > 2) Hey look, two redundant addition instructions, combine 'em
>   > 3) Hey look, taking into account the known alignment of the stack
>   >    frame and the "add sp, const, reg; srlx 4; sllx 4;" sequence,
>   >    I can determine that this is really an alignment of the 'constant'
>   >    so I can merge this into a constant operation and blow the two
>   >    shifts away.
> 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 have another proposal: pretend that the bias is aligned. (e.g. 2048).
It is possible to make a 1:1 mapping of a virtual machine with a
stack bias of N to on with a stack bias of M by changing the representation
for all instructions that refer to the stack pointer.
Adjust GO_IF_LEGITIMATE_ADDRESS that the correct boundaries are used,
and use an add in place of a reg<-> sp move etc.