[PATCH] D105223: [lld-macho] Add support for LTO optimization level

Leonard Grey via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 1 07:35:55 PDT 2021


lgrey added a comment.

In D105223#2851229 <https://reviews.llvm.org/D105223#2851229>, @tschuett wrote:

> Does this test -O2 or --lto-O2? Do you need two files for checking lto, i.e. it inlines foo across two TUs?

Effectively both, since what it really wants to test is the passthrough, but I don't think there's a way to sense for that directly. This just adapts lld/test/COFF/lto-opt-level.ll, but if there's some way to mock lto::LTO and assert things about its config, that seems like it would be good. Is there?

I think two files aren't necessary since the single file inlining is enough to demonstrate the flag was passed.



================
Comment at: lld/MachO/Config.h:129
   llvm::StringRef thinLTOJobs;
+  uint32_t ltoo = 2;
   bool deadStripDylibs = false;
----------------
thakis wrote:
> int3 wrote:
> > lgrey wrote:
> > > thakis wrote:
> > > > Is this the same default ld64 seems to use?
> > > AFAICT, it doesn't optimize.
> > > 
> > > ```
> > > $ cat opt_check.c
> > > void foo() {
> > >     return;
> > > }
> > > 
> > > int main(int argc, char** argv) {
> > >     foo();
> > >     return 0;
> > > }
> > > $ clang -flto=thin opt_check.c && nm -pa a.out
> > > 0000000100003f80 t _foo
> > > 0000000100000000 T __mh_execute_header
> > > 0000000100003f90 T _main
> > >                  U dyld_stub_binder
> > > ```
> > > 
> > > Should we change it to 0 for compat?
> > ld64 has an undocumented `-flto-codegen-only` flag. I haven't looked into what exactly it does, but it seems relevant...
> > Should we change it to 0 for compat?
> 
> Yes, I think so.
> 
> > -flto-codegen-only
> 
> I think that's probably something else. That ends up calling thinlto_codegen_set_codegen_only() in llvm/tools/lto/lto.cpp.
> 
> …but lto_file.cpp in ld64 doesn't seem to pass an optimization flag, and OptLevel in lto.cpp defaults to 2. Strange that ld64 doesn't get an opt level of 2 then…
Maybe the legacy LTO implementation bitrotted? The [docs](https://clang.llvm.org/docs/ThinLTO.html#id8) bake optimization in:
```
% clang -flto=thin -O2 file1.c file2.c -c
% clang -flto=thin -O2 file1.o file2.o -o a.out
```

I tried changing to 0, but this breaks existing behavior, since the default appears to be 2 when omitting opt level from the config. Are we OK with that?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105223



More information about the llvm-commits mailing list