Re: [GCC 3.0] Bad regression, binary size

[Linus Torvalds <torvalds at transmeta dot com>]

In article <20010707164531.C2847@redhat.com> you write:
>On Sat, Jul 07, 2001 at 11:41:48PM +0200, Jamie Lokier wrote:
>> By the way, is this 16 byte stack alignment going to be a permanent
>> feature?
>
>Yes.

Ugh.  It's a bad, bad, misoptimization.

99% of all code tends to be pretty much integer only.  You do not get
any wins from the alignment, and you do get clear losses.  For one,
function calls are clearly more expensive, and your dcache isn't as
dense. 

So you optimize for the 1% of benchmarks that care, at the expense of
the 99% of real-life code that doesn't?

>> As far as I can tell, it is not necessary to 16-byte align all functions
>> just to help the performance of a few.  Instead, functions which pass
>> aligned arguments or use aligned locals, and which don't receive any
>> aligned argument, could use "and" to align the stack themselves.  It is
>> necessary to record the original stack pointer, but that is easy enough.
>
>Yes, this can be done, but it is _really_ expensive.  You can
>no longer directly address stack arguments, and wind up burning
>yet another register to address them.

You can fix it in three easy-ish steps (famous last words):
 - require that functions that have alignment requirements have a frame
   pointer
 - make a "align frame pointer prologue" (which is not that different
   from the existing one - one extra "and")
 - load all alignment-wanting arguments into pseudos in the prologue
   after aliging the frame pointer (and let the normal spill code spill
   them if required - now they are aligned or are cached in registers). 

This would not have any negative impact on most code, and I don't see it
as being noticeably slower than the "always align" even for the FP-heavy
code. Especially as gcc _already_ defaults to having a frame pointer
even when optimizing.

gcc-3.0 already gets complaints for generating slower and more bloated
code than previous gcc releases. That should tell people something.

		Linus