Speeding Up Builds with LLVM ThinLTO: When and How to Use It

Problem: Long link steps dominate incremental builds

When a project grows, the link phase can take seconds or minutes, slowing down edit‑compile‑test cycles. Full LTO (-flto=full) improves runtime but often makes the link step even heavier because the optimizer works on a single combined module.

Thesis: LLVM ThinLTO gives most of the optimization benefit of full LTO while keeping the link step fast and parallelizable

How ThinLTO works

ThinLTO splits the traditional LTO pipeline into two stages. In the frontend stage each object file is compiled with -flto=thin, which emits a compact summary of its symbols and optimizations. These summaries are cheap to produce and can be generated in parallel. In the backend stage the linker collects the summaries, determines which functions need to be imported across module boundaries, and runs a targeted, import‑driven optimization pass only on the relevant parts. The heavyweight whole‑program analysis is avoided, so memory usage drops and the backend can run on multiple threads.

Worked example: building a tiny C program

Assume you have a file demo.c containing a simple recursive function. From a terminal with clang and LLVM ≥6.0 available, run:

1. Compile with full LTO and measure link time:

clang -flto=full -O2 demo.c -o demo_full
time -p ./demo_full   # run the binary just to ensure it links; the time output shows real, user, sys

2. Compile with ThinLTO and measure link time:

clang -flto=thin -O2 demo.c -o demo_thin
time -p ./demo_thin

You can compare the real values from the time output; ThinLTO typically shows a shorter link step. To check binary size, use:

size demo_full demo_thin

The size difference is usually within a few percent, while the link time reduction can be 60 % or more depending on the project.

Trade‑off and verification

Because ThinLTO only optimizes imports that the summary predicts as beneficial, a few cross‑module optimizations that full LTO would catch may be missed. In performance‑critical hot paths this can translate to a runtime difference of a few percent. To verify that the impact stays within acceptable bounds for your workload:

• Build a representative benchmark (e.g., a Fibonacci function or a small kernel) with both -flto=full and -flto=thin.
• Run each binary several times and take the median execution time.
• Confirm that the ThinLTO binary is no more than ~5 % slower than the full‑LTO binary.

If the difference exceeds your threshold, consider reverting to full LTO for those translation units or using profile‑guided optimization to guide ThinLTO’s import decisions.

Actionable steps

1. Ensure your toolchain is recent: llvm-config --version should return 6.0 or higher.

1. Add -flto=thin -O2 (or -O3) to your clang invocations.
2. Keep your build system’s parallel job count high; ThinLTO’s backend scales with available cores.
3. Periodically run the size and benchmark checks above to detect regressions.

When you need the absolute best runtime and can tolerate longer links, switch back to -flto=full for release builds; otherwise ThinLTO offers a practical sweet spot for faster iteration.