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

[Gareth McCaughan <gmccaughan at synaptics-uk dot com>]

Scott Robert Ladd wrote:

> 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'd like to propose a slight variation on this theme.

There are several different axes along which the kind
of code a compiler generates can vary:

  - execution speed
  - code size
  - debuggability
  - compilation speed[1]
  - robustness[2]
  - simplicity of generated code[3]

and so on. It seems to me that rather than having a single
"how much optimization?" parameter and a bunch of flags
requesting special emphasis on execution speed or code size
or whatever, it makes more sense to let users specify how
important each axis is to them.

So, for instance, you could say

    gcc ..... -Ospeed=3 -Ospace=1 -Odebug=0 -Ocompiletime=0

to mean "make this run absolutely as fast as possible without
concern for debuggability or compilation time, but do take
a little trouble to avoid the generated code being enormous".
Most of the time, most users would just go on using -O2 or
whatever; the -O values would map to values for all the quality
axes. It might be worth having other pre-packaged sets of
optimization levels, though my feeling is that once you
get beyond the level of sophistication of putting "-O2" or
whatever on all your compilations, being exposed to the full
generality is unlikely to hurt.

Prior art: Common Lisp does almost exactly this, and it
seems to work very well.

[1] Compilation speed isn't really a property of the generated
    code, of course, but of the compilation process.

[2] At one extreme is making unsafe assumptions about the
    code, as many C compilers used to do when asked for
    optimization in the bad old days. At the other extreme
    is inserting bounds checks and the like. In between we
    have, e.g., -fstrict-aliasing. Possibly -ffast-math
    should be considered under this heading too.

[3] Closely related to debuggability, but maybe focusing on
    comprehensibility to humans.

-- 
Gareth McCaughan