This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Gcc extra alignment..
- To: John Wehle <john at feith dot com>
- Subject: Re: Gcc extra alignment..
- From: Jamie Lokier <egcs at tantalophile dot demon dot co dot uk>
- Date: Thu, 2 Nov 2000 17:37:24 +0100
- Cc: rittle at latour dot rsch dot comm dot mot dot com, gcc at gcc dot gnu dot org, torvalds at transmeta dot com
- References: <200011020043.TAA08582@jwlab.FEITH.COM>
John Wehle wrote:
> > The stack is aligned to 16 bytes for some reason I don't entirely see
> > the point in. (Like, why can't the few functions that use 128-bit SIMD
> > use `and' to align their stack instead?)
>
> Keeping the stack always aligned is felt to be cheaper than burning another
> register in order to still access the arguments when using 'and' to align
> the stack.
It's also possible to copy the arguments to the aligned stack area, so
you don't need two stack registers.
> I didn't have any benchmark numbers which clearly indicated the best
> approach when I supplied the patches for both approaches in late 1998
> / early 1999 (in fact there may not be one best approach).
Well the most obvious thing is that _most_ programs don't need 16-byte
alignment at all, and relatively small parts of relatively few programs
need 8-byte alignment either.
That means alignments in code which _doesn't_ use floating point, MMX or
SSE are pure overhead. The Linux kernel is one such program.
Is that accounted for in your benchmark?
> Of course both the stack and frame pointer are normally present unless
> -fomit-frame-pointer is in use so really no additional registers are
> needed to support using 'and' to align the stack. I don't believe that
> there's any reason it can't be supported as an option if someone was to
> update the my original patch and supply convincing benchmark numbers.
-- Jamie