This is the mail archive of the
mailing list for the GCC project.
EABI stack alignment for ppc
- From: Olivier Hainque <hainque at adacore dot com>
- To: gcc at gcc dot gnu dot org
- Cc: hainque at adacore dot com
- Date: Tue, 26 Apr 2005 15:24:49 +0200
- Subject: EABI stack alignment for ppc
PPC EABI targets are currently configured with both BIGGEST_ALIGNMENT and
PREFERRED_STACK_BOUNDARY set to 128, I believe to accomodate
"a long double member within a structure or union shall start at the lowest
available offset aligned on a 16byte boundary"
Besides, for 32bit non-altivec targets, we have 64 for STACK_BOUNDARY.
There is code in expand_main_function to force the stack pointer alignment to
PREFERRED_STACK_BOUNDARY in such situations, not triggered for C like
languages on those targets because FORCE_PREFERRED_STACK_BOUNDARY_IN_MAIN is
not defined (maybe it should, btw).
We apply this dynamic re-alignment to every subprogram with foreign convention
in Ada, still, because alignment requests must always be obeyed when not to be
It turns out that the current re-alignment code doesn't work for PPC.
It first 'rounds' the stack pointer in place, and then resorts to
allocate_dynamic_stack_space to "pick up the pieces", as the comment says.
The latter triggers the 'allocate_stack' expander, which copies the back chain
from the current stack pointer, which in turn retrieves garbage when the
initial 'rounding' has had a real effect.
One way of addressing that would be to adjust the re-alignment code so that it
does not touch the stack pointer before calling allocate_dynamic_stack_space.
Now, I'm a bit unclear on the meaning of the ABI statement quoted above, and
on the real implications this should have in the compiler.
Does it imply that a long double field *address* should always be a multiple
of 16, or just that the *offset* should be such a multiple ?
In the latter case, are bumping BIGGEST_ALIGNMENT and PREFERRED_STACK_BOUNDARY
the only options ?
Other thoughts ?
Thanks in advance,