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

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.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150319/b8a70ba7/attachment.html>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-libLTO-llvm-lto-gold-Introduce-flag-for-controlling-.patch
Type: text/x-diff
Size: 13404 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150319/4c3a6f8d/attachment.patch>

+      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