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: john at feith dot com
- Subject: Re: ix86 double alignment (was Re: egcs-1.1 release schedule)
- From: Craig Burley <burley at gnu dot org>
- Date: Tue, 23 Jun 1998 18:06:39 -0400 (EDT)
- CC: law at cygnus dot com, d dot love at dl dot ac dot uk, egcs at cygnus dot com, davem at dm dot cobaltmicro dot com
>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. 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).
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. I think crt0 (or whatever) already assures this, but
don't know for sure about that or whether it further assures
16-byte or 32-byte alignment. But without more than 8-byte
alignment of frames, we won't get Intel's recommended alignment
for long double or large objects when they're on the stack.
(I'm guessing DATA_ALIGNMENT is already used for static and automatic
stuff, but somebody should verify this.)
tq vm, (burley)