This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ix86 double alignment (was Re: egcs-1.1 release schedule)
- To: Craig Burley <burley at gnu dot org>
- Subject: Re: ix86 double alignment (was Re: egcs-1.1 release schedule)
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Tue, 23 Jun 1998 22:31:27 -0600
- cc: john at feith dot com, d dot love at dl dot ac dot uk, egcs at cygnus dot com, davem at dm dot cobaltmicro dot com
- Reply-To: law at cygnus dot com
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