Ross Ridge wrote:
> 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.
H.J. Lu writes:
> That is how we get into trouble in the first place. The only place I
> think of where you can guarantee everything is compiled with the same
> -fpreferrred-stack-boundary is kernel. Our proposal will align stack
> only when needed. PREFERRED_STACK_BOUNDARY > ABI_STACK_BOUNDARY will
> generate a largr stack unnecessarily.
I'm currently using -fpreferred-stack-boundary without any trouble.
Your proposal would in fact generate code to align stack when it's not
necessary. This would change the behaviour of -fpreferred-stack-boundary,
hurting performance and that's unacceptable to me.
>> 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).
>
> On x86-64, ABI_STACK_BOUNDARY is 16byte, but the Linux kernel may
> want to use 8 byte for PREFERRED_STACK_BOUNDARY. INCOMING will
> be MIN(STACK_BOUNDARY, PREFERRED_STACK_BOUNDARY) == 8 byte.
Using MAX(STACK_BOUNDARY, PREFERRED_STACK_BOUNDARY) also equals 8 in that
case and preserves the behaviour -fpreferred-stack-boundary in every case.
Ross Ridge
