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

[Mehdi AMINI via Phabricator via llvm-commits]

mehdi_amini added a comment.

In https://reviews.llvm.org/D29376#663788, @pcc wrote:

> 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.


I know, that's why I didn't write "that is exactly O0".

>>> 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.

That's very legitimate, and "not being tied to the rest of the LTO pipeline" is exactly the reason why I oppose blocking the LTO pipeline on such use case. If such use-case needs to be "untied", a separate flag/flow can be provided to them.

> LTO opt level 1 already allows users to do that; it roughly means "act like a regular linker with --gc-sections".

I'd be fine with having `LTO O1` being hardcoded to a special path that would be CFI+DCE, but then what is O0?


https://reviews.llvm.org/D29376