调优 LLVM 的 SLP 向量化器成本模型：一次性能回归的排查与修复

背景

在近期对 LLVM 编译器后端针对 RISC-V 架构（特别是 BPI-F3 开发板）的优化过程中，作者发现了一个显著的性能回归现象。通过监控 Igalia 的 LNT (LLVM Ninja Test) 实例，一个特定的基准测试程序（Benchmark）显示出高达 89% 的性能波动。具体表现为：发出的指令数量增加了约 26%，而执行周期（Cycles）增加了约 48%。

这一性能下降的核心在于 LLVM 的新版本代码生成（Codegen）试图将原本标量（Scalar）的有序浮点加法链（Ordered fadd chain）替换为向量化的归约指令（如 vfredosum.vs）。然而，这种替换引入了额外的内存存储（Store）开销，导致整体执行效率反而低于旧的标量实现。作者通过深入分析 LLVM IR 中间表示，定位到问题根源在于中端（Middle-end）的 SLP（Superword Level Parallelism，超字级并行）向量化器成本模型未能准确评估“内存溢出（Stack Spilling）”带来的惩罚，从而做出了错误的优化决策。

核心内容

1. 性能回归的具体表现

在对比新旧版本 LLVM 生成的汇编代码后，作者观察到一个基本块（Basic Block）的执行周期几乎翻倍。

• 旧版本行为：执行一系列标量浮点加法指令（fadd），直接在寄存器中进行累加，无需额外的内存交互。
• 新版本行为：
  1. 内存溢出：编译器生成了一系列 fsd（Float Store Double，双精度浮点存储）指令，将寄存器中的标量浮点值存储到栈内存中（地址为 s1 + 0x80 及其后续偏移量）。
  2. 向量加载：使用 vle64.v 指令从上述内存地址加载数据到向量寄存器 v16。
  3. 向量归约：执行 vfredosum.vs（有序浮点求和归约）指令，对向量寄存器中的数据进行求和。

这种新代码生成策略试图用一条向量归约指令替代多条标量加法指令，但由于必须先进行“标量转向量”的内存搬运，其总开销（Cycles）远高于直接进行标量计算。

2. 问题定位：从汇编到 LLVM IR

为了确定问题出在后端（Backend）还是中端（Middle-end），作者使用以下命令生成了 LLVM IR 中间表示：

$lbd/bin/clang -O3 \
--target=riscv64-unknown-linux-gnu \
-march=rva22u64_v \
--gcc-toolchain=/usr \
--sysroot=/usr/riscv64-linux-gnu \
-I. \
-DFP_ABSTOLERANCE=1e-5 \
-S -emit-llvm seidel-2d.c \
-o seidel-2d.ll

通过分析生成的 IR，作者发现以下关键模式：

1. 标量加法链：IR 中保留了 fadd double 指令，用于计算标量累加值。
2. 向量构建：出现了一连串的 insertelement 指令，逐步将标量值插入到一个 <8 x double> 类型的向量中。
   • 初始向量标记为 poison（毒药值，表示未初始化）。
   • 每个 insertelement 将前一步的结果作为源向量，插入一个新的标量值。
   • 最终构建出包含所有累加值的完整向量 %34。
3. 向量归约调用：构建好的向量被传递给 llvm.vector.reduce.fadd.v8f64 内在函数（Intrinsic），该内在函数映射到 RISC-V 的 vfredosum 指令。

; 简化的 IR 片段示意
%27 = insertelement <8 x double> poison, double %24, i32 0
%28 = insertelement <8 x double> %27, double %add.i, i32 1
...
%34 = insertelement <8 x double> %33, double %26, i32 7
%35 = call double @llvm.vector.reduce.fadd.v8f64(double -0.000000e+00, <8 x double> %34)

这表明问题并非出在 RISC-V 后端对 vfredosum 指令的生成上，而是出在中端（Middle-end）。中端的 SLP 向量化器错误地判断：将标量操作转换为向量操作并调用归约内在函数，比保留原有的标量链更高效。

3. 根本原因：成本模型（Cost Model）的缺陷

LLVM 的 SLP 向量化器在决定是否将标量指令向量化时，依赖于成本模型来估算不同执行路径的代价。在此案例中：

• 被忽略的开销：成本模型未能充分计入将标量值“溢出”到栈内存（Stack Spilling）以构建向量的代价。fsd 指令不仅消耗执行周期，还增加了内存带宽压力和潜在的缓存未命中风险。
• 错误的收益评估：模型高估了 vfredosum 归约指令相对于多个 fadd 指令的性能收益，低估了数据准备阶段（存储+加载）的惩罚。

4. 排查过程

作者通过 git log 搜索与 "reduction"（归约）相关的提交，最终锁定了一个可疑的提交（commit e28e），该提交修改了与归约相关的成本计算逻辑。

关键要点

• 性能回归现象：LLVM 新版本在 RISC-V 目标上导致特定基准测试性能下降 89%，主要体现为指令数增加 26% 和周期数增加 48%。
• 错误的优化决策：编译器试图用向量归约（vfredosum）替代标量加法链（fadd），但引入了昂贵的内存溢出（fsd）和加载（vle64.v）操作。
• 问题定位：通过生成 LLVM IR，确认问题出在中端（Middle-end）的 SLP 向量化逻辑，而非后端（Backend）的指令生成。
• IR 特征：IR 中出现了大量的 insertelement 指令用于构建向量，随后调用 llvm.vector.reduce.fadd 内在函数，这是向量化器强行将标量链转换为向量归约的证据。
• 根本原因：SLP 向量化器的**成本模型（Cost Model）**存在缺陷，未能正确评估“标量转向量”过程中的内存访问惩罚（Stack Spilling Penalty），导致其做出了错误的优化选择。
• 修复方向：需要调整 SLP 向量化器的成本模型，使其在评估归约操作时，更准确地计入数据准备阶段的内存开销。

意义与影响

1. 编译器优化的复杂性：此案例生动展示了编译器优化并非简单的“指令替换”。向量化通常能带来性能提升，但在数据依赖性强、数据量小或内存访问受限的场景下，盲目向量化反而会导致性能倒退。
2. 成本模型的重要性：LLVM 等现代编译器的性能高度依赖于其内部的成本模型。任何对成本估算逻辑的修改（如新的归约优化）都需要经过严格的基准测试，以确保不会引入新的性能回归。
3. RISC-V 生态的成熟度：随着 RISC-V 向量扩展（RVV）的普及，编译器后端和中端需要不断适配新的指令集特性。此修复有助于提升 LLVM 对 RISC-V 向量指令的支持质量，确保开发者能真正受益于硬件加速。
4. 调试方法论：作者展示了一套标准的编译器性能调试流程：观察性能指标 -> 对比汇编代码 -> 生成 IR 定位问题阶段（前端/中端/