Re: A proposal to align GCC stack

[rridge at csclub dot uwaterloo dot ca (Ross Ridge)]

Ye, Joey writes:
>i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386
>and 64 for x86_64. It is the minimum stack boundary. It is fixed.

Strictly speaking by the above definition it would be 8 for i386.
The hardware doesn't force the stack to be 32-bit aligned, it just
performs poorly if it isn't.

>v. INCOMING_STACK_BOUNDARY in bits, which is the stack boundary
>at function entry. If a function is marked with __attribute__
>((force_align_arg_pointer)) or -mstackrealign option is provided,
>INCOMING = STACK_BOUNDARY.  Otherwise, INCOMING == MIN(ABI_STACK_BOUNDARY,
>PREFERRED_STACK_BOUNDARY) because a function can be called via psABI
>externally or called locally with PREFERRED_STACK_BOUNDARY.

This section doesn't make sense to me.  The force_align_arg_pointer
attribute and -mstackrealign assume that the ABI is being
followed, while the -fpreferred-stack-boundary option effectively
changes the ABI.  According your defintions, I would think
that INCOMING should be ABI_STACK_BOUNDARY in the first case,
and MAX(ABI_STACK_BOUNDARY, PREFERRED_STACK_BOUNDARY) in the second.
(Or just PREFERRED_STACK_BOUNDARY because a boundary less than the ABI's
should be rejected during command line processing.)

>vi. REQUIRED_STACK_ALIGNMENT in bits, which is stack alignment required
>by local variables and calling other function. REQUIRED_STACK_ALIGNMENT
>== MAX(LOCAL_STACK_BOUNDARY,PREFERRED_STACK_BOUNDARY) in case of a
>non-leaf function. For a leaf function, REQUIRED_STACK_ALIGNMENT ==
>LOCAL_STACK_BOUNDARY.

Hmm... I think you should define STACK_BOUNDARY as the minimum
alignment that ABI requires the stack pointer to keep at all times.
ABI_STACK_BOUNDARY should be defined as the stack alignment the
ABI requires at function entry.  In that case a leaf function's
REQUIRED_STACK_ALIGMENT should be MAX(LOCAL_STACK_BOUNDARY,
STACK_BOUNDARY).

>Because I386 PIC requires BX as GOT pointer and I386 may use AX, DX
>and CX as parameter passing registers, there are limited candidates for
>this proposal to choose. Current proposal suggests EDI, because it won't
>conflict with i386 PIC or regparm.

Could you pick a call-clobbered register in cases where one is availale?

>//  Reserve two stack slots and save return address 
>//  and previous frame pointer into them. By
>//  pointing new ebp to them, we build a pseudo 
>//  stack for unwinding

Hmmm... I don't know much about the DWARF unwind information, but
couldn't it handle this case without creating the "pseudo frame"?
Or at least be extended so it could?

					Ross Ridge