This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: optimization defaults (was: Re: [GCC 3.0] Bad regression, binary size)
- To: gcc at gcc dot gnu dot org, jthorn at galileo dot thp dot univie dot ac dot at
- Subject: Re: optimization defaults (was: Re: [GCC 3.0] Bad regression, binary size)
- From: dewar at gnat dot com
- Date: Tue, 24 Jul 2001 11:47:40 -0400 (EDT)
- Cc: jthorn at thp dot univie dot ac dot at
<<I think we can safely assume that anyone doing benchmarks at -O0 is
clueless. Maybe we want to add a sentence or two in the manual to
empasize that -O0 really means *no* optimization, but I don't think
we need worry about -O0 performance in anything except compile time.
>>
Speaking from our GNAT experience, that's quite unfair.
Many of our customers are used to compilers where
a) reasonable code is generated even with optimization turned off
b) they prefer not to optimize, because of considerations of reliability
and debuggability.
Thus when they get GNAT (and I am sure the same happens with C and C++)
they often compare unoptimized performance of GNAT with unoptimized
performance of some other compiler, assuming that this is apples vs apples
when of course it is not, because gcc produces truly ghastly code in -O0
mode.
I actually think that some very mild optimization would speed up compile time
by reducing the amount of junk that has to be dealt with subsequently, and
for that matter has to be assembled.
I have often felt that it would be nice to have an optimization level
between -O0 and -O1 that would not affect debuggability, but would generate
basically reasonable code, unlike what comes out at -O0 now.
Anyway, you can dismiss people as clueless, but the fact of the matter is
that gcc often suffers in benchmarking because of this effect.