[PATCH] D79818: [lld] Support size levels with (Thin)LTO

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

In D79818#2035652 <https://reviews.llvm.org/D79818#2035652>, @mehdi_amini wrote:

> In D79818#2035301 <https://reviews.llvm.org/D79818#2035301>, @phosek wrote:
>
> > In D79818#2035232 <https://reviews.llvm.org/D79818#2035232>, @MaskRay wrote:
> >
> > > @mehdi_amini @pcc @tejohnson
> > >
> > > I just saw another issue saying that `clang -Os -flto=thin a.c` does not work https://bugs.llvm.org/show_bug.cgi?id=45913 (+ @manojgupta)
> > >  I marked it as yet another duplicate of PR42445
> > >
> > > For -Os, clang driver passes -plugin-opt=Os (https://github.com/llvm/llvm-project/blob/master/clang/lib/Driver/ToolChains/CommonArgs.cpp#L402) but neither LLVMgold.so nor LLD recognizes `-plugin-opt=Os`. 
> > >  -Oz is similar. What is the concrete suggestion here? For quick reference, the `-plugin-opt=O` logic was added by rL256146 <https://reviews.llvm.org/rL256146>.
> >
> >
> > The issue form my perspective is the inconsistency. Today, lld accepts `-plugin-opt=O<number>` but it doesn't accept `-plugin-opt=O<letter>`, but Clang automatically translates `-O<anything>` to `-plugin-opt=O<anything>` which results in a failure when your try to use `-Os`, `-Oz` or `-Og` with (Thin)LTO.
> >
> > If the official stance of LTO maintainers is that we should be relying on function attributes and avoid overriding the optimization level via flags, then I'd argue that we should remove `-plugin-opt=O<number>` from lld altogether. The partial support just leads to confusion as demonstrated by some of the issues others have already referenced. In fact this change was motivated by several internal bugs from developers who tried to use ThinLTO with `-Oz` and hit the error even though `-O2` worked fine.
>
>
> The underlying issue is that O<number> vs O<letter> are somehow-but-not-really orthogonal options. Internally also, O<number> impacts the pass pipeline which isn't setup to be handled per-function, while the O<letter> is mostly communicated by adding a function attribute and does not fundamentally need to impact the optimizer pass pipeline.
>  Adding LTO into the mix makes it harder to reconcile: should we override the compile-time function attribute based on the link-time flag? On the other hand O<number> does not have the same problem with LTO.


I see that -O<number> can affect regular LTO/ThinLTO pass manager passes (`populate*PassManager` (legacy PM) and `build*Pipeline` (new PM) called by `LTOBackend.cpp:opt`). Mapping -Os and -Oz to SpeedLevel 2 may be the most user convenient thing.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79818/new/

https://reviews.llvm.org/D79818