如何优化单次编译单文件程序的GCC编译速度

疑问1：Dead Store Elimination（DSE） 耗时高的原因及与死代码消除的区别 #

• 核心区别：
  • Dead Store Elimination（DSE）：专门消除没有后续读取操作的存储指令——比如给变量赋值后，后续代码从未读取该变量的值，这个赋值操作就是"死存储"，DSE会直接移除它。
  • 死代码消除（Dead Code Elimination, DCE）：消除的是永远不会被执行到的代码块/指令——比如if (0) { ... }中的代码，或者return语句之后的冗余逻辑。
• 耗时高的原因：
  你的场景是10万行代码+嵌套循环+-O3+-funroll-all-loops，循环强制展开后生成了大量冗余存储操作；再加上-mavx和512位向量宽度的设置，变量的数据流依赖关系变得异常复杂。GCC在DSE阶段需要遍历所有变量的存储、读取轨迹，做全局数据流分析来判断哪些存储是无效的，这个过程在代码量膨胀、依赖关系复杂的情况下会消耗大量CPU时间。

疑问2：reload CSE regs 阶段的含义 #

这个阶段并不是"先做CSE再撤销"，而是寄存器分配后的修复步骤：
在-O3优化下，GCC会先通过公共子表达式消除（CSE）把重复计算的表达式存入寄存器，减少重复计算。但循环展开、向量化会导致寄存器压力骤增，寄存器分配器可能无法为所有CSE优化后的表达式保留足够的寄存器，有些之前存在寄存器里的公共子表达式的值会被溢出到内存。reload CSE regs阶段就是把这些溢出到内存的公共子表达式重新加载回寄存器，确保后续代码能正确使用这些值。因为你的代码寄存器压力大，这个阶段需要处理大量重新加载操作，所以耗时较高。

基于-O3的编译速度优化方案 #

由于你必须保留-O3以保证执行速度，以下是不影响执行效率的优化方向：

• 拆分大文件为多个小模块并行编译：
  把10万行的单文件拆分成多个逻辑独立的小文件（比如把foo函数和相关依赖拆分到单独的.c文件），然后用-j选项开启并行编译（例如gcc -O3 ... -j8，数字根据CPU核心数调整）。这样可以把单文件的编译压力分散到多个CPU核心，大幅缩短总编译时间。拆分时要合理保留内联函数的声明（比如在头文件中用static inline），避免影响执行速度。
• 调整循环展开和向量化选项：
  • 把-funroll-all-loops换成-funroll-loops：前者会强制展开所有循环，导致代码量暴增，增加编译分析压力；后者只会展开GCC判断为适合的循环，既能保留大部分循环展开的性能收益，又能减少代码膨胀，降低DSE和寄存器分配阶段的工作量。
  • 评估-mprefer-vector-width=512的必要性：如果目标CPU在执行512位向量指令时没有明显性能提升，或者代码中的循环并不适合512位向量（比如循环体数据依赖强），可以换成-mprefer-vector-width=256，减少向量化后的代码复杂度，降低编译阶段的分析压力。
• 升级GCC版本：
  GCC 11.4是较旧的稳定版本，后续的GCC 12、13版本在优化阶段的性能有显著提升，尤其是DSE和寄存器分配相关模块，能在保持-O3优化效果的前提下，大幅缩短编译时间。
• 关闭不必要的调试信息：
  如果编译时默认添加了-g选项（生成调试信息），请去掉它，调试信息会增加大文件的编译时间，且不影响执行速度。
• 使用链接时优化（LTO）配合并行编译：
  拆分文件后，添加-flto=auto选项开启链接时优化，既可以享受单文件编译的并行速度，又能在链接阶段保持全局优化的效果，不会损失-O3带来的执行性能。

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