From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeffrey A Law <law@cygnus.com>
To: Craig Burley <burley@gnu.org>
Cc: john@feith.com, d.love@dl.ac.uk, egcs@cygnus.com, davem@dm.cobaltmicro.com
Subject: Re: ix86 double alignment (was Re: egcs-1.1 release schedule) 
Date: Tue, 23 Jun 1998 22:55:00 -0000
Message-id: <21163.898662687@hurl.cygnus.com>
References: <199806232206.SAA00584@melange.gnu.org>
X-SW-Source: 1998-06/msg00834.html

  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