This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: optimization defaults (was: Re: [GCC 3.0] Bad regression, binary size)


<<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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]