[PATCH] D29376: LTO: align the Monolithic LTO optimization pipeline on the ThinLTO and O2/O3 one

Peter Collingbourne via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 1 12:54:23 PST 2017

pcc added a comment.

In https://reviews.llvm.org/D29376#663761, @mehdi_amini wrote:

> In https://reviews.llvm.org/D29376#663757, @pcc wrote:
> > We already use regular LTO at opt level 1 -- this basically provides "dead stripping with support for CFI and devirtualization". That is essentially all we need from the LTO pipeline at the moment.
> So that's more like a O0 :)

No, O0 does not include globaldce and functionattrs.

>> Based on my reading of the code, the thin LTO opt level 1 pipeline does a lot more than the current regular LTO opt level 1 pipeline. Switching the pipeline like this would likely make link times unacceptably slow until we switch to thin LTO.
> `Unacceptably slow` for Chromium is not the majority of use-cases. 
>  If we end up with Chromium being the only blocker for any progress for the 99.9% other applications, you're likely gonna have to supply you own flag "-mllvm -do-lto-optimizations-but-not-too-much".

It is not necessarily just Chromium, it is any user who just wants CFI/devirt without it being tied to the rest of the LTO pipeline. It is already possible to pick and choose those features at compile time, and I reckon that property should be carried through to the linker. LTO opt level 1 already allows users to do that; it roughly means "act like a regular linker with --gc-sections". I think we should keep that meaning at least until those users can move to thin LTO. I don't have a problem with changing the other opt levels, though (and in fact, I'd encourage it, as it would allow us to remove the existing regular LTO pipeline).


More information about the llvm-commits mailing list