Re: [GCC 3.0] Bad regression, binary size

[Linus Torvalds <torvalds at transmeta dot com>]

On Mon, 9 Jul 2001, Marc Espie wrote:
>
> No, you read this a bit too quick. Someone suggested to use
> -mpreferred-stack-boundary to get the size back down, which actually does
> work, but still does not give me any idea why my kernel is suddenly bigger.

Ahh, ok.

> The actual object sizes is +10K,
> The resulting kernel is +60K,
> compressed size difference is even larger.

Bad compression? Doesn't sound like alignment or lack of merging. Although
the code alignment is using the "multi-byte nops", which might not
compress that well. If the default architecture has changed..

> Now, the rationale for keeping -mpreferred-stack-boundary `high' by default
> is that  mixed code (`normal' code + floating point code) does need that
> boundary by default, so if you turn that off, say in library code, then
> all floating point code loses (because it's somewhat inefficient to regain
> proper boundary, and the compiler does not really know when to emit that
> code, e.g., where is the boundary between floating point code and
> non-floating point code, since this is global stuff that isn't even
> `fixed').

But that's a bogus argument.

The compiler _does_ know when to emit the code. You only need to emit the
code when:
 - you have floating point arguments to a function you're calling (so that
   you can try to align the arguments - but realize that none of the x86
   ABI's really allow for true alignment ANYWAY)
 - you need to spill floating point

If you add these rules together, you also know that
 - you are already aligned if you got a floating point argument.

(Exchange "large object" for "floating point" - I realize that things like
XMM etc also want alignment. Also, you may want to modify the rule about
fp arguments - maybe not try to keep the stack itself aligned, but keep
instead the first fp argument aligned).

Now, floating point doesn't just happen on its own. When you have floating
point spills, I will bet you that in most cases you have floating point
arguments to your function too. Which means that with the above two
heuristics (and the rule you can infer from them), you will probably see
very little "unnecessary" alignment generation.

And the win? You see _no_ unnecessary alignment for the normal case.

And remember: you're supposed to optimize for the normal case. That's
rule#1 in optimization. Always.

> Kernels are special beasts, since they are completely isolated from
> userland, and hence their stack boundary issues are very well isolated.

I agree that kernels tend to have more well-defined behaviour, and for
that reason kernels (and embedded projects) can often use rules that are
illegal in general. HOWEVER, I disagree strongly that kernels are that
"special".

I would argue that floating point is a lot more special than kernels are.
I bet the code generation and optimization issues for kernels tend to be
closer to most programs than FP code tends to be. Which is why I think it
is the FP code that should be special-cased, not the kernel.

> I can hardly fault the gcc team on preferred-stack-boundary...

Why? Do you argue that it makes code better on average? I seriously doubt
it. And if you don't argue that, then why just accept the "we will always
do this thing" decision?

Now, I can accept the fact that some people may think it is _easier_ to
just always keep the stack aligned. That's a technical judgement, and
likely to be true. But if THAT is the reason for the alignment, then I
would still fault rth for saying "it will always be so". Maybe somebody
comes along and is willing to fix it, and I would hope that the gcc
developers would jump for joy, instead of being set on a course of bad
code generation for the default case.

		Linus