LTO本质是链接时合并多翻译单元的中间表示（如LLVM Bitcode）再全局优化。需编译和链接均启用-flto，否则无效；可提升跨文件内联与虚函数去虚拟化，但代价是编译慢、内存高、调试难。
链接时优化（LTO）本质是把多个翻译单元的中间表示合并后再优化
普通编译流程中，每个 .cpp 文件单独编译成目标文件（.o），此时编译器只能看到本文件内的代码，跨文件的函数内联、死代码消除、常量传播等全局优化全部失效。LTO 的核心动作是在链接阶段，让链接器（如 ld 或 lld）不直接处理机器码，而是加载编译器生成的“中间表示”（如 LLVM Bitcode 或 GCC GIMPLE），把这些 IR 合并成一个逻辑上的大模块，再跑一遍完整的优化流水线（包括 -O2 或 -O3 级别的所有 passes）。
启用 LTO 需要编译和链接两步都加标志，缺一不可
只在编译时加 -flto 不会生效；只在链接时加也不会触发优化。必须两端一致：
- 编译每个源文件时：用
g++ -flto -O2 -c a.cpp b.cpp—— 此时生成的.o实际包含 Bitcode（GCC）或.bc（Clang），而非纯机器码 - 链接时：用
g++ -flto -O2 a.o b.o -o prog—— 链接器调用 GCC/Clang 后端，读取 Bitcode，合并、优化、最终生成可执行文件 - 若使用
make，需确保所有.o都用-flto编译，否则混合 LTO/non-LTO 目标会导致链接失败或降级为非 LTO 模式
LTO 对内联和虚函数调用有实质性改善
这是最常被验证到的收益点。例如一个定义在 a.cpp 的 inline 函数，被 b.cpp 中的虚函数调用间接调用，传统编译无法内联；而 LTO 合并后能识别该调用链，并在优化中完成内联。同样，如果 b.cpp 中的虚函数调用仅发生在单个派生类实例上（且该类定义在 a.cpp），LTO 可能将虚调用降级为直接调用（devirtualization）。
但注意：-flto 默认不开启跨 DSO 优化（即不优化动态库之间的调用）。若需对 .so 做 LTO，GCC 需配合 -fPIC -flto -shared，且主程序链接时也需 -flto，同时避免符号隐藏（-fvisibility=hidden 会阻碍跨模块分析）。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
LTO 的代价：编译慢、内存高、调试信息弱
实际项目中容易低估这些副作用：
- 链接时间可能增加 2–5 倍，尤其在大型项目中，
ld会变成瓶颈；Clang +lld比 GCC +ld.bfd快得多，推荐搭配使用 - 内存占用显著上升，10k 行 C++ 项目链接时可能吃掉 2–4 GB 内存；CI 环境若内存不足会 OOM
-
gdb调试体验下降：LTO 后的二进制中行号映射不准、局部变量丢失、内联展开导致栈帧混乱；建议发布构建用 LTO，开发构建关掉 - 不是所有优化都稳定：某些版本 GCC 在 LTO 下会错误折叠浮点计算（受
-ffast-math影响更大），若程序依赖严格 IEEE 语义，需测试验证
g++ -flto -O3 -march=native -DNDEBUG main.cpp util.cpp -o app # 注意：-march=native 和 -DNDEBUG 应在编译和链接时都出现，否则 LTO 可能忽略部分架构特化
LTO 真正起效的前提是整个构建链条统一——从预处理、编译、汇编到链接，所有环节都要知道“我们正在做全局优化”。漏掉任意一环，就退回传统模型。这也是为什么它在 CMake 中要用 set(CMAKE_INTERPROCEDURAL_OPTIMIZATION ON) 而不是手动加 flag：后者极易遗漏。
