x86 stack alignment redux

x86 stack alignment redux

[Dave Love]

It's a while since I tried to get something like this in for the
benefit of people doing double precision fortran calculations, at
least...

With this change, a glibc2-based system such as is now apparently
becoming usable, and -malign-double, g77 users running on GNUish
686-based boxes should no longer suffer an average 50% perfromance hit
because doubles on the stack only get word-aligned (or a smaller hit
on 586).  Previous discussion suggested it's a bug if STACK_BOUNDARY
doesn't agree with the initial stack pointer alignment and glibc2
ensures initial double alignment.

This really is important to serious scientific users with high-profile
projects of the sort I understand have just been slagging off g77/gcc
at a high-performance computing meeting here.

1997-11-13  Dave Love  <d.love@dl.ac.uk>

	* config/i386/linux.h (STACK_BOUNDARY): Define as 64 for glibc2.
	* config/i386/gnu.h (STACK_BOUNDARY): Define as 64.

*** config/i386/linux.h	1997/11/02 15:23:02	1.1
--- config/i386/linux.h	1997/11/13 16:45:40
***************
*** 37,42 ****
--- 37,48 ----
  #undef DEFAULT_PCC_STRUCT_RETURN
  #define DEFAULT_PCC_STRUCT_RETURN 1
  
+ #ifndef USE_GNULIBC_1
+ #undef STACK_BOUNDARY
+ #define STACK_BOUNDARY 64       /* glibc2's crt ensures this, libc5
+                                    only gives you 32 */
+ #endif
+ 
  /* This is how to output an element of a case-vector that is relative.
     This is only used for PIC code.  See comments by the `casesi' insn in
     i386.md for an explanation of the expression this outputs. */
*** config/i386/gnu.h	1997/11/13 16:46:29	1.1
--- config/i386/gnu.h	1997/11/13 16:47:18
***************
*** 3,8 ****
--- 3,11 ----
  /* This does it mostly for us.  */
  #include <i386/linux.h>
  
+ #undef STACK_BOUNDARY
+ #define STACK_BOUNDARY 64       /* glibc2's crt ensures this */
+ 
  #undef CPP_PREDEFINES
  #define CPP_PREDEFINES GNU_CPP_PREDEFINES("i386")
  

Re: x86 stack alignment redux

[Jeffrey A Law]

  In message <rzq3el01z6k.fsf@djlvig.dl.ac.uk>you write:
  > With this change, a glibc2-based system such as is now apparently
  > becoming usable, and -malign-double, g77 users running on GNUish
  > 686-based boxes should no longer suffer an average 50% perfromance hit
  > because doubles on the stack only get word-aligned (or a smaller hit
  > on 586).  Previous discussion suggested it's a bug if STACK_BOUNDARY
  > doesn't agree with the initial stack pointer alignment and glibc2
  > ensures initial double alignment.
  > 
  > This really is important to serious scientific users with high-profile
  > projects of the sort I understand have just been slagging off g77/gcc
  > at a high-performance computing meeting here.
  > 
  > 1997-11-13  Dave Love  <d.love@dl.ac.uk>
  > 
  > 	* config/i386/linux.h (STACK_BOUNDARY): Define as 64 for glibc2.
  > 	* config/i386/gnu.h (STACK_BOUNDARY): Define as 64.
I installed this.

However, I'm a little worried about things breaking if we happen to mix
code compiled with an old compiler (say egcs-1.0 or gcc-2.7) with code
which assumes a 64bit stack boundary.  Isn't this change going to break
that case, or does the prologue/epilogue code for older compilers always
allocate 64bit hunks?

jeff

Re: x86 stack alignment redux

[H.J. Lu]

>   > 1997-11-13  Dave Love  <d.love@dl.ac.uk>
>   > 
>   > 	* config/i386/linux.h (STACK_BOUNDARY): Define as 64 for glibc2.
>   > 	* config/i386/gnu.h (STACK_BOUNDARY): Define as 64.
> I installed this.

I don't think it is a good idea. Please check out Marc's patch.

> 
> However, I'm a little worried about things breaking if we happen to mix
> code compiled with an old compiler (say egcs-1.0 or gcc-2.7) with code
> which assumes a 64bit stack boundary.  Isn't this change going to break
> that case, or does the prologue/epilogue code for older compilers always
> allocate 64bit hunks?
> 

pcg@goof.com (Marc Lehmann) and I have discussed it a few months ago.
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.

I am enclosing the ChangeLog here:

Thu Aug  7 22:30:59 1997  Marc Lehmann  <pcg@goof.com>

        * i386.c (ix86_sp_offset, ix86_frame_size): New function.
        (function_prologue, ix86_expand_prologue, ix86_expand_epilogue):
        use ix86_frame_size () instead of get_frame_size ().
        * i386.h (MASK_STACK_ALIGN_DOUBLE, MASK_ARG_ALIGN_DOUBLE,
        TARGET_STACK_ALIGN_DOUBLE, TARGET_ARG_ALIGN_DOUBLE):
        new defines.
        (TARGET_SWITCHES): new switches -m[no-]stack-align-double,
        -m[no]-arg-align-double, -mall-align-double.  -mstack-align-double
        enabled by default.
        (FUNCTION_ARG_BOUNDARY): align DFmode and XFmode arguments
        to 64 bit when -marg-align-double.
        (STACK_BOUNDARY, BIGGEST_ALIGNMENT): set to 64 if double-alignment
        requested.
        (INITIAL_ELIMINATION_OFFSET): use ix86_sp_offset () instead
        of get_frame_size ().
 


-- 
H.J. Lu (hjl@gnu.org)

Re: x86 stack alignment redux

[Jeffrey A Law]

  In message < m0xgPgQ-0004ecC@ocean.lucon.org >you write:
  > >   > 1997-11-13  Dave Love  <d.love@dl.ac.uk>
  > >   > 
  > >   > 	* config/i386/linux.h (STACK_BOUNDARY): Define as 64 for glibc2
  > .
  > >   > 	* config/i386/gnu.h (STACK_BOUNDARY): Define as 64.
  > > I installed this.
  > 
  > I don't think it is a good idea. Please check out Marc's patch.
OK.  I've reverted David's patch.

However, we can't use Marc's patch because he doesn't have a copyright
assignment on file with the FSF as far as I can tell.  And his changes
are in my opinion significant enough to require a copyright assignment.

jeff

Re: x86 stack alignment redux

[H.J. Lu]

> 
> 
>   In message < m0xgPgQ-0004ecC@ocean.lucon.org >you write:
>   > >   > 1997-11-13  Dave Love  <d.love@dl.ac.uk>
>   > >   > 
>   > >   > 	* config/i386/linux.h (STACK_BOUNDARY): Define as 64 for glibc2
>   > .
>   > >   > 	* config/i386/gnu.h (STACK_BOUNDARY): Define as 64.
>   > > I installed this.
>   > 
>   > I don't think it is a good idea. Please check out Marc's patch.
> OK.  I've reverted David's patch.
> 
> However, we can't use Marc's patch because he doesn't have a copyright
> assignment on file with the FSF as far as I can tell.  And his changes
> are in my opinion significant enough to require a copyright assignment.
> 

Have you asked him about it?


-- 
H.J. Lu (hjl@gnu.org)

Re: x86 stack alignment redux

[Marc Lehmann]

>   In message < m0xgPgQ-0004ecC@ocean.lucon.org >you write:
>   > >   > 1997-11-13  Dave Love  <d.love@dl.ac.uk>
>   > >   > 
>   > >   > 	* config/i386/linux.h (STACK_BOUNDARY): Define as 64 for glibc2
>   > .
>   > >   > 	* config/i386/gnu.h (STACK_BOUNDARY): Define as 64.
>   > > I installed this.
>   > 
>   > I don't think it is a good idea. Please check out Marc's patch.
> OK.  I've reverted David's patch.
> 
> However, we can't use Marc's patch because he doesn't have a copyright

there aren't many marc's around here... I sent the assignment to the
fsf a month ago.. it shouldn't take months from germany to the us, so I
suspect it got lost (Oh habe I good luck all the time).

> assignment on file with the FSF as far as I can tell.  And his changes

should I send it again?

      -----==-                                              |
      ----==-- _                                            |
      ---==---(_)__  __ ____  __       Marc Lehmann       +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com       |e|
      -=====/_/_//_/\_,_/ /_/\_\                          --+
    The choice of a GNU generation                        |
                                                          |

Re: x86 stack alignment redux

[Dave Love]

>>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:

 Jeffrey> OK.  I've reverted David's patch.

Good-oh if something better happens.  People doing Serious Numerical
Work on x86 will rejoice.

 Jeffrey> However, we can't use Marc's patch because he doesn't have a
 Jeffrey> copyright assignment on file with the FSF as far as I can
 Jeffrey> tell.

Bernd Schmidt had a different (simpler?) patch previously posted here
and gcc2, I think, and he's in copyright.list.  What was the issue
with his?

Re: x86 stack alignment redux

[Marc Lehmann]

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

Re: x86 stack alignment redux

[Jeffrey A Law]

  In message < rzq7m9aza7q.fsf@djlvig.dl.ac.uk >you write:
  > >>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:
  > 
  >  Jeffrey> OK.  I've reverted David's patch.
  > 
  > Good-oh if something better happens.  People doing Serious Numerical
  > Work on x86 will rejoice.
I think something will happen as soon as we deal with the copyright issues.


  >  Jeffrey> However, we can't use Marc's patch because he doesn't have a
  >  Jeffrey> copyright assignment on file with the FSF as far as I can
  >  Jeffrey> tell.
  > 
  > Bernd Schmidt had a different (simpler?) patch previously posted here
  > and gcc2, I think, and he's in copyright.list.  What was the issue
  > with his?
I think both Bernd & Marc worked on that code, so we need an assignment
on record for both Bernd & Marc.

Bernd's assignment is already on file; I've asked the record keepers to
find out what's going on with Marc's assignment.

jeff

Re: x86 stack alignment redux

[Jeffrey A Law]

  In message < 19971212171051.08257@cerebro.laendle >you write:
  > > 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
Yes it does.

If a function doesn't keep the stack rounded to the appropriate boundary
then bad things will happen.



  > lea 16(%esp),%ebx
  > addl $4,%ebx
  > 
  > into
  > 
  > lea 16(%esp),%ebx
  > orb $4,%ebx
Yes.  The combiner will make this transformation if it believes all the
effected low order bits are zero.


  > when another push is added in the prologue (to save registers), the orb is
  > no longer valid.
Right, but if STACK_BOUNDARY is defined to 64bits, then the prologue is
responsible for always maintaining that boundary.


jeff

Re: x86 stack alignment redux

[Mike Stump]

> Date: Fri, 12 Dec 1997 16:59:55 +0100
> From: Marc Lehmann <pcg@goof.com>
> To: egcs@cygnus.com

> I sent the assignment to the fsf a month ago.. it shouldn't take
> months from germany to the us, so I suspect it got lost (Oh habe I
> good luck all the time).

> should I send it again?

They are up to 11-18 now, so chances are they haven't processed it
yet.  You can ask assign@gnu.ai.mit.edu (or is it at gnu.org now?) if
he has it in his next batch.  If he says yes, then no need to send in
a new one.  If he says no, then you should.

It just takes longer than one thinks it should...  It's real paper
after all!