Re: [GCC 3.0] Bad regression, binary size

[Jonathan Thornburg <jthorn at galileo dot thp dot univie dot ac dot at>]

In message <URL:http://gcc.gnu.org/ml/gcc/2001-07/msg00617.html>,
Linus Torvalds <torvalds at transmeta dot 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.

I think this is a fundamental philosophical point... with which I
strongly disagree.  The problem is that referring to "most" programs
begs the question of just which sort of workload you're sampling.

I'd like to put in a voice to urge that fp performance continue to be
treated as "important".  Indeed, the integer programs that _I_ use
(including OS kernels, shells, web browsers, not to mention gcc itself)
are generally either not CPU-bound, or are already "fast enough", so
I really don't care very much about integer performance.  But the fp
codes I develop and use for a living are all painfully slow, and the
science I'm doing with them would be a lot better if they were faster,
so I care a lot about fp performance.

And yes, there are people doing serious fp on x86.  It may be a kludge
of an architecture, but sometimes money talks... and the newer x86 cpus
have significantly improved fp over older ones.

So please, keep those fp-performance options (eg 16-byte stack alignment
without having to always use a frame pointer on x86) alive for those of
us who care!

-- 
-- Jonathan Thornburg <jthorn@thp.univie.ac.at>
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany             http://www.aei.mpg.de/~jthorn/home.html
   "C++ is to programming as sex is to reproduction. Better ways might
    technically exist but they're not nearly as much fun." -- Nikolai Irgens