[PATCH] D123804: [clang] A Unified LTO Bitcode Frontend

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

In D123804#4490463 <https://reviews.llvm.org/D123804#4490463>, @ormris wrote:

>> IIUC -flto=full -funified-lto, -flto -funified-lto, and -flto=thin -funified-lto are identical.
>
> They're not completely identical. They change the flag passed to the linker when the linker is invoked by the compiler. I think it's worth preserving that workflow. It's used fairly often for manually compiling a project (e.g. `clang -flto=thin -funified-lto hello.cpp`), but also by CMake.

OK, sounds good. I think the description can be updated to include some examples.
The discourse link has quite a lot of discussions and the commit message/summary can be a good place to summarize all the information.
If I were a newcomer, I would find the discourse link too daunting to comprehend...

>> In the absence of -flto, -funified-lto seems a no-op (I do not see a test).
>
> Good point. Fixed.
>
>> For the lld option, I guess --lto-mode={thin,full}
>
> Maybe.... I was trying to mirror `-flto` and reduce the amount of typing required.





================
Comment at: clang/test/CodeGen/unified-lto-pipeline.c:1
+// RUN: %clang -flto=thin -funified-lto -O2 -c %s -o %t.0
+// RUN: mv %t.0 %t.1
----------------
ormris wrote:
> MaskRay wrote:
> > Without `--target`, this uses the default target triple which may fail for some exotic platforms.
> > 
> > Prefer `%clang_cc1` for non-driver tests. Instead of comparing the output files, test `-fdebug-pass-manager` output.
> Why test the pipeline rather than binary equivalence? Identical bitcode files is a key part of this feature.
`cmp %t.0 %t.1` should be retained. My point is that we probably should test some output to demonstrate that his is a ThinLTO pipeline.

`// RUN: not cmp %t.2 %t.3` is probably less useful if we can demonstrate that the pipeline is different.


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

https://reviews.llvm.org/D123804