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.
Ross Ridge wrote:
>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.
Robert Dewar writes:
>First, although for some types, the accesses may work, the optimizer
>is allowed to assume that data is properly aligned, and could possibly
>generate incorrect code ...
That's not enforced by hardware.
>Second, I am pretty sure there are SSE types that require
>alignment at the hardware levell, even on the i386
This isn't a restriction on stack aligment. It's a restriction on what
kinds of machine types can be accessed on the stack.
As I mentioned later in my message STACK_BOUNDARY shouldn't be defined in
terms of hardware, but in terms of the ABI. While the i386 allows the
stack pointer to bet set to any value, by convention the stack pointer
is always kept 4-byte aligned at all times. GCC should never generate
code that that would violate this requirement, even in leaf-functions
or transitorily during the prologue/epilogue.
This is different than the proposed ABI_STACK_BOUNDARY macro which defines
the possibily stricter aligment the ABI requires at function entry. Since
most i386 ABIs don't require a stricter alignment, that has ment that
SSE types couldn't be located on the stack. Currently you can get around
this problem by changing the ABI using -fperferred-stack-boundary or by
forcing an SSE compatible alignment using -mstackrealign or __attribute__
((force_align_arg_pointer)). Joey Ye's proposal is another solution
to this problem where GCC would automatically force an SSE compatible
aligment when SSE types are used on the stack.
Ross Ridge
