如何在GCC中编译常规.h-.c目标文件并达到静态Unity构建同等优化水平？

核心逻辑说明 #

Unity构建能实现全内联，本质是把所有源文件合并成单个编译单元，编译器可以直接看到所有函数实现，自然能无阻碍地完成内联和全局优化。而常规构建下，编译器默认按单个源文件编译，目标文件仅保留对外暴露的符号信息，链接器默认只做符号解析与地址重定位，不会深入做跨文件优化——但这并非做不到，只需手动开启特定配置即可。

具体实现方法 #

• 强制开启链接时优化（LTO）
  这是核心关键，主流编译器均支持：

  • GCC/Clang：编译和链接阶段都添加 -flto 选项，追求极致性能可使用 -flto=full（编译时间会明显延长）。
  • MSVC：编译时添加 /GL 参数，链接时搭配 /LTCG 参数。
    开启LTO后，链接器会获取所有目标文件的中间代码（IR），能像处理单个编译单元一样完成跨文件内联、死代码消除、函数合并等优化，效果基本与Unity构建持平。

• 给函数优化添加“引导提示”

  • 对于需要跨文件内联的函数，除了使用static，可在头文件中用extern inline声明（C99及以上标准支持），同时在某一个源文件中实现该函数，能提升编译器跨文件内联的意愿。
  • 确需强制内联的场景，可使用__attribute__((always_inline))（GCC/Clang）或__forceinline（MSVC），但注意不要滥用——过度内联会导致代码膨胀，反而降低缓存命中率。

• 拉满编译器优化级别
  确保开启-O3（GCC/Clang）或/Ox（MSVC）这类高级别优化选项，它们会让编译器更积极地执行内联、循环展开等优化操作，与LTO配合能最大化性能收益。

• 避免不必要的符号限制
  若非必须，不要给非static函数添加__attribute__((visibility("hidden")))这类符号可见性限制属性，否则会制约LTO的跨文件优化能力。

为什么编译器默认不做跨文件优化？ #

传统编译流程优先兼顾编译速度与模块化：单个源文件编译完成后直接生成目标文件，后续修改仅需重新编译改动的文件，效率很高。但代价是每个目标文件仅对外暴露符号，内部实现细节不会传递给链接器。LTO是为追求极致性能后续新增的功能，它需要保留所有中间代码，会大幅增加编译链接时间，因此默认不会开启——毕竟多数场景下，编译速度比极致性能更具优先级。

内容的提问来源于stack exchange，提问作者iloveclang