Re: [GCC 3.0] Bad regression, binary size

[Linus Torvalds <torvalds at transmeta dot com>]

On Mon, 9 Jul 2001 dewar@gnat.com wrote:
>
> <<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.
> >>
>
> But it is not just floating-point, it is any 8 or 16 byte object, such
> as a 64-bit integer, or a struct with two 32-bit fields.

Structs with two 32-bit fields? Why? They are accessed with 32-bit
operations, they don't need any alignment.

Using MMX opcodes for moving 8-byte entities around is _stupid_. You get
FP save/restore exceptions everywhere. The break-even point for using MMX
(and trust me, the kernel people have done the numbers) tends to be in the
kilobyte range. So something like memcpy()/memset() will use it, but as it
only makes sense with large areas and with XMM anyway (and XMM has support
for unaligned start/end stuff), I seriously doubt it's an issue.

But read my email again: I did say that "floating point" is "any large
object". Yes it happens. But yes, it also tends to be very localized.
Whether we're talking about "long long" or "long double" or
"xmm_fp_type_t". And I claim that my heuristic should work rather
efficiently.

There are numbers to back up the problems with stack alignment. Just
search the archives on this list.

Show me the numbers that back up the fact that stack alignment is globally
necessary. I doubt you will find a _single_ benchmark that would hurt from
doing it just locally.

I have the numbers for the current practice being BAD. You show me yours
to back up YOUR claims.  Until you do, you're just spouting opinions and
hot air.

And that's not how you should do optimization work.

		Linus