llvm dev - Mar 2015 - [LLVMdev] [cfe-dev] Controlling the LTO optimization level

+      OptLevel = opt[1] - '0';

Please check and reject things like -OX at least in the gold plugin.

Can you add a test showing that

* createLowerBitSetsPass is run at -O0
* the addLateLTOOptimizationPasses passes are run at -O1, but not -O0


I think the patch is fine otherwise, but wait for a review from
someone on the ld64 side (Duncan, Manman or Bob for example).

Thanks,
Rafael


On 19 March 2015 at 15:55, Peter Collingbourne <peter at pcc.me.uk>
wrote:
> On Thu, Mar 19, 2015 at 06:32:56PM +0000, Eric Christopher wrote:
>> On Thu, Mar 19, 2015 at 11:12 AM Rafael Espíndola <
>> rafael.espindola at gmail.com> wrote:
>>
>> > Having the analogous of -O0/-O1/-O2/-O3 for the LTO pipeline makes
>> > sense I think.
>> >
>> > I agree that something along option number 2 is probably the best.
>> > Some questions:
>> >
>> > * Should "clang -O3 foo.o -o foo" use LTO with -O3?
>> > * Should "clang foo.o -o foo" use LTO with -O0? That
would be a fairly
>> > big change. Maybe we could make the LTO default be 3?
>> > * Should we just add a --ltoO to the clang driver that is
independent of
>> > -O?
>> > * Some linkers already take a -O(1,2,3) option. Should we try to
>> > forward that or should we differentiate LTO optimizations and
general
>> > linker optimizations?
>> >
>> >
>> The linker taking -O1,2,3 as a start is fine for sure. I'd rather
this go
>> from a clang driving everything perspective than a linker driving
>> everything, but that ship may have sailed.
>>
>>
>> > If we want to differentiate linker and LTO optimizations, adding a
-O
>> > plugin option to the gold plugin should be fine. As Bob points
out,
>> > for ld64 for now we would just use -mllvm.
>> >
>>
>> Sure. A better command line interface similar to the one that we
already
>> have in clang to deal with enabling/disabling passes (or, perhaps, one
>> that's even better - we're not very good at that at the moment)
would be
>> ultimately a good place to be. Otherwise the interface is just going to
be
>> some sort of special case hell for what everyone wants to do at the LTO
>> level.
>
> Thanks all. The attached implements the proposal of adding -O to libLTO,
> llvm-lto and the gold plugin, which seems to have consensus as a reasonable
> first step.
>
> Thanks,
> --
> Peter

This SGTM in principle.  The specific set of passes that you've enabled at
-O1 seems strangely small to me, but we can adjust that later.

Should this -O level be shared with CodeGen?
> On 2015-Mar-19, at 13:13, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
> 
> +      OptLevel = opt[1] - '0';
> 
> Please check and reject things like -OX at least in the gold plugin.
Same with the libLTO API and `llvm-lto`.

It might be nice to write a single utility function to verify this that's
shared between the three consumers?
> 
> Can you add a test showing that
> 
> * createLowerBitSetsPass is run at -O0
> * the addLateLTOOptimizationPasses passes are run at -O1, but not -O0
> 
> 
> I think the patch is fine otherwise, but wait for a review from
> someone on the ld64 side (Duncan, Manman or Bob for example).
> 
> Thanks,
> Rafael
> 
> 
> On 19 March 2015 at 15:55, Peter Collingbourne <peter at pcc.me.uk>
wrote:
>> On Thu, Mar 19, 2015 at 06:32:56PM +0000, Eric Christopher wrote:
>>> On Thu, Mar 19, 2015 at 11:12 AM Rafael Espíndola <
>>> rafael.espindola at gmail.com> wrote:
>>> 
>>>> Having the analogous of -O0/-O1/-O2/-O3 for the LTO pipeline
makes
>>>> sense I think.
>>>> 
>>>> I agree that something along option number 2 is probably the
best.
>>>> Some questions:
>>>> 
>>>> * Should "clang -O3 foo.o -o foo" use LTO with -O3?
>>>> * Should "clang foo.o -o foo" use LTO with -O0? That
would be a fairly
>>>> big change. Maybe we could make the LTO default be 3?
>>>> * Should we just add a --ltoO to the clang driver that is
independent of
>>>> -O?
>>>> * Some linkers already take a -O(1,2,3) option. Should we try
to
>>>> forward that or should we differentiate LTO optimizations and
general
>>>> linker optimizations?
>>>> 
>>>> 
>>> The linker taking -O1,2,3 as a start is fine for sure. I'd
rather this go
>>> from a clang driving everything perspective than a linker driving
>>> everything, but that ship may have sailed.
>>> 
>>> 
>>>> If we want to differentiate linker and LTO optimizations,
adding a -O
>>>> plugin option to the gold plugin should be fine. As Bob points
out,
>>>> for ld64 for now we would just use -mllvm.
>>>> 
>>> 
>>> Sure. A better command line interface similar to the one that we
already
>>> have in clang to deal with enabling/disabling passes (or, perhaps,
one
>>> that's even better - we're not very good at that at the
moment) would be
>>> ultimately a good place to be. Otherwise the interface is just
going to be
>>> some sort of special case hell for what everyone wants to do at the
LTO
>>> level.
>> 
>> Thanks all. The attached implements the proposal of adding -O to
libLTO,
>> llvm-lto and the gold plugin, which seems to have consensus as a
reasonable
>> first step.
>> 
>> Thanks,
>> --
>> Peter
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Thu, Mar 19, 2015 at 01:43:25PM -0700, Duncan P. N. Exon Smith
wrote:
> This SGTM in principle.  The specific set of passes that you've enabled
at
> -O1 seems strangely small to me, but we can adjust that later.
Sure. (It seemed best to me for this set to be small, at least for now,
because LTO is single-threaded, unlike regular optimization in a parallelized
build system, and so the cost of enabling a given pass is larger, especially
at lower optimization levels. The passes I selected seemed to provide enough
benefit to justify the cost.)
> Should this -O level be shared with CodeGen?
Seems reasonable, done.
> > On 2015-Mar-19, at 13:13, Rafael Espíndola <rafael.espindola at
gmail.com> wrote:
> > 
> > +      OptLevel = opt[1] - '0';
> > 
> > Please check and reject things like -OX at least in the gold plugin.
> 
> Same with the libLTO API and `llvm-lto`.
> 
> It might be nice to write a single utility function to verify this
that's
> shared between the three consumers?
Maybe. That might wait until the consumers share some kind of common flag
parsing API though. At the moment they're different enough that it's
simplest
to just write out the check in each one.
> > 
> > Can you add a test showing that
> > 
> > * createLowerBitSetsPass is run at -O0
> > * the addLateLTOOptimizationPasses passes are run at -O1, but not -O0
Done.

Thanks,
-- 
Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-libLTO-llvm-lto-gold-Introduce-flag-for-controlling-.patch
Type: text/x-diff
Size: 18265 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150319/ad2d511c/attachment.patch>