问题描述

在包含大量紧密循环和底层算术操作的计算密集型应用中，开启 LTO（Link-Time Optimization）后可能出现性能退化而非预期的优化收益。实测表明退化幅度可达 +4%~+10%。

根因分析

问题的本质是 LTO 模式下 inline scheduling 顺序与 loop optimization 的交互冲突：

1. 不是「能否 inline」的问题，而是「何时 inline」的问题。 LTO 将多个编译单元合并后，原本在单文件编译中会被 early inliner 处理的小函数（如底层乘法、位操作辅助函数），其 inline 提示被推迟到 late inliner pass。然而此时 loop unrolling 和 vectorization 优化已经完成。

2. 循环优化看到不完整的循环体。 由于关键热路径函数在 early inliner 阶段未被展开，后续 loop unrolling pass 看到的循环体包含函数调用而非展开后的指令序列，因此做出了更保守的展开决策（少展开约 30%~40% 的指令）。

3. 影响范围： 这一问题主要影响具有以下特征的代码：

   • 跨编译单元的小型 inline-declared 辅助函数
   • 这些函数位于循环热路径上
   • 循环优化收益高度依赖完整循环体的可见性

修复方向

通过调整 inline 时机，确保关键小函数在 early inliner 阶段被展开，使后续 loop unrolling/vectorization pass 能看到完整的循环体，可完全消除该劣化。具体措施包括：

• 提高 early inliner 对小函数的内联阈值（inline-small-function threshold）
• 放宽 LTO 模式下对 inline-declared 函数的 unit growth 限制

经验证，应用上述调整后 LTO 退化可从 +10% 降至统计学不显著的水平（<0.2%，p>0.1）。