FatLTO

Introduction

FatLTO objects are a special type of fat object file that contain LTO compatible IR in addition to generated object code, instead of containing object code for multiple target architectures. This allows users to defer the choice of whether to use LTO or not to link-time, and has been a feature available in other compilers, like GCC, for some time.

Under FatLTO the compiler can emit standard object files which contain both the machine code in the .text section and LLVM bitcode in the .llvm.lto section.

Overview

Within LLVM, FatLTO is supported by choosing the FatLTODefaultPipeline. This pipeline will:

  1. Clone the IR module.

  2. Run the pre-link (Thin)LTO pipeline using the cloned module.

  3. Embed the pre-link bitcode in a special .llvm.lto section.

  4. Optimize the unmodified copy of the module using the normal compilation pipeline.

  5. Emit the object file, including the new .llvm.lto section.

Internally, the .llvm.lto section is created by running the EmbedBitcodePass at the start of the PerModuleDefaultPipeline. This pass is responsible for cloning and optimizing the module with the appropriate LTO pipeline and emitting the .llvm.lto section. Afterwards, the PerModuleDefaultPipeline runs normally and the compiler can emit the fat object file.

Limitations

Linkers

Currently, using LTO with LLVM fat lto objects is supported by LLD and by the GNU linkers via The LLVM gold plugin. This may change in the future, but extending support to other linkers isn’t planned for now.

Supported File Formats

The current implementation only supports ELF files. At time of writing, it is unclear if it will be useful to support other object file formats like COFF or Mach-O.