LLVM Pass 开发实战从 IR 遍历到指令级优化的编译器扩展一、编译器中间表示与优化机会LLVM 的核心设计采用多层中间表示与 Pass 管线架构前端语言C/C/Rust/Swift先编译为统一的 LLVM IR经过一系列 Pass 优化后再转换为目标机器码。这种设计让优化逻辑脱离语言前端开发者只需编写一次 Pass 就能应用于多种前端语言。生产级编译器中LLVM 内置 Pass 已覆盖常量传播、循环不变量外提、死代码消除等常见优化场景。但当遇到特定领域需求——比如 AI 推理算子的自动向量化、安全敏感代码的控制流平坦化、嵌入式平台的指令选择定制——内置 Pass 往往缺乏必要的领域知识。这时就需要开发自定义 Pass 来扩展编译器能力。本文将介绍 LLVM Pass 的开发流程、IR 遍历方法及指令优化策略并提供一个实际案例。二、LLVM IR 与 Pass 架构LLVM IR 是一种强类型的 SSAStatic Single Assignment形式低级中间表示。理解 IR 结构是开发 Pass 的基础。graph TD subgraph LLVM IR 层次结构 M[Modulebr/编译单元] M -- F[Functionbr/函数] F -- BB[BasicBlockbr/基本块] BB -- I[Instructionbr/指令] I -- V[Valuebr/操作数/常量] end subgraph Pass 管线架构 P1[ModulePassbr/全局优化] P2[FunctionPassbr/函数级优化] P3[BasicBlockPassbr/基本块级优化] P1 -- P2 -- P3 end M -.- P1 F -.- P2 BB -.- P3 style M fill:#e3f2fd style F fill:#e8f5e9 style BB fill:#fff3e0 style I fill:#fce4ec2.1 LLVM IR 的核心概念每条 LLVM IR 指令都遵循 SSA 形式每个值只被赋值一次使用-定义链def-use chain显式编码在 IR 中。这一特性让数据流分析非常高效——给定一条指令可以直接遍历其所有使用者和定义者无需额外的数据流方程求解。IR 指令的操作数类型包括常量Constant、参数Argument、其他指令的结果Instruction和基本块标签BasicBlock。通过Value::use_begin()和Value::user_begin()可以分别遍历一个值的所有使用者和使用者所属的指令。2.2 Pass 的分类与注册机制LLVM Pass 主要分为两类ModulePass以整个编译单元为输入适用于全局常量合并、函数内联等需要全局视角的优化。FunctionPass以单个函数为输入适用于死代码消除、寄存器分配等局部优化。Pass 通过llvm::PassBuilder注册到优化管线中可以插入到管线的任意位置如优化早期、循环优化之前、代码生成之前。三、生产级 Pass 实现冗余边界检查消除以下实现一个 FunctionPass用于消除数组访问中的冗余边界检查。在安全编程中数组访问通常附带边界检查但当循环变量已知在合法范围内时这些检查是冗余的——消除它们可以减少分支预测失败提升循环执行效率。3.1 Pass 框架搭建// RedundantBoundsCheckElimination.cpp // 消除冗余边界检查的 LLVM FunctionPass #include llvm/IR/Function.h #include llvm/IR/Instructions.h #include llvm/IR/IRBuilder.h #include llvm/IR/Dominators.h #include llvm/Passes/PassBuilder.h #include llvm/Passes/PassPlugin.h #include llvm/Support/raw_ostream.h #include llvm/Analysis/ScalarEvolution.h #include llvm/Analysis/LoopInfo.h using namespace llvm; namespace { struct RedundantBoundsCheckElimination : public PassInfoMixinRedundantBoundsCheckElimination { PreservedAnalyses run(Function F, FunctionAnalysisManager AM) { auto LI AM.getResultLoopAnalysis(F); auto SE AM.getResultScalarEvolutionAnalysis(F); auto DT AM.getResultDominatorTreeAnalysis(F); bool Changed false; SmallVectorInstruction *, 16 ToErase; for (auto BB : F) { auto *Term BB.getTerminator(); auto *Br dyn_castBranchInst(Term); if (!Br || !Br-isConditional()) continue; auto *Cond dyn_castICmpInst(Br-getCondition()); if (!Cond) continue; if (isRedundantBoundsCheck(Cond, LI, SE, DT)) { BasicBlock *SafeBB getSafeSuccessor(Br, Cond); if (SafeBB) { BranchInst::Create(SafeBB, Br); ToErase.push_back(Br); Changed true; } } } for (auto *I : ToErase) { I-eraseFromParent(); } return Changed ? PreservedAnalyses::none() : PreservedAnalyses::all(); } private: bool isRedundantBoundsCheck(ICmpInst *Cond, LoopInfo LI, ScalarEvolution SE, DominatorTree DT) { Value *LHS Cond-getOperand(0); Value *RHS Cond-getOperand(1); auto *Phi dyn_castPHINode(LHS); if (!Phi) return false; Loop *L LI.getLoopFor(Phi-getParent()); if (!L) return false; const SCEV *PhiSCEV SE.getSCEV(Phi); const SCEVAddRecExpr *AR dyn_castSCEVAddRecExpr(PhiSCEV); if (!AR || !AR-isAffine()) return false; const SCEV *Start AR-getStart(); const SCEV *Step AR-getStepRecurrence(SE); if (Cond-getPredicate() ICmpInst::ICMP_SLT isaConstantInt(RHS) castConstantInt(RHS)-isZero()) { if (isKnownNonNegative(Start, SE) isKnownPositive(Step, SE)) { return true; } } if (Cond-getPredicate() ICmpInst::ICMP_ULE || Cond-getPredicate() ICmpInst::ICMP_SLT) { const SCEV *RHSSCEV SE.getSCEV(RHS); if (SE.isKnownPredicate(ICmpInst::ICMP_ULE, SE.getBackedgeTakenCount(L), RHSSCEV)) { return true; } } return false; } BasicBlock *getSafeSuccessor(BranchInst *Br, ICmpInst *Cond) { BasicBlock *TrueBB Br-getSuccessor(0); BasicBlock *FalseBB Br-getSuccessor(1); if (isTrapBlock(TrueBB)) return FalseBB; if (isTrapBlock(FalseBB)) return TrueBB; return nullptr; } bool isTrapBlock(BasicBlock *BB) { for (auto I : *BB) { if (auto *Call dyn_castCallInst(I)) { auto *Callee Call-getCalledFunction(); if (Callee Callee-getName().contains(trap)) return true; } } return false; } bool isKnownNonNegative(const SCEV *S, ScalarEvolution SE) { return SE.isKnownNonNegative(S); } bool isKnownPositive(const SCEV *S, ScalarEvolution SE) { return SE.isKnownPositive(S); } }; } // anonymous namespace extern C LLVM_ATTRIBUTE_WEAK ::llvm::PassPluginLibraryInfo llvmGetPassPluginInfo() { return { LLVM_PLUGIN_API_VERSION, RedundantBoundsCheckElimination, LLVM_VERSION_STRING, [](PassBuilder PB) { PB.registerPipelineParsingCallback( [](StringRef Name, FunctionPassManager FPM, ArrayRefPassBuilder::PipelineElement) { if (Name redundant-bce) { FPM.addPass(RedundantBoundsCheckElimination()); return true; } return false; } ); } }; }3.2 CMake 构建与集成# CMakeLists.txt - LLVM Pass 外部构建 cmake_minimum_required(VERSION 3.16) project(RedundantBCEPass) find_package(LLVM REQUIRED CONFIG) message(STATUS LLVM 版本: ${LLVM_PACKAGE_VERSION}) message(STATUS LLVM 路径: ${LLVM_DIR}) include_directories(${LLVM_INCLUDE_DIRS}) separate_arguments(LLVM_DEFINITIONS_LIST NATIVE_COMMAND ${LLVM_DEFINITIONS}) add_definitions(${LLVM_DEFINITIONS_LIST}) add_library(RedundantBCEPass MODULE RedundantBoundsCheckElimination.cpp ) target_compile_features(RedundantBCEPass PRIVATE cxx_std_17) set_target_properties(RedundantBCEPass PROPERTIES PREFIX ) target_link_libraries(RedundantBCEPass PRIVATE LLVMCore LLVMSupport LLVMAnalysis )3.3 使用方式# 编译 Pass 插件 cmake -B build -DLLVM_DIR$(llvm-config --cmakedir) cmake --build build # 对 LLVM IR 文件应用 Pass opt -load-pass-plugin./build/RedundantBCEPass.so \ -passesredundant-bce \ -S input.ll -o output.ll # 验证优化效果 opt -load-pass-plugin./build/RedundantBCEPass.so \ -passesredundant-bce \ -stats -S input.ll -o /dev/null四、Pass 开发的工程挑战LLVM Pass 开发在获得编译器级优化能力的同时也面临一些实际挑战API 稳定性问题LLVM 的 Pass 基础设施在 13-18 版本间经历了从 Legacy Pass Manager 到 New Pass Manager 的重大迁移。许多 API 被废弃或重命名且 LLVM 不提供跨版本的 API 兼容保证。为 LLVM 16 编写的 Pass 可能在 LLVM 18 上无法编译维护成本随版本升级持续增加。ScalarEvolution 的分析精度限制SE 分析对循环结构的要求较为严格——需要循环具有单入口、可计算的迭代次数与仿射归纳变量。对于包含间接跳转、可变步长或复杂退出条件的循环SE 可能返回CouldNotCompute导致 Pass 无法做出优化决策。Pass 间的交互副作用自定义 Pass 与内置 Pass 之间可能存在隐式依赖。例如冗余边界检查消除依赖循环简化LoopSimplify与归纳变量规范化IndVarSimplify的前置处理。若 Pass 注册顺序不当可能导致分析结果不准确甚至引入错误优化。IR 转储与调试的陡峭学习曲线LLVM IR 的文本表示包含大量类型注解与元数据阅读难度远高于高级语言。当 Pass 引入错误优化时定位根因通常需要逐指令对比优化前后的 IR 差异这一过程耗时且容易遗漏关键细节。llvm::verifyFunction可以检测 IR 的合法性但无法检测语义正确性。五、总结LLVM Pass 开发为编译器扩展提供了统一的接口和工具支持使得领域特定的优化逻辑可以嵌入到编译管线中。通过 ScalarEvolution 的归纳变量分析与支配树的条件推理冗余边界检查消除 Pass 能够在编译期安全地消除运行时冗余检查减少分支预测失败提升循环密集型代码的执行效率。落地建议新 Pass 开发优先使用 New Pass Manager APIPass 注册时显式声明对前置分析LoopInfo、ScalarEvolution、DominatorTree的依赖在 CI 中集成llvm-lit测试框架对于 SE 分析不可覆盖的复杂循环考虑结合运行时剖析Profile-Guided Optimization辅助优化决策。