# 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`.