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

[Jan Hubicka <hubicka at ucw dot cz>]

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

I would completely agree with this.  Perhaps we can use -Ofast,
so people won't think about existing -Os as shortcut for -Ospeed.
It is not very english, but perhaps more error prone.
Also -O3 does not include loop unrolling and -fomit-frame-pointer for
some reason.  I think we ought to consider including it.
> 
> Two factors that are *not* considered in any of these switches are
> ease of debugging, and scope (function/unit/program) of optimization.

I was thinking about this too.  The solution may be to introduce
-Odebug/-Ono-debug specifiers that control subset of optimizations
making debugging nasty.
However it is dificult to make decision here. Clearly -fweb is nasty until we have location lists.
Bot is for instance tail call optimization is nasty or not nasty?  It
breaks unwind info.  Similarly for register allocation and one don't
know where to stop.
The idea of -Odebug is more foggy, so perhaps we can discuss it in
separate.  I will happilly make -Ospeed/-Ofast, -Osize, -Obalanced
patch if we have consensus here :)

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