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, etc. > 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 -Os,-Og,-O0,-O1,-O2,-O3. [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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140602174106.ga2...@khazad-dum.debian.net
