On Mon, 3 Sep 2012, Richard Guenther wrote: > On Fri, Aug 10, 2012 at 1:30 PM, Richard Guenther <rguent...@suse.de> wrote: > > > > This adds a new optimization level, -Og, as previously discussed. > > It aims at providing fast compilation, a superior debugging > > experience and reasonable runtime performance. Instead of making > > -O1 this optimization level this adds a new -Og. > > > > It's a first cut, highlighting that our fixed pass pipeline and > > simply enabling/disabling individual passes (but not pass copies > > for example) doesn't scale to properly differentiate between > > -Og and -O[23]. -O1 should get similar treatment, eventually > > just building on -Og but not focusing on debugging experience. > > That is, I expect that in the end we will at least have two post-IPA > > optimization pipelines. It also means that you cannot enable > > PRE or VRP with -Og at the moment because these passes are not > > anywhere scheduled (similar to the situation with -O0). > > > > It has some funny effect on dump-file naming of the pass copies > > though, which hints at that the current setup is too static. > > For that reason the new queue comes after the old, to not confuse > > too many testcases. > > > > It also does not yet disable any of the early optimizations that > > make debugging harder (SRA comes to my mind here, as does > > switch-conversion and partial inlining).
Please, no inlining. Think of stack back-traces and their use when debugging. > > The question arises if we want to support in any reasonable > > way using profile-feedback or LTO for -O[01g], thus if we > > rather want to delay some of the early opts to after IPA > > optimizations. > > > > Not bootstrapped or fully tested, but it works for the compile > > torture. > > > > Comments welcome, > > No comments? Then I'll drop this idea for 4.8. I'm guessing people were just expecting that some other maintainer was going to say "ok", and waiting for it to be committed! Comments? Ok: great! But, there was a talk at the GNU Tools Cauldron with related contents - <http://gcc.gnu.org/wiki/cauldron2012#Control-flow_preservation_in_GCC_for_safety-critical_uses>. It'll be Very Nice if control flow preservation was part of -Og or at least they played nice together. Can't determine that myself though, sorry. brgds, H-P
