[PATCH][RFC] Add -Og

[Richard Guenther]

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.