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).
>
>> 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.
> 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 =.
> 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.
Thanks,
Matt
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-d...@linaro.org
