Re: A proposal to align GCC stack

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

Ross Ridge writes:
> 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

"H.J. Lu" <hjl at lucon dot org> writes
> According to Apple engineer who implemented the -mstackrealign,
> on MacOS/ia32, psABI is 16byte, but -mstackrealign will assume
> 4byte, which is STACK_BOUNDARY.

Ok.  The importanting thing is that for backwards compatibility it needs
to continue to assume 4-byte alignment on entry and align the stack to
a 16-byte alignment on x86 targets, so that makes more sense.

>> 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.
>
> That isn't true since some .o files may not be compiled with
> -fpreferred-stack-boundary or with a different value of
> -fpreferred-stack-boundary.

Like with any ABI changing flag, that's not supported:

	... Further, every function must be generated such that it keeps
	the stack aligned.  Thus calling a function compiled with a higher
	preferred stack boundary from a function compiled with a lower
	preferred stack boundary will most likely misalign the stack.

The -fpreferrred-stack-boundary flag currently generates code that
assumes the stack aligned to the preferred alignment on function entry.
If you assume a worse incoming alignment you'll be aligning the stack
unnecessarily and generating code that this flag doesn't require.

> On x86-64, ABI_STACK_BOUNDARY is 16byte, but the Linux kernel may
> want to use 8 byte for PREFERRED_STACK_BOUNDARY.

Ok, if people are using this flag to change the alignment to something
smaller than used by the standard ABI, then INCOMING should be
MAX(STACK_BOUNDARY, PREFERRED_STACK_BOUNDARY).

					Ross Ridge