Re: x86 stack alignment redux

[Marc Lehmann <pcg@goof.com>]

> 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                        |
                                                          |