This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: x86 stack alignment redux
> I don't think it is a good idea. Please check out Marc's patch.
defining STACK_BOUNDARY should not affect compatibility issues, but
(in pgcc), I found a bug (which I couldn't track down yet), which is
affect by STACK_BOUNDARY==64.. sometimes, combine will optimize
lea 16(%esp),%ebx
addl $4,%ebx
into
lea 16(%esp),%ebx
orb $4,%ebx
when another push is added in the prologue (to save registers), the orb is
no longer valid.
I have no idea wether this is a pgcc.only bug or not, it's still on my list ;)
another problem is that, on machines that have push_insns, gcc/egcs/pgcc will
effectively ignore the bvalue that FUNCTION_BOUNDARY returns on calls, i.e.
a double argument is aligned properly when generating the function body, but
when the function is called, gcc just push'es some integers without aligning
the double that follows.
> There are several alignments. We should enable those which won't
> break old binaries by default. We only enable those which are not
> compatible with old binaries when asked for. Please check the egcs
> mail archive. I have forwarded Marc's patch to egcs at the beginning.
-mstack-align-double (STACK_BOUNDARY) is safe (apart from the above bug)
-marg-align-double (aligning doubles in argument slots) totally breaks the abi
(totally = much more often than -malign-double), and doesn't work
yet.
-malign-double (structures) breaks the abi, but often works in practise (libjpeg
is a prominent exception).
this is really very bad, since misalignment often causes runtime
differences of 30% and *more*. I often get letters from people
that ask my why static variables seem to be faster than auto variables
(or vice versa), which is caused by random alignment.
-----==- |
----==-- _ |
---==---(_)__ __ ____ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / pcg@goof.com |e|
-=====/_/_//_/\_,_/ /_/\_\ --+
The choice of a GNU generation |
|