Full LTO vs ThinLTO: Choosing an LLVM Link-Time Optimization Mode

The decision: Full LTO, ThinLTO, or no LTO

Link-time optimization (LTO) defers cross-module optimization until the linker has all object files. In an LLVM toolchain, you enable it with -flto at compile and link time. The practical decision is not whether LTO exists, but which mode to use: Full LTO (-flto=full) or ThinLTO (-flto=thin), or to leave LTO off.

The short answer for most C/C++ projects is ThinLTO. It is designed to scale across large codebases and parallel link jobs, and it keeps incremental builds more usable than Full LTO. Full LTO is worth considering when you can afford a serial, memory-heavy link for a final release and want the most aggressive cross-module optimization the toolchain can produce.

Constraints that usually decide it

Before comparing flags, check these constraints. They eliminate options faster than any benchmark.

• Link machine memory. Full LTO merges the whole program into one optimization module. Peak memory can be several times the size of the final binary.
• Link time budget. Full LTO link time grows with program size and is largely serial. ThinLTO can use multiple threads for backend code generation.
• Incremental builds. Any source change can invalidate cross-module decisions. Full LTO often forces a full relink; ThinLTO limits the work to affected modules.
• Debug info requirements. LTO can make variable locations and inlined frames harder to inspect. If your team relies on precise stepping, validate debug info before adopting either mode.
• Prebuilt libraries. Mixing LTO objects with non-LTO objects is a common source of link failures or silently disabled optimization. Rebuild dependencies with the same mode, or verify that your linker handles the mix.

Compare supported options

Trade-offs in practice

Full LTO gives the optimizer a single view of the program. Inlining, constant propagation, and dead-code elimination can cross module boundaries without summary-based limits. The cost is a monolithic link step: more RAM, longer wall-clock time, and a build that is hard to parallelize. On a large project, the link can become the slowest part of the build.

ThinLTO keeps per-module summaries and imports only the functions that matter. The backend can then run in parallel, and unchanged modules can be reused in incremental builds. It is not identical to Full LTO, but it is usually the better engineering trade-off because it preserves most of the benefit while keeping builds tractable.

No LTO remains the right choice when build latency dominates, when the binary is small, or when you have not measured a meaningful gain. LTO is not a guaranteed speedup; it can increase code size and occasionally regress performance by making different inlining decisions.

Debug info is a separate axis. Both LTO modes can drop or move variables, and inlined functions may not appear as separate frames. If you ship debug symbols, test with your debugger and symbol server before rolling LTO out broadly.

Concrete build and validation example

The following assumes a recent Clang/LLVM toolchain. Check your version first; flag behavior has been stable across recent major releases, but verify on your installed compiler.

clang --version
ld.lld --version   # if you plan to use lld

Run these commands in a shell from your project directory. No special permissions are required. Replace a.c and b.c with your own source files. The example uses -g so you can check debug info.

Full LTO:

clang -O2 -g -flto=full -c a.c -o a.o
clang -O2 -g -flto=full -c b.c -o b.o
clang -O2 -g -flto=full a.o b.o -o app-full

ThinLTO:

clang -O2 -g -flto=thin -c a.c -o a-thin.o
clang -O2 -g -flto=thin -c b.c -o b-thin.o
clang -O2 -g -flto=thin a-thin.o b-thin.o -o app-thin -fuse-ld=lld

Expected checks:

• file a.o should report LLVM IR bitcode. If it reports an ELF object, LTO was not enabled for that file.
• llvm-dis a.o -o - should print LLVM IR. This confirms the object is bitcode, not machine code.
• size app-full app-thin compares text, data, and bss sizes. Smaller is not automatically faster; use it only as a signal that optimization changed the binary.
• llvm-dwarfdump --debug-info app-full | grep -m5 DW_TAG_subprogram checks that debug info survived. If it prints nothing, investigate the link step and your -g flags.
• Run your own benchmark. If hyperfine is available, hyperfine './app-full' './app-thin' gives repeated runs. Otherwise use time several times and compare medians, not a single run.

For ThinLTO, you can also observe parallel backend work by limiting jobs: -Wl,--thinlto-jobs=4. This is a useful diagnostic when link time is dominated by one core.

Failure modes and how to diagnose

• Link fails with undefined references or a missing LTO plugin. Ensure static archives were created with llvm-ar and indexed with llvm-ranlib. If you use GNU ld, install the LLVMgold plugin and make it discoverable. With lld, pass -fuse-ld=lld.
• Link is too slow or runs out of memory. Switch from Full LTO to ThinLTO. Reduce parallel jobs with -Wl,--thinlto-jobs=N if memory is the bottleneck.
• Debug info is missing or imprecise. Confirm -g is present at both compile and link. Check sections with readelf -S app-full | grep debug. Some variables may still be optimized away; that is expected behavior, not always a bug.
• Mixing LTO and non-LTO objects. Run file on every object. Rebuild non-LTO dependencies with the same LTO mode, or keep them out of the LTO link.

Rollback and limitations

LTO changes build flags, so rollback is straightforward: remove -flto from compile and link commands, then do a clean rebuild. If your Clang version supports fat LTO objects (check clang --help | grep fat-lto), you may be able to link without LTO, but object files will be larger.

Limitations to keep in mind: LTO does not guarantee a performance win; it can increase binary size; debug info quality varies by version and optimization level; and LTO objects from different toolchains (for example, GCC LTO objects linked by Clang) are not generally compatible. For reproducible builds, compare sha256sum of two clean builds and investigate any differences. Treat the comparison table as a starting point, then measure link time, memory, runtime, and debugger behavior on your own toolchain. If any of those checks fail, keep LTO off until the issue is understood.