Unified LTO Bitcode Front-End Comes Together For LLVM

Thanks to work carried out by Sony engineers and then offered for upstream, over the past few weeks support for a unified LTO bitcode front-end has materialized within the LLVM codebase.

Up to this point when dealing with LLVM's Link-Time Optimizations (LTO) whether going for the "thin" or "full" LTO bitcode had to be determined at the pre-link phase since the generated LTO bitcode was incompatible with one another. Sony's unified LTO bitcode front-end allows for the same bitcode to be used whether going for the thin or full LTO route and thus punting that decision to the linking stage. LLVM's ThinLTO provides for better scalability over the conventional "full" LTO. Those unfamiliar with the ThinLTO can see LLVM's documentation.

Sony's Matthew Voss explained on LLVM Discourse of this work on unifying the LTO bitcode as an option:

"Currently, LTO mode is chosen during the pre-link phase and can’t be changed at a later stage. Thin and Full LTO bitcode may share a binary format (LLVM bitcode), but are explicitly made incompatible. When summaries were added to Full LTO, they were given a different name, to ensure that they were never confused with ThinLTO summaries.

Our 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. In addition, this means that all LTO bitcode is compatible, from an optimization perpsective. Currently, if a compilation has both Thin and Full LTO bitcode files, they will be optimized separately with no information shared between the Full and Thin backends. Since the internal structure of a bitcode file isn’t visible to most users, this may not be the expected behavior. This compatibility also means that deploying bitcode libraries can be a simpler process. A normalized set of features over all bitcode files helps to ensure that users get the optimizations they expect when these libraries are included.

We implemented this feature by making every LTO module identical in structure to a split ThinLTO bitcode module. We then use the Full LTO pipeline for pre-link optimisation. This allows for maximum optimisation and compatibility. It also, as you’ll see below, leads to increased file sizes. This is due to the fact that type information is always available when using this scheme, which means that more split modules are created."

Earlier this month the LLVM code was committed for adding this Unified LTO Bitcode Frontend followed by the clang support with the "-funified-lto" switch. Last week brought the LLD support for this unified LTO bitcode.