Re: [PATCH][RFC] Add -Og

[Richard Earnshaw <rearnsha at arm dot com>]

On 04/09/12 10:45, Richard Guenther 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).
> 
>> 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.
> 

I'd add

5. User variables don't have to live in memory (or in any single place),
but there should only be one 'live' location at any one time.  Changing
the value of a variable at a sequence point/statement/line boundary
(pick a definition and document it) should affect all subsequent uses of
that variable.  Values assigned to variables remain available until the
declaration goes out of scope.

R.