Let me tell ya, this stuff is wild!

Before anything else: what’s LTO and why should we care about it? Well, let’s say you have a massive codebase with tons of dependencies. Normally, when you compile your program, the compiler generates intermediate language (IL) for each source file and then optimizes everything at link time. But with LTO, the IL is written to special sections in an output file so that all the different compilation units can be optimized as a single module!

This expands the scope of inter-procedural optimizations to encompass the whole program (or, rather, everything that is visible at link time). And let me tell ya, it’s pretty ***** cool. But there are some requirements and design considerations you need to be aware of before jumping in headfirst.

First off, LTO requires a container format for the IL sections (ELF was chosen as the initial implementation on the branch), but support has been added for PE-COFF and Mach-O. So if your target doesn’t support one of these formats, you might be outta luck.

Secondly, LTO does not require any special linker features (although it can take advantage of the plugin feature in gold). The basic mechanism used by the compiler to delay optimization until link time is to write the IL sections inside object files and then load every function in every file during compilation.

But there are some issues left to address, such as how to handle mixed command line options (which can affect code generation) or how to analyze and visualize LTO files when debugging. And let’s not forget about the need for tools that can read GIMPLE formatted as a text file instead of relying on source code.

Overall, LTO is an exciting development in the world of coding, but it requires careful consideration and attention to detail. So if you want to learn more about this stuff (and maybe even contribute to the project), be sure to check out the design documents and discussions on GCC’s website!