Re: [PATCH][RFC] Add -Og

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Tue, Sep 4, 2012 at 4:16 AM, Matthew Gretton-Dann
<matthew.gretton-dann@linaro.org> wrote:
> On 4 September 2012 10:45, Richard Guenther <rguenther@suse.de> wrote:
>> On Mon, 3 Sep 2012, H.J. Lu wrote:
>>
>>> On Mon, Sep 3, 2012 at 11:50 AM,  <rguenther@suse.de> wrote:
>>> > "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>> >
>>> >>On Mon, Sep 3, 2012 at 6:28 AM, Richard Guenther
>>> >><richard.guenther@gmail.com> wrote:
>>> >>> On Fri, Aug 10, 2012 at 1:30 PM, Richard Guenther <rguenther@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.