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. 2. Compiler shouldn't inline a function or move lines around. -- H.J.
