On Tue, Sep 4, 2012 at 4:16 AM, Matthew Gretton-Dann <matthew.gretton-d...@linaro.org> wrote: > On 4 September 2012 10:45, Richard Guenther <rguent...@suse.de> wrote: >> 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).
It will be harder to use it to debug binutils. >>> 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? > > I don't see a problem with inlining functions under -Og - under a > couple of assumptions: > * The debug table format can correctly mark inlined functions (DWARF > can - I don't know about other formats). > * The compiler is executing sequence points in order - and so the > function being inlined doesn't 'spill out' into the function it is > inlined into. See below for further comments. > > This should provide enough information to the debugger to allow it to > maintain the illusion that an inlined function is a separate function, > and enable a user to set breakpoints on all calls to the function. It works for me. >> 3. Compiler shouldn't move lines around. >> >> A good goal as well, probably RTL pieces are least ready for this. > > I would change this to say something like (using C language terms): > The compiler should provide enough information to allow breakpoints to > be set at each sequence point, and that the state of the machine is > such that everything before that sequence point will have been > completed and that nothing after that sequence point will have been > started. > > It is probably also possible to argue that there is a case for having > points between sequence points where we say the code would be in a > good state (lets call them observation points). So for instance we > might want to say that in: > > int x, a, b, c; > ... > x = a + b * c; > > If we just say we only promise a known state at sequence points then > the compiler is free to use some form of multiply-accumulate > instruction here. But a user may want to see the multiply followed by > addition split out. So we could define the observation points to be > on the *, +, and =. The problem I run into is "next" in gdb can go backward within the same function when compiled with optimization. It makes harder for me to use breakpoints to track where/when the problem happens. -- H.J.