Link-Time Optimization

Ordinarily the compiler runs the whole pipeline per file and hands the linker finished machine code. By then it is far too late for any cross-file reasoning: the linker sees bytes and relocations, and cannot inline a function it can only recognise as a range of instructions.

LTO changes only *when* code generation happens. Each -c compile runs the frontend, the type checker and usually a cheap first optimization pass, then serialises the IR into the object file and stops. The linker — via a plugin, because a linker does not know what bitcode is — recognises these files, resolves symbols across all of them, feeds the resolution back to the optimizer, and the optimizer generates real machine code with the full set of definitions in hand.

The symbol resolution feedback is the part that is easy to miss and is genuinely load-bearing. The optimizer needs to know not merely that a definition exists but whether *this* definition is the one that will win: whether it is preemptible, whether it is also defined in a shared library being linked, whether anything outside the bitcode set references it. Only the linker knows, which is why the two components have to talk rather than merely take turns.

Full LTO does the obvious thing: merge every module into one, run the interprocedural optimizer over it, then generate code. The view is complete and the analysis is exact. It is also a single process holding the IR of the entire program, running a mostly sequential optimizer, and rerunning all of it whenever anything changes. On large programs this is where builds go to die — link steps measured in tens of minutes and tens of gigabytes.

ThinLTO replaces the merge with a plan. Each compile emits, alongside its bitcode, a compact summary: the module's call graph edges, per-function size and cost estimates, which symbols it defines and references, and enough type information to reason about virtual calls. The linker combines only the summaries — small, fast, one pass — into a global index, and from that index decides *which* functions each module should import from which other modules. Then the backend jobs run in parallel, one per module, each importing only the handful of bodies its plan named.

What ThinLTO trades is exactness. The plan is made from summaries, not from bodies, so the importing decisions are made on estimates, and a function not imported is not available to be inlined however profitable it would have been. In exchange it recovers the two properties full LTO destroys: the backend is parallel again, one job per module, and it is cacheable and incremental — an unchanged module whose imports did not change can reuse its previous object file.

In practice ThinLTO recovers a large majority of full LTO's runtime benefit at a small multiple of a normal build's cost rather than an enormous one, which is why it is what most large projects that use LTO at all actually use. The exact fraction is a property of the codebase, not a constant.

The failures cluster into three families, and none of them is "the optimizer produced worse code".

The first is resources. Full LTO on a large binary is the single most memory-hungry step in most builds, and it fails by being killed rather than by reporting anything useful. The second is flag consistency: because code generation happens at link time, target flags supplied only at compile time may be silently ignored, and inconsistent flags across units now meet inside one optimizer. The third and most interesting is latent bugs surfacing. LTO does not create undefined behavior; it makes existing UB and existing one-definition-rule violations exploitable, because the optimizer can finally see both halves of the contradiction. Code that "worked" for a decade breaks, and the LTO flag gets the blame it does not quite deserve — the honest description is that it changed which assumption was profitable to act on. That distinction matters when you go looking for the fix, because reverting the flag hides the bug rather than removing it.