[LLVMdev] [cfe-dev] Controlling the LTO optimization level
peter at pcc.me.uk
Thu Mar 19 12:55:34 PDT 2015
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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 13404 bytes
Desc: not available
More information about the llvm-dev