The unified LTO pipeline creates a single LTO bitcode structure that can
be used by Thin or Full LTO. This means that the LTO mode can be chosen
at link time and that all LTO bitcode produced by the pipeline is
compatible, from an optimization perspective. This makes the behavior of
LTO a bit more predictable by normalizing the set of LTO features
supported by each LTO bitcode file.
Example usage:
# Compile and link. Select regular LTO at link time. clang -flto -funified-lto -fuse-ld=lld foo.c # Compile and link. Select ThinLTO at link time. clang -flto=thin -funified-lto -fuse-ld=lld foo.c # Link separately, using ThinLTO. clang -c -flto -funified-lto foo.c # -flto={full,thin} are identical in terms of compilation actions clang -flto=thin -fuse-ld=lld foo.o # pass --lto=thin to ld.lld # Link separately, using regular LTO. clang -c -flto -funified-lto foo.c clang -flto -fuse-ld=lld foo.o # pass --lto=full to ld.lld
The RFC discussing the details and rational for this change is here:
https://discourse.llvm.org/t/rfc-a-unified-lto-bitcode-frontend/61774
This is a bit unfortunate, as we now get a lot of transitive includes to most *.cpp files in lld/ELF...