[cfe-dev] [LLVMdev] Controlling the LTO optimization level

[Rafael Espíndola]

+      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