4. LLVM优化Pass

LLVM优化Pass是编译器中实现代码变换与优化的核心执行单元。在深度学习编译场景下，TVM将高层计算图转换为LLVM IR后，需要依赖LLVM的Pass基础设施完成内存访问优化、循环变换、公共子表达式消除等底层优化。理解Pass管理器的调度机制以及GVN、LICM、SROA等关键Pass的算法原理，是编写高效后端代码生成规则、诊断性能瓶颈的前提。本章从Pass管理器的架构出发，深入剖析三类典型Pass的实现细节，并结合TVM中实际代码生成案例说明其应用方式。

LLVM Pass 管理器与三类核心优化 Pass 关系图 Pass 管理器 legacy PM / New PM (NPM) GVN 全局值编号 消除冗余计算 基于支配树 + 哈希表 LICM 循环不变量代码外提 循环分析 + 安全校验 提升至预头块 SROA 标量替换聚合体 拆分内存对象 消除alloca访问 LLVM IR 输入 优化后 IR 输出 Pass 依赖与执行顺序 • 前置分析：DominatorTree、LoopInfo、TargetTransformInfo • 典型顺序：SROA → GVN → LICM → 其他清理 Pass • 新 Pass 管理器支持显式依赖声明与缓存复用

4.1 Pass管理器的架构与调度机制

4.1.1 核心原理：从Legacy PM到New PM

LLVM的Pass管理器负责Pass的实例化、调度、依赖分析和结果缓存。早期Legacy Pass Manager（Legacy PM）采用线性执行模型，Pass之间通过getAnalysis<T>()动态请求依赖，但存在以下问题：无法静态验证依赖完整性、Pass执行顺序敏感、难以支持并发编译。New Pass Manager（NPM）自LLVM 8.0起逐步取代Legacy PM，其核心设计包括：

  • 显式依赖声明：Pass通过getAnalysisUsage()声明所需分析结果，管理器在运行前构建依赖DAG。
  • 分析结果缓存：分析Pass（如DominatorTree）的结果可被多个变换Pass复用，避免重复计算。
  • 流水线管道化：支持PassBuilder构建优化管道，允许按OptimizationLevel自动插入Pass。
  • 函数/模块级粒度：区分ModulePass、FunctionPass、LoopPass等不同作用域，NPM统一为Pass概念。

在TVM中，LLVM后端通过TargetMachine的addPassesToEmitFile接口将自定义Pass注入到LLVM优化管道中。TVM的CodeGenLLVM会先执行自定义的TVMPass（如TVMCombine），再调用LLVM标准优化管道。

4.1.2 判断方法：如何选择Pass插入位置

在TVM中注入LLVM Pass时，需要根据优化目标选择插入阶段：

  1. IR生成后立即执行：适用于TVM特有的简化（如TVMFlattenBuffer），此时IR尚未被LLVM优化。
  2. 标准优化管道中：通过PassBuilder的registerPipelineStartEndCallback在指定位置插入。
  3. 代码发射前：用于最后的清理工作，如移除未使用的元数据。
经验提醒：在TVM中，若自定义Pass需要依赖LLVM的分析结果（如LoopInfo），务必在getAnalysisUsage中声明，否则NPM会因依赖缺失而拒绝执行。

4.1.3 案例拆解：TVM中注册自定义Pass

以下代码展示了TVM中如何通过NPM注册一个简单的函数级Pass：

// 在TVM的LLVM后端中注册自定义Pass
class TVMCombinePass : public llvm::PassInfoMixin<TVMCombinePass> {
public:
  llvm::PreservedAnalyses run(llvm::Function &F, 
                              llvm::FunctionAnalysisManager &AM) {
    // 执行自定义变换
    bool Changed = combineRedundantLoads(F);
    return Changed ? llvm::PreservedAnalyses::none() 
                   : llvm::PreservedAnalyses::all();
  }
};

// 注册到PassBuilder
llvm::PassBuilder PB;
PB.registerPipelineParsingCallback(
  [](llvm::StringRef Name, llvm::FunctionPassManager &FPM,
     llvm::ArrayRef<llvm::PassBuilder::PipelineElement>) {
    if (Name == "tvm-combine") {
      FPM.addPass(TVMCombinePass());
      return true;
    }
    return false;
  });

该案例中，TVMCombinePass通过PassInfoMixin适配NPM接口，返回PreservedAnalyses告知管理器哪些分析结果仍然有效。若变换改变了CFG，则需返回none()使所有分析失效。

4.1.4 常见误区与总结

风险提示：不要在所有Pass中调用PreservedAnalyses::none()，这会强制重新计算所有分析结果，导致编译时间显著增加。应精确声明哪些分析被破坏。

Pass管理器的核心价值在于依赖管理与结果复用。在深度学习编译中，由于IR规模庞大（单个函数可能包含数千个基本块），合理利用分析缓存可减少30%以上的编译时间。

特性Legacy PMNew PM (NPM)
依赖声明运行时动态请求静态声明，构建DAG
分析缓存手动管理自动缓存与失效
并发支持不支持支持并行编译
Pass类型Module/Function/Loop等统一Pass概念

4.2 GVN（全局值编号）的原理与实现

4.2.1 核心原理：基于支配关系的值等价性

GVN（Global Value Numbering）的目标是识别程序中计算相同值的指令，并消除冗余。其核心思想是：为每个值分配一个值编号（Value Number），如果两条指令具有相同的编号，则它们计算的结果必然相同。GVN利用支配树（Dominator Tree）保证安全性：只有当一条指令支配另一条指令时，才能用前者替换后者。

实现步骤包括：

  1. 构建支配树和支配边界。
  2. 按支配序（RPO）遍历基本块，维护ValueNumber到Value*的映射表。
  3. 对每条指令计算操作数哈希，若哈希命中且支配关系成立，则替换为已存在的值。
  4. 处理load指令时，需结合别名分析（AliasAnalysis）判断内存访问是否等价。

4.2.2 判断方法：何时GVN能生效

GVN适用于以下场景：

  • 同一基本块内或循环中存在重复的算术运算（如a*b出现多次）。
  • 通过getelementptr计算相同地址的指针。
  • 加载相同内存地址且中间无写操作。

在TVM中，当计算图包含重复的layout_transform或cast操作时，GVN能有效消除冗余。

4.2.3 案例拆解：消除冗余计算

考虑以下LLVM IR片段：

%a = mul i32 %x, %y
%b = mul i32 %x, %y   ; 冗余
%c = add i32 %a, %b

GVN分析过程：

  1. 为%a分配编号VN1，记录(mul, %x, %y) → %a。
  2. 遇到%b时，计算操作数哈希得到相同编号VN1。
  3. 检查支配关系：%a支配%b，因此将%b替换为%a。
  4. 最终IR变为%c = add i32 %a, %a。

在TVM的GEMM代码生成中，若索引计算i*lda+j在多个load指令中重复出现，GVN可将其合并为一次整数运算，减少地址计算开销。

4.2.4 常见误区与总结

注意事项：GVN不能跨内存写操作消除load指令。例如，若两个load之间有一个store可能修改同一地址，则不能合并。此时需要依赖更强大的部分冗余消除（PRE）或内存SSA。

GVN是编译器中收益最稳定的Pass之一，通常能减少5%-15%的指令数。在深度学习模型中，由于大量重复的张量形状计算和索引运算，GVN的收益尤为明显。

4.3 LICM（循环不变量代码外提）的原理与实现

4.3.1 核心原理：循环分析驱动的代码移动

LICM（Loop Invariant Code Motion）将循环体内不随迭代变化的计算提升到循环外部，减少重复执行。其实现依赖LoopInfo分析结果，主要步骤包括：

  1. 识别循环的预头块（Preheader）和退出块（Exit Block）。
  2. 遍历循环体内指令，判断是否为不变量：操作数要么是常量，要么在循环外定义，要么是循环不变量。
  3. 检查安全性：指令必须满足支配所有出口且不会产生副作用（如不会触发异常）。
  4. 将不变量指令插入预头块，并更新所有使用点。

4.3.2 判断方法：安全外提的条件

一条指令能否外提需同时满足：

  • 循环不变性：操作数在循环内不被修改。
  • 支配性：指令在循环内的所有路径上执行，且外提后仍能覆盖所有使用点。
  • 无副作用：不涉及volatile访问、函数调用（可能抛出异常）或内存写操作。

对于load指令，还需确保循环内没有可能修改该内存地址的store。

4.3.3 案例拆解：矩阵乘法中的地址计算外提

在TVM生成的矩阵乘法代码中，内层循环通常包含以下模式：

for (int i = 0; i < N; ++i) {
  for (int j = 0; j < M; ++j) {
    float *a_ptr = A + i * lda + j;  // 不变量：i*lda
    float *b_ptr = B + j * ldb;      // 不变量：j*ldb
    C[i*ldc+j] += (*a_ptr) * (*b_ptr);
  }
}

LICM分析：

  1. 识别i*lda为循环j的不变量（i在j循环内不变）。
  2. 将i*lda的计算外提到j循环的预头块。
  3. 进一步，若lda是常量，i*lda可被GVN与外部循环的相同计算合并。

实际效果：对于N=1024的矩阵乘法，LICM可减少约N*M次整数乘法，显著降低地址计算开销。

4.3.4 常见误区与总结

风险提示：LICM外提浮点运算可能改变精度。例如，若循环内存在a = b * c，且b在循环内被修改，则不能外提。LLVM默认不进行可能改变浮点语义的变换，除非指定FastMathFlags。

LICM在深度学习编译中至关重要，因为张量运算的索引计算往往包含大量循环不变量。TVM的StorageRewrite和LoopPartitionPass会主动创造更多LICM机会。

4.4 SROA（标量替换聚合体）的原理与实现

4.4.1 核心原理：将内存对象拆分为标量

SROA（Scalar Replacement of Aggregates）针对alloca指令分配的聚合类型（结构体、数组）进行优化。其核心思想是：如果聚合体的每个字段都能被独立分析，则将其拆分为多个标量虚拟寄存器，从而消除内存访问，使后续Pass（如GVN、寄存器分配）能更有效地处理。

实现步骤：

  1. 识别alloca指令，检查其所有使用点是否满足可拆分条件（如getelementptr + load/store）。
  2. 若聚合体未被取地址（addrspacecast、ptrtoint等），则进行拆分。
  3. 为每个字段创建独立的虚拟寄存器，并替换所有load/store操作。
  4. 若所有字段均被替换，则删除原alloca。

4.4.2 判断方法：SROA的适用条件

SROA成功的关键在于：

  • 聚合体的所有访问必须通过getelementptr进行，且索引为常量。
  • 不能有将聚合体指针传递给外部函数的操作（除非函数被内联）。
  • 聚合体大小不宜过大（LLVM默认限制为128字节）。

在TVM中，SROA常用于优化struct类型的参数传递和临时变量存储。

4.4.3 案例拆解：优化TVM中的缓冲区描述符

TVM在生成代码时，常使用结构体描述缓冲区信息：

struct BufferDesc {
  float* data;
  int shape[4];
  int strides[4];
};

void compute(BufferDesc *buf) {
  for (int i = 0; i < 4; ++i) {
    buf->data[i] = buf->data[i] * buf->strides[i];
  }
}

SROA分析：

  1. 识别buf指向的alloca（假设buf由alloca分配）。
  2. 检查所有访问：buf->data和buf->strides均为getelementptr + load/store。
  3. 将data和strides拆分为独立指针变量。
  4. 进一步，若strides是常量，可被常量传播消除。

优化后，循环内的load操作直接访问寄存器，减少了内存延迟。

4.4.4 常见误区与总结

经验提醒：SROA与mem2reg不同，mem2reg仅处理简单的alloca（无聚合类型），而SROA专门处理聚合体。在TVM中，若发现生成的LLVM IR包含大量alloca结构体，应优先检查SROA是否被禁用。

SROA是LLVM中最重要的内存优化Pass之一，它为后续的寄存器分配和指令调度创造了条件。在深度学习编译中，SROA能有效减少张量描述符的内存访问，提升缓存利用率。

4.5 三类Pass的协同与实战调优

4.5.1 协同工作流程

在实际编译管道中，SROA、GVN和LICM通常按以下顺序执行：

  1. SROA首先运行，将聚合体拆分为标量，为后续优化提供更多机会。
  2. GVN消除拆分后出现的冗余计算。
  3. LICM将循环不变量外提，减少循环体开销。

这种顺序并非，但遵循先内存优化，再全局优化，最后循环优化的原则。

4.5.2 实战调优：TVM中调整Pass管道

TVM允许通过环境变量或代码配置LLVM优化级别：

# 在TVM中设置LLVM优化级别
import tvm
target = tvm.target.Target("llvm -mcpu=skylake -O3")
# 或通过PassBuilder自定义管道
with tvm.transform.PassContext(config={"tir.disable_assert": True}):
    # 编译流程
    pass

当遇到性能瓶颈时，可通过llc -debug-pass-manager查看Pass执行日志，定位未生效的优化。

4.5.3 案例复盘：优化一个卷积核生成代码

背景：TVM为3x3卷积生成LLVM IR，初始性能为120ms/iter。

现象：分析发现内层循环包含大量重复的getelementptr计算和结构体字段访问。

分析：

  • SROA未生效：缓冲区描述符以结构体形式传递，导致每次访问都需内存load。
  • GVN未消除冗余：多个getelementptr计算相同地址。
  • LICM未外提：循环内重复计算i*3+j。

操作：

  1. 在TVM代码生成中，将缓冲区描述符拆分为独立参数（data_ptr、stride等）。
  2. 启用llvm -O3，确保SROA和GVN运行。
  3. 手动将i*3计算外提到内层循环外。

结果：优化后性能提升至85ms/iter，减少约29%的执行时间。

复盘：LLVM Pass的效果高度依赖IR质量。TVM在生成IR时，应尽量使用标量变量而非结构体，为LLVM优化创造有利条件。

总结：掌握Pass管理器的调度逻辑，理解GVN、LICM、SROA的算法边界，是深度学习编译器后端开发的核心技能。建议读者在TVM中通过llc -print-after-all观察每个Pass后的IR变化，建立直观的优化感知。
← 上一章 📖 返回目录 下一章 →