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]
Other format: [Raw text]

Re: Should -fcross-jumping be part of -O1?


Scott Robert Ladd <coyote@coyotegulch.com> writes:

> In my mind, GCC can support more than one constituency; I would very
> much like to see a -Ospeed, -Osize, and -Obalanced switches, for
> example, to provide specific optimization sets for given audiences.

I think this is a good idea.

I'd like to point out that there are Makefiles all over the place that
are hardwired to -O2.  So -O2 needs to do something sane in the general
case.  I would suggest that -O2 and your -Obalanced be synonymous.

I don't think it is a good idea to add more -O[0-9] levels.

There is another axis to consider, namely compile time, which is what
-O1/2/3 are *supposed* to trade off now.  This becomes less and less
important as hardware gets faster, but should not be ignored, since
gcc is well known to be too slow even on fast hardware.

My suggested constellation of -O switches:

-O0    No optimization whatsoever.  
       Except maybe do obviously-dead code elimination.
-O1    Optimize, but speed of compilation is more important than
       speed or size of generated code.  Possibly this, not -O0,
       should be the default mode.

-O3/-Ospeed
       Optimize for speed at the expense of size.
-Os/-Osize
       Optimize for size at the expense of speed.
-O2/-Obalanced
       Produce a balance of speed and size optimizations acceptable
       for most code.

Two factors that are *not* considered in any of these switches are
ease of debugging, and scope (function/unit/program) of optimization.
I do not think it is appropriate to exclude optimizations from any
level just because they mess up debugging info, and scope of
optimization is a detail that shouldn't be exposed at the level of
these switches.  If it makes sense in terms of the speed/size/compile
speed tradeoffs to do whole-program optimization at -O1 then we should
do it at -O1.  We can have -f switches for that.

Incidentally, Scott, I would encourage you to submit patches for 3.4
that adjust the default optimization sets, if you can find
better-in-general settings.

zw


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