[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Why not 03 ?

On Mon, 02 Jun 2014, Xavier Roche wrote:
> On Mon, Jun 02, 2014 at 10:36:01AM -0300, Henrique de Moraes Holschuh wrote:
> > As long as you have a way to regression-test.  And I don't mean performance
> > regressions, either.  Although issues with -O3 are rare, they're not unheard
> > of.
> Looking at the `man gcc' page, I fail to see, outside compiler bugs, what could cause issues at 03 vs. O2.

It is a moving target.

For GCC 4.9:
-O3 turns on all optimizations specified by -O2 and also turns on the:
-finline-functions, -funswitch-loops, -fpredictive-commoning,
-fgcse-after-reload, -ftree-loop-vectorize, -ftree-slp-vectorize,
-fvect-cost-model, -ftree-partial-pre and -fipa-cp-clone options.

For GCC 4.7:
-O3 turns on all optimizations specified by -O2 and also turns on the:
-finline-functions, -funswitch-loops, -fpredictive-commoning,
-fgcse-after-reload, -ftree-vectorize and -fipa-cp-clone options.

And compiler bugs _are_ an issue.  Which is why testing done on an
optimization level is not strictly valid for other optimization levels.  You
can ignore this, but it may eventually bite you (especially on less common
arches and optimization modes).

> I have the feeling that most "dangerous" (ie. breaking dirty code, or code using non-specified C behavior) features are already on O2:
>   * -fstrict-aliasing (code aliasing the same pointer wirh a different type)
>   * -fstrict-overflow (signed arithmetic overflow being undefined)

Optimizations related to memory reuse are _always_ a bit dangerous to enable
blindly on anything that has complex signal handlers, needs to be able to
"secure clobber" memory, implements multithreading syncronization directly,

> Outside architecture issues, such as "will produce bytecode unsupported by
> old processors", what typical optimizations can harm us at O3 ?

All of the optimizations in -O3 are known to be harmful[1] in certain
situations, otherwise they'd be in the -O2 set in the first place.

Fortunately, only compiler bugs and code with undefined behaviour will cause
incorrect program behaviour [unrelated to performance] when you change among

[1] supposedly they are only possibly harmful to performance.  When it
causes miscompiling, it is a bug.

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Reply to: