On Mon, 3 Sep 2012, H.J. Lu wrote: > On Mon, Sep 3, 2012 at 11:50 AM, <rguent...@suse.de> wrote: > > "H.J. Lu" <hjl.to...@gmail.com> wrote: > > > >>On Mon, Sep 3, 2012 at 6:28 AM, Richard Guenther > >><richard.guent...@gmail.com> 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). > >>>> > >>>> 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. > >>> > >> > >>When I debug binutils, I have to use -O0 -g to get precise > >>line and variable info. Also glibc has to be compiled with > >>-O, which makes debug a challenge. Will -Og help bintils > >>and glibc debug? > > > > I suppose so, but it is hard to tell without knowing more about the issues. > > > > The main issues are > > 1. I need to know precise values for all local variables at all times.
That would certainly be a good design goal for -Og (but surely the first cut at it won't do it). > 2. Compiler shouldn't inline a function or move lines around. Let's split that. 2. Compiler shouldn't inline a function well - we need to inline always_inline functions. And I am positively sure people want trivial C++ abstraction penalty to be removed even with -Og, thus getter/setter methods inlined. Let's say the compiler should not inline a function not declared inline and the compiler should not inline a function if that would increase code size even if it is declared inline? 3. Compiler shouldn't move lines around. A good goal as well, probably RTL pieces are least ready for this. 4. Generated code should be small and fast, compile-time and memory usage should be low. Unless either of it defeats 1. to 3. The patch only provides a starting point and from the GIMPLE side should be reasonably close to the goals above. Richard.
