[LLVMdev] [cfe-dev] Controlling the LTO optimization level
Duncan P. N. Exon Smith
dexonsmith at apple.com
Thu Mar 19 13:43:25 PDT 2015
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 - '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).
> 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
>>>> * 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
>> 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.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-commits