This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: ix86 double alignment (was Re: egcs-1.1 release schedule)



  In message <199806232206.SAA00584@melange.gnu.org>you write:
  > >Though it's not as fine-grain as what's mentioned above it may be
  > >worth while to consider using the DATA_ALIGNMENT macro when laying
  > >out variables for the stack.  On the i386 it currently returns the
  > >Intel recommended alignment for doubles, long doubles, arrays, etc.
  > >(the recommended alignment for long doubles is different from doubles).
  > 
  > I realized later that we can't really do alignment of stack variables
  > on more than 8-byte boundaries unless we're willing to align the
  > stack frames themselves to those larger boundaries.
Yup.  Good point.


  > In a program
  > that doesn't itself use long double or arrays, would this be a
  > win or lose anyway, in terms of performance?  On the one hand, almost
  > always subtracting 4-28 bytes from %sp before pushing arguments onto
  > the stack before a call seems a waste.  On the other hand, maybe the
  > new stack frame itself meets Intel's definition of an object
  > greater than 32 bytes long (at least in most cases, I'd guess).
It's an interesting question to think about.  HP recommends a 64byte
alignment for the stack on PAs.  It has some *really* nice benefits
as far as the dcache is concerned.  And until about a year ago we
actually followed that guideline -- by setting STACK_BOUNDARY appropriately :-)

That's how I know about the problems that combine will cause if you
end up with a mis-aligned stack pointer relative to STACK_BOUNDARY.
It turned out the crt0 code on hpux10 only provided 8 byte alignment
for the stack pointer.  Opps.

Once in a great while folks would complain about the stack wasteage,
but it was rather rare -- even the embedded folks working on the PA
didn't complain (which in retrospect I find amazing).

  > My current assumption is we are shooting for only 8-byte alignment
  > of the stack frame to obtain 8-byte alignment of doubles within
  > the frame.
Right.  The nice thing is whatever mechanism we come up with could
later be used to increase the stack pointer alignment if we deemed
it useful.

  > (I'm guessing DATA_ALIGNMENT is already used for static and automatic
  > stuff, but somebody should verify this.)
Correct.  We changed the definition of DATA_ALIGNMENT to apply to 
basically anything in the static store -- including constants which
turned out to be a big win for some spec codes on the x86.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]