如果你在编译器、编程语言或高性能计算相关领域工作那么你对 LLVM 这个名字一定不陌生。但如果有人问起LLVM 项目到底是什么很多人的第一反应是它是一个编译器。这个说法不算错但远远不够。LLVM 是一个模块化的编译器基础设施是一整套工具链和库的集合它改变了编译器的构建方式。早期它只是伊利诺伊大学的一个研究项目目标是提供一种静态单赋值形式的中间表示让优化和分析变得更简单。后来这个架构被证明极具生命力Clang、LLD、MLIR 等子项目陆续加入让 LLVM 从一个学术原型长成了今天几乎统治了工具链底层生态的基础设施。我最初接触 LLVM 是因为工作需要把一套内部 DSL 编译到不同架构上当时翻了很多文档踩了不少坑后来逐渐整理出了自己的学习路径。这篇内容不打算写成官方文档的复述而是想从一个实际使用者的角度把 LLVM 这个庞大项目剖开讲讲它的核心模块、构建方式、实战要点以及那些文档里不会明说的经验。无论是刚入门的学生、做语言前端的工程师还是想用 LLVM 加速计算管线的研究者应该都能在这里找到一些有用的线索。需要说明一点LLVM 的演进速度很快主分支几乎每天都在变。本文基于 LLVM 15.0.7 时代形成的结构来描述后续版本在细节上会有调整但整体架构和设计思路是稳定连贯的。1. 用一个具体问题理解 LLVM 的架构逻辑为什么它能通吃所有语言想理解 LLVM最好的方式不是背诵模块名而是回答一个问题为什么 C、Rust、Swift、Julia 这些语法风格差异巨大的语言最终都能靠同一套优化和后端跑出高效机器码答案藏在中间表示这个分层设计里。LLVM 的核心抽象叫 LLVM IR它是一种低层次但仍是人类可读的中间语言。它的设计目标是既保留足够的语义信息来做优化比如类型信息、控制流结构、内存访问模式又足够接近机器层面让后端可以做真实的指令选择与寄存器分配。这套架构可以简单归纳为三段流水线语言前端把源码翻译成 IR中端优化器对 IR 做一轮又一轮的变换后端再把 IR 映射成目标机器的指令。1.1 前端Clang 只是其中一员提到 LLVM 的前端大多数人第一个想到的是 Clang。Clang 负责解析 C/C/Objective-C 源码生成 AST再逐步降级到 LLVM IR。它和 GCC 的最大差异在于Clang 的架构是库化的解析器、语义分析器、代码生成器都可以作为库被嵌入其他工具这让 IDE 的代码补全、静态检查工具、重构工具都能复用同一套前端逻辑而不是各自写一套解析器。但不是所有语言都走 Clang。Rust 用的是 rustc 内置的前端Swift 用 swiftcJulia 在早期版本自己生成 LLVM IR。LLVM 并不关心你的源码长什么样只要你最终能把语义翻译成合法的 IR就能接入整套优化与后端。1.2 中端Pass 管线和优化策略IR 进入中端后会经过一个被称为 Pass 管线的过程。每个 Pass 都是一次对 IR 的变换或分析比如死代码消除、循环展开、内联、常量传播。这些 Pass 以固定顺序执行每一轮变换都让 IR 更接近高效的机器代码。有趣的是Pass 管线的顺序本身就是一门学问。内联太早可能导致代码膨胀太晚又可能错过其他优化机会循环优化通常放在后期因为它依赖前面的分析结果。LLVM 默认提供几套优化等级-O0、-O1、-O2、-O3、-Os它们背后就是不同的 Pass 组合。你可以把 Pass 理解为一个个可以插拔的功能卡。编译器工程师的一大工作就是决定在哪种优化等级下挂载哪些 Pass以及它们的执行顺序。这也是为什么有些 CPU 平台会专门开启或关闭某些 Pass——优化策略和硬件特性之间有很强的耦合。1.3 后端目标描述文件驱动代码生成后端是 LLVM 中最魔法的部分。它负责两件事指令选择把 IR 指令映射为目标机器的具体指令和寄存器分配把虚拟寄存器映射到物理寄存器。这两件事都高度依赖目标平台但 LLVM 通过 TableGen 语言把平台描述数据和编译器逻辑分离开。具体来说后端工程师会用 TableGen 描述一款 CPU 的指令集、寄存器文件、指令编码格式、调度模型。LLVM 的工具链会从这些描述中生成 C 代码形成指令选择器、汇编器、反汇编器。这意味着如果你要为一个新的 CPU 架构提供 LLVM 支持你不需要重写整个编译器而是写一套描述文件再补上一些特殊的定制逻辑。这种设计也让 LLVM 能快速支持新平台。RISC-V 就是一个典型案例从规范发布到 LLVM 提供较完整的后端支持时间非常短因为大部分代码生成逻辑是通用的只需要填写新架构的硬件信息。1.4 组件之间的边界是 LLVM 最伟大的设计至此你应该已经理解了 LLVM 的价值它不绑定任何语言、不绑定任何 CPU、甚至不绑定任何应用场景。前端团队只需要关心语言语义到 IR 的翻译优化团队只需要关心 IR 变换的数学与算法性质后端团队只需要关心硬件特性。三个团队在 IR 这个边界上汇合彼此几乎不需要了解对方领域的全部细节。这个设计在工业界产生了巨大的实际价值。一个创业公司想做一门新语言如果从零写编译器可能耗费数年但如果借助 LLVM前端完成到 IR 之后优化和后端能力直接就位。这也是为什么今天几乎所有新兴系统语言都选择 LLVM 作为后端引擎。2. 把 llvm-project 拉到本地版本选择、目录结构与构建配置的实战经验理论说完进入实操环节。无论你想给 LLVM 贡献代码还是想基于它做二次开发第一步都是把 llvm-project 仓库拉到本地并完成构建。这一步看似简单实际上版本选择、磁盘空间、构建时长、CMake 参数配置都会影响你的后续效率。2.1 克隆仓库与版本选择策略官方仓库托管在 GitHub 上地址是 llvm/llvm-project。仓库非常庞大完整克隆包含全部历史记录体积超过 1GB如果你只想要最近的快照建议用--depth参数做浅克隆git clone --depth1 --branch llvmorg-15.0.7 https://github.com/llvm/llvm-project.git我需要特别提醒版本选择的问题。很多初学者直接跟踪 main 分支这其实会给学习带来很大困扰因为 main 分支处于持续开发状态某个 API 可能这周还是这样用下周就变了。官方文档和网上大量教程基于的版本也不统一你在编译时报错后去搜索引擎找答案很可能找到的解法不适用于你的版本。建议学习和做实验时选择一个稳定的 release 版本比如 15.0.7等把整个流程跑通了再决定是否跟进 main 分支。克隆完成后你会看到仓库下有这些核心子目录llvm/主体代码包括 IR 定义、优化 Pass、后端框架、通用工具clang/C/C/Objective-C 前端lld/链接器compiler-rt/运行时库用于 sanitizer、profile 等功能libcxx/、libcxxabi/、libunwind/C 标准库实现mlir/MLIR 框架用于构建可扩展的编译基础设施flang/、polly/、openmp/其他子项目这些子项目可以独立构建也可以在同一个 CMake 项目中统一构建。第一次建议只构建核心的llvm和clang把其他子项目关掉能大幅缩短编译时间。2.2 CMake 配置的关键参数与坑点LLVM 使用 CMake 构建配置命令可以在llvm/CMakeLists.txt基础上进行。下面这是我实测下来比较合理的一份配置cmake -G Ninja \ -DCMAKE_BUILD_TYPERelease \ -DLLVM_ENABLE_PROJECTSclang;lld \ -DLLVM_TARGETS_TO_BUILDX86;RISCV \ -DLLVM_INSTALL_UTILSON \ -DCMAKE_INSTALL_PREFIX$HOME/llvm-15.0.7 \ ../llvm-project/llvm逐一说明这些参数的意义。-G Ninja比默认的 Unix Makefiles 快得多并行性好强烈建议用。-DCMAKE_BUILD_TYPERelease决定优化等级如果你要做开发调试这个要改成Debug或RelWithDebInfo但代价是编译时间和生成的二进制体积都会显著增加。-DLLVM_ENABLE_PROJECTS决定除了核心 LLVM 之外还要构建哪些子项目这里我用的是clang;lld。-DLLVM_TARGETS_TO_BUILD可以大大缩短构建时间的选项默认编译所有架构后端会消耗大量时间建议只保留你需要的X86;RISCV。-DCMAKE_INSTALL_PREFIX设置安装路径方便后续使用。这里有一个非常隐蔽的坑LLVM_ENABLE_PROJECTS和LLVM_EXTERNAL_PROJECTS有时候容易混淆前者用于仓库内构建后者用于外部独立项目。如果你用错了CMake 配置阶段可能不会报错但实际构建时不会包含你想构建的组件。还有一个容易忽略但影响实际使用体验的参数是LLVM_INSTALL_UTILS。把它设为 ON 后llvm-config、llvm-lit这些工具会一并安装后续跑测试或者用 CMake 引用 LLVM 库都会省事很多。2.3 一次完整的构建过程与耗时预期配置完成后执行构建ninja这个命令会全量编译。我个人的经验是在 8 核 16 线程的机器上Release 模式、只构建 X86 和 RISC-V 后端的前提下首次全量构建 LLVM 和 Clang 大约需要 40~60 分钟。如果你是在服务器上构建可以先cmake --build . --target llvm-config只构建某个工具链速度会快很多。如果你用默认的 Makefile 而不是 Ninja并行编译记得make -j$(nproc)否则会串行执行几个小时都不一定跑得完。构建完成后ninja install会把产物安装到上面设置的CMAKE_INSTALL_PREFIX路径下。验证安装是否成功$HOME/llvm-15.0.7/bin/clang --version看到版本信息后一个基础的 LLVM 工具链就准备好了。2.4 Debug 模式与开发调试场景的特殊配置如果你打算阅读 LLVM 源码、写 Pass 或者参与开发Release 模式并不合适。建议单独为开发创建一个构建目录使用 Debug 模式cmake -G Ninja \ -DCMAKE_BUILD_TYPEDebug \ -DLLVM_ENABLE_PROJECTSclang \ -DLLVM_TARGETS_TO_BUILDX86 \ -DLLVM_OPTIMIZED_TABLEGENON \ ../llvm-project/llvm注意最后这个LLVM_OPTIMIZED_TABLEGENON它的作用是先用 Release 模式构建 TableGen 工具再用它们去生成 Debug 版本的代码能显著减少 Debug 构建的等待时间。如果没有这个参数Debug 模式下的 TableGen 运行速度会慢到怀疑人生。Debug 模式下断言、调试信息都是开启的编译期错误信息更丰富但二进制体积大、运行速度慢。如果你只是想跑一下测试不建议用 Debug。3. 从引擎盖下看 IR 的真实结构使用 llvm-as、llvm-dis 与 opt 驱动调试流程安装完 LLVM 之后大多数人会迫不及待想写一个 Pass或者至少看看 IR 长什么样。IR 是整个编译器中端和后端的数据出入口理解 IR 的形态是深入 LLVM 的基础。3.1 IR 的三种形态LLVM IR 有三种等价的表示形态内存中的数据结构、可读的文本形式.ll文件和二进制位码形式.bc文件。文本形式适合人阅读和调试二进制形式适合存储和传输。clang 可以直接生成 IR 文本cat hello.c EOF #include stdio.h int add(int a, int b) { return a b; } int main() { printf(%d\n, add(1, 2)); return 0; } EOF clang -S -emit-llvm hello.c -o hello.ll打开hello.ll你会看到一段类似这样的内容节选define i32 add(i32 %a, i32 %b) { entry: %add add nsw i32 %a, %b ret i32 %add }define i32 add(i32 %a, i32 %b)定义了一个返回 32 位整数、接收两个 32 位整数参数的函数%add是虚拟寄存器名字代表%a %b的结果nsw是 no signed wrap 的标志表示这个加法不允许有符号溢出这个标志为后续优化提供额外信息。3.2 用 opt 运行单条优化指令观察效果opt是 LLVM 中一个看似简单却极为强大的工具它允许你对 IR 文件运行一个或多个 Pass观察 IR 的变换过程。例如删除死代码opt -passesdce hello.ll -S -o hello_dce.ll对比前后内容你会看到main中一些无用的计算被移除。-passesdce指定了要跑的 Pass-S表示输出文本形式-o指定输出文件。不同版本的 opt 在 Pass 名称上有变化。旧版用-dce新版用-passesdce前者是 legacy 接口后者是新 Pass 接口。LLVM 15 已经对 legacy pass 大幅收紧了后面写自定义 Pass 时很可能需要直接使用新接口。再试一个更直观的优化常量传播。define i32 test() { %a add i32 1, 2 ret i32 %a }保存为const.ll运行opt -passesconstprop const.ll -S你会发现%a add i32 1, 2被替换成了3。这个保存为const.ll的示例文件就是最小化的 IR 样例非常适合学习 Pass 的行为。3.3 用 llc 观察指令选择的最终产物llc负责把 IR 降级为汇编代码。在跨平台或者嵌入式场景下通常用它查看不同后端的输出llc hello.ll -o hello.s查看生成的汇编你能看到%add对应的机器指令。如果想观察不同后端的行为可以加-marchriscv64llc hello.ll -marchriscv64 -o hello_riscv.s用同一份 IR 在不同架构之间切换输出是理解 LLVM 后端的一个窗口。机器码生成质量的差异既取决于 IR 是否包含足够的语义信息也取决于后端描述文件是否精细。3.4 自定义一个极简 Pass从零到跑通写一个自定义的 LLVM Pass 是很多人学习 LLVM 的第一步。在当前版本中推荐方式是使用 New Pass Manager 接口。下面这个示例展示如何写一个简单的模块级打印 Pass#include llvm/IR/Function.h #include llvm/IR/Module.h #include llvm/Pass.h #include llvm/Passes/PassBuilder.h #include llvm/Passes/PassPlugin.h using namespace llvm; namespace { struct HelloPass : public PassInfoMixinHelloPass { PreservedAnalyses run(Module M, ModuleAnalysisManager MAM) { for (auto F : M) { if (!F.isDeclaration()) { errs() Hello from: F.getName() \n; } } return PreservedAnalyses::all(); } }; } // namespace extern C ::llvm::PassPluginLibraryInfo LLVM_ATTRIBUTE_WEAK llvmGetPassPluginInfo() { return { LLVM_PLUGIN_API_VERSION, HelloPass, LLVM_VERSION_STRING, [](PassBuilder PB) { PB.registerPipelineParsingCallback( [](StringRef Name, ModulePassManager MPM, ArrayRefPassBuilder::PipelineElement) { if (Name hello-pass) { MPM.addPass(HelloPass()); return true; } return false; }); }}; }编译这个 Pass 需要链接 LLVM 库通常会通过 CMake 处理。核心就是注册一个PassPlugin并告诉 PassBuilder 在遇到hello-pass这个名称时创建对应的 Pass。运行方式opt -load-pass-plugin./libHelloPass.so -passeshello-pass hello.ll -S这里有一个常见认知误区新 Pass 架构下插件名称不固定为全小写就是合法的必须和注册时的字符串完全匹配。如果插件加载成功但 Pass 没跑优先排查注册字符串是否一致。4. 从 IR 到机器码的后端征程指令选择的两大策略与 llvmpipe 的软件渲染真相理解 LLVM 后端是怎么工作的比单纯跑几个命令有意思得多。后端工作的第一步是指令选择——把 IR 中平台无关的操作映射为平台相关的指令序列。这一步骤在不做任何优化的情况下也绕不开因为 LLVM IR 里的加法和目标机器的加法指令并不是一一对应的有些机器支持直接对内存操作数做加法有些必须先加载到寄存器有些机器有独立的浮点寄存器堆有些则复用通用寄存器。4.1 有向无环图覆盖与 SelectionDAG传统方法是把 IR 转换为 SelectionDAG这是一个有向无环图节点是操作边是数据依赖。指令选择就变成在 DAG 上找到一组匹配模式用目标指令覆盖尽可能多的节点。这种方式能做很多精细的优化比如模式匹配到乘加合并指令或者在一条指令里同时完成加载和算术操作。它的缺点是速度慢因为图覆盖本质上是复杂的组合搜索而且生成的代码难以预测。4.2 全球指令选择更快的路线为了解决 SelectionDAG 的性能问题LLVM 引入了 GlobalISel。它采用更直接的逐步匹配方式先把 IR 泛化为机器指令这一步几乎不做复杂匹配然后再通过多个小的 Pass 逐步降低机器指令的抽象程度最终变成可被指令选择器匹配的形式。实际效果对比在早期实现中GlobalISel 生成的代码质量比 SelectionDAG 低 5%~10%但随着版本迭代这个差距在缩小尤其是针对 AArch64 架构已经比较成熟。llc默认选择哪种方案可以通过-fast-isel或-global-isel等参数控制。如果你做交叉编译且编译器编译速度是瓶颈可以尝试 GlobalISel如果追求最终代码质量SelectionDAG 仍是更稳固的选择。4.3 llvmpipe一个用 LLVM IR 做软件光栅化的极致示例前面说的都是编译器后端但 LLVM 的用途远不止编译源码。Mesa 项目中的llvmpipe就是一个软件渲染器它把图形管线的着色器编译成 LLVM IR然后交给 LLVM 的 JIT 引擎生成当前 CPU 的机器码用 SIMD 指令比如 AVX2、AVX-512去并行处理像素或顶点。我在用 llvmpipe 跑开源渲染测试时关注到的一个细节是llvmpipe 的运行时信息里能看到类似LLVM 15.0.7的版本号以及它使用的向量位宽信息。这意味着它确实把 LLVM 当作一个运行时编译引擎而不是仅仅在构建期使用。llvmpipe 为什么用 LLVM因为它要面对大量不同的着色器组合如果为每种组合都写手工汇编工作量是不可想象的。通过 LLVM JIT它可以按需把着色器程序编译成当前 CPU 的指令那是通用的做法能在性能与可维护性之间取得一个很好的平衡。LLVM 从头到尾参与源码编译和运行时 JIT这样一个理念现在非常普及。苹果的 Metal 3、很多机器学习推理引擎、数据库执行引擎都采用类似思路把热点路径编译成机器码来换取性能。4.4 后端的寄存器分配一个容易忽略但影响巨大的环节指令选择之后是寄存器分配它决定哪些虚拟寄存器使用物理寄存器、哪些溢出到栈上。LLVM 的默认分配器是 Greedy Register Allocator。它在处理大型函数、大量虚拟寄存器时需要在复杂度和分配质量之间做取舍。如果你的自定义后端出现莫名性能下降先别急着改指令选择描述用llc -debug-onlyregalloc看一下寄存器分配的 dump往往能直接定位问题——比如某个临时变量的生命周期过长导致缓存压力过大。5. 工具链家族的其他成员lld、compiler-rt 与 MLIR 让 llvm-project 不再只是编译器很多人以为 llvm-project 就是 Clang 加优化器其实项目的版图远不止此。真正让 llvm-project 成为一个工具链全家桶的是 lld、compiler-rt、MLIR 这些围绕 IR 构建的子项目。5.1 lld现代链接器的标杆链接器常常被忽视但链接速度快慢直接影响大型项目的构建体验。lld 的设计目标是内聚、快速、内存占用可控。它支持 ELF、Mach-O、COFF、Wasm 等多种格式并且很多地方利用了并行处理。我实测下来一个中等规模 C 项目使用默认的 GNU ld 链接耗时比 lld 多出不少切换后明显感受到构建时间缩短。启用方式很简单clang -fuse-ldlld hello.c -o hello如果你想深入体验 lld 的处理器可以试试ld.lld --time-trace它会生成 Chrome trace 格式的时间分析文件让你直观看到链接过程的每一段耗时。对于大型商业项目这个数据非常有决策价值。5.2 compiler-rtsanitizer 背后的运行时compiler-rt 是一个容易被忽略但日常开发离不开的子项目。AddressSanitizer、UndefinedBehaviorSanitizer、ThreadSanitizer 这些工具运行时都来自这里。它们不依赖特定的操作系统库因此可以用于交叉编译和嵌入式环境。使用方式clang -fsanitizeaddress hello.c -o hello_asan ./hello_asan一旦有内存越界、use-after-free 等问题ASan 会给出详细报告。相比 valgrindASan 的性能开销低得多可以作为 CI 流程的常规检查项。5.3 MLIR一种构建编译器的编译器MLIR 是 LLVM 社区近年来引入的一个子项目全称是 Multi-Level Intermediate Representation。它试图解决的核心问题是某些领域如机器学习、HPC需要多层级抽象同时需要在不同层级上做优化。MLIR 允许你定义自己的方言这些方言可以分层级从高层语义逐步降低到 LLVM IR。我有一次想对一个数据流图做自定义优化如果直接用 LLVM IR优化逻辑会非常别扭因为 IR 层级太低了没法表达这是一个张量算子这种高层概念。但如果用 MLIR 定义一个小型方言在方言层做变换最后再 lower 到 LLVM IR整个过程优雅很多。MLIR 的学习曲线比普通 LLVM 开发更陡但它解决的是传统编译器框架难以处理的扩展性问题。如果你要做领域专用编译基础设施MLIR 值得投入时间研究。5.4 Flang 与 OpenMP补齐更多语言和应用拼图flang为 Fortran 提供了 LLVM 前端支持让老牌科学计算语言也能吃到 LLVM 的优化。openmp子项目实现了 OpenMP 运行时库支持 offload 到 GPU 等异构设备。今天很多高性能计算项目正是以 LLVM 工具链为底座组合使用这些组件。如果你的工作涉及 HPC 或者异构计算这些子项目和 LLVM 主体是协同工作的而不是孤立的存在。6. 如果想啃源码从哪个文件切入如何调试和避开无头苍蝇式阅读LLVM 源码库非常庞大想通读几乎不可能绝大多数工程师也是带着具体问题去读的。但带着问题读和全然没有方向地乱翻效率差别很大。6.1 找入口读代码最有效的方式是跟随一条管线学习源码最佳路径是追踪一条真实的数据流。比如从 Clang 入口开始看clang/lib/CodeGen/CodeGenAction.cpp它会调用 AST 生成 IR然后追踪 IR 如何经过优化管线最终到后端。这条链路把前端、中端、后端串起来是理解全貌最好的方式。对后端感兴趣可以读llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp这是传统指令选择的核心逻辑所在对优化管线感兴趣可以读llvm/lib/Passes/PassBuilder.cpp里的buildPerModuleDefaultPipeline定义了默认优化等级的 Pass 组合。6.2 利用 assert 和调试输出LLVM 内部大量的assert和LLVM_DEBUG宏是调试的线索。你可能会看到类似下面的代码LLVM_DEBUG(dbgs() Processing instruction: I \n);这些输出默认是关闭的需要用-debug参数或者环境变量打开。例如opt -passesloop-unroll -debug-onlyloop-unroll myfile.ll -S-debug-only可以根据不同的调试分类筛选输出避免被海量日志淹没。Debug 构建模式下这些信息更加完整这也是我前面强调要单独准备一个 Debug 构建目录的原因。6.3 小步改造跑测试验证读源码的理想状态是带着 issue 去读。比如你想了解某个 Pass 为什么不生效就在源码里打 log 看完整执行路径。每一次修改后都建议用ninja check或llvm-lit跑相关测试例如llvm-lit -sv test/Transforms/LoopUnroll测试框架会验证你的改动是否符合预期。在 LLVM 生态中没有测试伴随的修改很难评估影响面也很容易在后续集成中埋下隐患。6.4 关于 LLVM 社区协作的一点经验如果阅读过程中遇到无法解决的问题Stack Overflow 和 LLVM Discourse 是很好的求助渠道。但提问前建议准备好最小复现用例一个能触发问题的hello.ll文件、运行的opt或llc命令、LLVM 版本号。LLVM 社区对帮我 debug这类空泛提问不太耐心但对提供了完整复现步骤的 issue 通常响应很快。7. 向量化与 SIMD 语境中的 LLVM256-bit 位宽、llvmpipe 日志与真实性能调优很多人在网络检索中会因为llvmpipe出现256 bits这样的字符串而好奇 LLVM 与 SIMD 的关系。这部分我展开讲讲因为它既是理解 LLVM 后端优化级别的窗口也是实际性能调优经常打交道的区域。7.1 IR 里的向量类型与自动向量化LLVM IR 支持向量类型比如8 x float代表 8 个 float 组成的向量。当你写出适合向量化的循环时优化器有机会把它转成 SIMD 指令。比如在 X86 平台上一个处理 8 个 float 的循环可能会被翻译成一条使用 YMM 寄存器256 位宽度的指令。自动向量化有两种方式循环向量化它检测循环体内没有循环迭代间的依赖时将一个迭代处理一个元素改成同时处理多个元素SLP 向量化它在基本块内发现多条独立标量指令可以合并为向量计算时进行合并。前者更适合简单的数值循环后者更适合结构体数组或多字段计算场景。7.2 查看向量化信息与 llvmpipe 日志的关联用 clang 查看某段代码是否会被向量化可以加-Rpassloop-vectorize系列的选项相关做法通常有clang -O3 -marchnative -Rpassloop-vectorize -Rpass-missedloop-vectorize vec.c这样会注明哪些循环被向量化、哪些没有以及理由。-marchnative让编译器根据当前 CPU 的特性生成指令这是做性能调优时常用的参数能让自动向量化发挥更充分的功效。如果你看到提示说无法证明循环无依赖或者循环结构不适合向量化就需要在代码层面进行调整比如手动拆分循环或者引入断言让别名分析更准确。当我们看到 llvmpipe 日志中的256 bits时往往意味着 LLVM 后端确实生成了 AVX2 或 AVX-512 的向量指令来加速像素处理也就是这里的256 bit代表向量寄存器的位宽。在渲染繁忙的帧中这种向量化带来的加速非常可观。7.3 向量寄存器的历史包袱与性能陷阱引入 256 位指令时有一个众所周知的性能陷阱早期 AVX 实现中上下文的切换和频率调节会导致在 256 位 AVX 指令和寄存器间切换时产生惩罚效应。虽然新的微架构缓解了大部分问题但在密集计算场景中用 SIMD 指令就一定快仍然是不成立的。因为启用向量化意味着更多寄存器占用、潜在的内存对齐要求、指令解码带宽消耗。实际性能测试需要以基准数据为准而不是只看指令条数。我调优性能时的经验是先用perf stat采集指令数、周期、缓存命中率再对热点函数用objdump -d或llvm-objdump检查生成的汇编确认是否真正生成了预期的向量指令并合理利用了寄存器资源。很多时候编译器生成的向量代码和手写 SIMD 有差距但可读性和维护性优势明显——这也是 LLVM 的价值所在它能帮你用更安全的抽象逼近高性能。7.4 跨平台向量化的可移植性问题在不同 CPU 上向量宽度和指令集是不同的。LLVM 的解决方案是靠 target-specific 的 intrinsic 和 target-independent 的向量类型结合。4 x float映射到 ARM NEON 是 128 位映射到 AVX2 是 128 位相同源码可以移植到不同平台算力发挥取决于平台宽度。如果你的代码依赖固定宽度比如必须跑 512 位指令x86 的 AVX-512 与 ARM 的 SVE 是差异明显的需要额外处理。LLVM 提供了target属性的方式去声明函数希望使用的指令集或者用__attribute__((target(avx512f)))在函数粒度控制生成策略适合需要精细控制性能的场景。8. 从学习到生产力不同岗位怎么用好 llvm-project很多刚开始接触的人会被LLVM 太大了劝退但其实不用全学。根据自己的具体工作场景挑对应的模块下手完全可以边做边学在实践里成长。8.1 如果你是语言实现者你在实现一门新语言目标是生成本地代码。建议直接看 Kaleidoscope 教程它是 LLVM 官方教程虽然基于旧版 API但核心思路没变先用 ORC JIT 跑通解释执行再用 MCJIT 或 ORC 编译为本地代码最后接入 Clang 做 ABI 层的互操作。重点学习IRBuilder的用法和模块/函数/基本块的组织方式。这个教程建议配合官方 LLVM IR 语言参考阅读遇到不理解的指令就查文档。做完一遍后会形成比较完整的心智模型。8.2 如果你做基础设施或者工具链那大概率需要把 Clang、lld、compiler-rt 组合在一起使用。你的目标不是从零写编译器而是定制工具链行为比如修改代码生成策略、定制 sanitizer 钩子、接入新的链接节。在这个场景下理解 llvm-project 的模块边界更重要。比如你想给某种新硬件提供一个完整的交叉编译工具链需要关注LLVM_TARGETS_TO_BUILD与 sysroot 的定义用 clang 的--target参数完成配置文件切换。工具链的每个部分都是可拆开的这种组合能力对产品落地有很大价值。8.3 如果你是做 HPC 或图形/深度学习方向的工程师如果你是数据密集计算相关方向的工程师你的关注点可能在自动向量化、循环优化、GPU offload、MLIR 这些更高层的抽象能力上。这类背景下重点不要花太多时间在深入 C 源码以及底层代码生成而是先学会用opt、llc、llvm-mca这些工具分析自己的性能瓶颈。llvm-mca是一个很有意思的工具它可以做一个静态的性能分析——不需要真正运行程序就能基于指令调度模型预测执行吞吐量。写汇编优化的人经常用到它。8.4 如果你是学生或者研究者做研究的人有得天独厚的优势可以放慢速度去读论文和源码交叉验证。比如研究指令选择算法可以把 SelectionDAG 的代码和论文对应着读。一个重要建议把 LLVM 当作一个实验平台而不是一个待破解的黑盒。每个结论都要用工具验证比如对 IR 跑变换、对汇编做性能测试、对目标平台做扫描。研究型工作最大的优势是可以沉下心看细节LLVM 提供了完整的可见性是编译器领域做实验的好土壤。9. 版本演进视角从 LLVM 15.0.7 观察项目长期稳定的架构模式版本号本身没有特殊性但通过一个特定的 Release 版本可以看出 LLVM 项目的演进节奏和工程管理方式。LLVM 以半年为节奏发布主要版本每个版本都有明确的新特性列表和兼容性说明。9.1 Release 分支哲学稳定与激进并存LLVM 在开发期很激进API 频繁变化但一到 Release 周期变更会全部冻结进入测试和 bug 修复阶段。这也解释了为什么用 main 分支跑生产项目不是好主意。选择 release 版本来学习、部署是一个可靠的生产策略。15.0.7 作为 15 系列的修复版本集成了若干 bug 修复属于那个周期里很稳定的一个点。9.2 新 Pass 架构的推进与新开发的兼容性思考围绕 LLVM 15新 Pass 架构已经非常成熟legacy Pass 处于淘汰边缘。如果你在参考某本旧书籍或旧博客注意区分代码的时间和 API 版本。新 Pass 的主要好处是更好的并行分析能力和简化的 API 边界这也是 LLVM 为了适应多线程编译场景做出的架构调整。如果你编写自定义 Pass建议从一开始就使用新 Pass 接口避免在 legacy 和新框架之间做无效迁移。9.3 互相引用历史版本资料时的坑这么多年来网上积累了海量的 LLVM 教程但很多教程里出现的 API 已面目全非。最典型的是 Pass 注册宏从RegisterPass到PassRegistry再到llvmGetPassPluginInfo差异很大。看教程时先看它的发布日期和 LLVM 版本如果不是针对你当前版本先不要直接抄写代码而是去当时版本的文档或源码里确认 API 是否仍然适用。10. 写代码之外社区协作、贡献流程与学习资源的实用建议最后说一些代码以外但长期受益的经验。10.1 贡献代码的正确打开方式如果想给 LLVM 贡献代码建议遵循官方贡献指南的流程。第一步往往不是提交代码而是先上 Discourse 或 GitHub issue 讨论设计。LLVM 社区对架构有很强的把关意识一个 pass 的设计如果和现有架构不一致即使代码正确也可能被要求大幅调整。代码风格方面LLVM 用clang-format统一格式提交前运行git-clang-format可以省去很多 review 反复。代码的所有权意识和模块责任人的把关对长期项目质量至关重要。10.2 必须收藏的资源列表LLVM Language Reference ManualIR 语法的权威定义常查常新。LLVM Developer Policy理解了它才能理解社区的很多决策逻辑。LLVM Weekly每周更新的社区资讯汇总能帮你跟踪生态动态。Stack Overflow 的 llvm 标签查排错思路效率高但提问前先确认版本。各种会议的视频如 LLVM Developers Meeting信息密度很高适合过渡阶段快速提升。10.3 学习路径的节奏控制我的建议是不要一口气想掌握全部模块。先用几天时间把 IR 语法和 opt 工具玩熟再花一周做一个简单的自定义 Pass之后根据需求接触 Clang、lld 或 MLIR。每深入一个模块都会反过来加深你对 LLVM 整体架构的认识这种感觉和单纯的文档阅读完全不是一回事。如果遇到卡点很多情况不是你的思路有问题而是版本差异或上下文信息缺失。先记录现象、复现最小案例、对照源码逻辑90% 的问题可以这样解决。剩下 10% 再去社区提问带着完整上下文的问题被认真回答的概率会大很多。从我自己的经历来说接触 LLVM 的初期是最容易被它就是编译器这个定式给限制住的。真正开始用它 JIT 渲染、做领域编译器、搭工具链之后才发现 LLVM 不只是一个程序而是一整套让编译器变得可以像积木一样灵活搭建的基础设施。现在回看从第一份 Release 构建到慢慢读通 IR、写完一个可以在opt中加载的 Pass这条路其实并没有想象中那么难。LLVM 这个项目最迷人的地方在于它把一个复杂到极致的系统切分成了清晰的模块每个模块都能独立演进又通过 IR 这个接口彼此连接。先用起来、再读代码、再深入设计每一步都有新东西可挖。这篇文章写到这里其实更想传达到的是LLVM 没那么遥不可及它更像一套开放的积木每个人都能找到自己需要的那几块拼出自己的解决方案。 LLVM项目深度解析：从IR到后端的编译器基础设施实战指南
如果你在编译器、编程语言或高性能计算相关领域工作那么你对 LLVM 这个名字一定不陌生。但如果有人问起LLVM 项目到底是什么很多人的第一反应是它是一个编译器。这个说法不算错但远远不够。LLVM 是一个模块化的编译器基础设施是一整套工具链和库的集合它改变了编译器的构建方式。早期它只是伊利诺伊大学的一个研究项目目标是提供一种静态单赋值形式的中间表示让优化和分析变得更简单。后来这个架构被证明极具生命力Clang、LLD、MLIR 等子项目陆续加入让 LLVM 从一个学术原型长成了今天几乎统治了工具链底层生态的基础设施。我最初接触 LLVM 是因为工作需要把一套内部 DSL 编译到不同架构上当时翻了很多文档踩了不少坑后来逐渐整理出了自己的学习路径。这篇内容不打算写成官方文档的复述而是想从一个实际使用者的角度把 LLVM 这个庞大项目剖开讲讲它的核心模块、构建方式、实战要点以及那些文档里不会明说的经验。无论是刚入门的学生、做语言前端的工程师还是想用 LLVM 加速计算管线的研究者应该都能在这里找到一些有用的线索。需要说明一点LLVM 的演进速度很快主分支几乎每天都在变。本文基于 LLVM 15.0.7 时代形成的结构来描述后续版本在细节上会有调整但整体架构和设计思路是稳定连贯的。1. 用一个具体问题理解 LLVM 的架构逻辑为什么它能通吃所有语言想理解 LLVM最好的方式不是背诵模块名而是回答一个问题为什么 C、Rust、Swift、Julia 这些语法风格差异巨大的语言最终都能靠同一套优化和后端跑出高效机器码答案藏在中间表示这个分层设计里。LLVM 的核心抽象叫 LLVM IR它是一种低层次但仍是人类可读的中间语言。它的设计目标是既保留足够的语义信息来做优化比如类型信息、控制流结构、内存访问模式又足够接近机器层面让后端可以做真实的指令选择与寄存器分配。这套架构可以简单归纳为三段流水线语言前端把源码翻译成 IR中端优化器对 IR 做一轮又一轮的变换后端再把 IR 映射成目标机器的指令。1.1 前端Clang 只是其中一员提到 LLVM 的前端大多数人第一个想到的是 Clang。Clang 负责解析 C/C/Objective-C 源码生成 AST再逐步降级到 LLVM IR。它和 GCC 的最大差异在于Clang 的架构是库化的解析器、语义分析器、代码生成器都可以作为库被嵌入其他工具这让 IDE 的代码补全、静态检查工具、重构工具都能复用同一套前端逻辑而不是各自写一套解析器。但不是所有语言都走 Clang。Rust 用的是 rustc 内置的前端Swift 用 swiftcJulia 在早期版本自己生成 LLVM IR。LLVM 并不关心你的源码长什么样只要你最终能把语义翻译成合法的 IR就能接入整套优化与后端。1.2 中端Pass 管线和优化策略IR 进入中端后会经过一个被称为 Pass 管线的过程。每个 Pass 都是一次对 IR 的变换或分析比如死代码消除、循环展开、内联、常量传播。这些 Pass 以固定顺序执行每一轮变换都让 IR 更接近高效的机器代码。有趣的是Pass 管线的顺序本身就是一门学问。内联太早可能导致代码膨胀太晚又可能错过其他优化机会循环优化通常放在后期因为它依赖前面的分析结果。LLVM 默认提供几套优化等级-O0、-O1、-O2、-O3、-Os它们背后就是不同的 Pass 组合。你可以把 Pass 理解为一个个可以插拔的功能卡。编译器工程师的一大工作就是决定在哪种优化等级下挂载哪些 Pass以及它们的执行顺序。这也是为什么有些 CPU 平台会专门开启或关闭某些 Pass——优化策略和硬件特性之间有很强的耦合。1.3 后端目标描述文件驱动代码生成后端是 LLVM 中最魔法的部分。它负责两件事指令选择把 IR 指令映射为目标机器的具体指令和寄存器分配把虚拟寄存器映射到物理寄存器。这两件事都高度依赖目标平台但 LLVM 通过 TableGen 语言把平台描述数据和编译器逻辑分离开。具体来说后端工程师会用 TableGen 描述一款 CPU 的指令集、寄存器文件、指令编码格式、调度模型。LLVM 的工具链会从这些描述中生成 C 代码形成指令选择器、汇编器、反汇编器。这意味着如果你要为一个新的 CPU 架构提供 LLVM 支持你不需要重写整个编译器而是写一套描述文件再补上一些特殊的定制逻辑。这种设计也让 LLVM 能快速支持新平台。RISC-V 就是一个典型案例从规范发布到 LLVM 提供较完整的后端支持时间非常短因为大部分代码生成逻辑是通用的只需要填写新架构的硬件信息。1.4 组件之间的边界是 LLVM 最伟大的设计至此你应该已经理解了 LLVM 的价值它不绑定任何语言、不绑定任何 CPU、甚至不绑定任何应用场景。前端团队只需要关心语言语义到 IR 的翻译优化团队只需要关心 IR 变换的数学与算法性质后端团队只需要关心硬件特性。三个团队在 IR 这个边界上汇合彼此几乎不需要了解对方领域的全部细节。这个设计在工业界产生了巨大的实际价值。一个创业公司想做一门新语言如果从零写编译器可能耗费数年但如果借助 LLVM前端完成到 IR 之后优化和后端能力直接就位。这也是为什么今天几乎所有新兴系统语言都选择 LLVM 作为后端引擎。2. 把 llvm-project 拉到本地版本选择、目录结构与构建配置的实战经验理论说完进入实操环节。无论你想给 LLVM 贡献代码还是想基于它做二次开发第一步都是把 llvm-project 仓库拉到本地并完成构建。这一步看似简单实际上版本选择、磁盘空间、构建时长、CMake 参数配置都会影响你的后续效率。2.1 克隆仓库与版本选择策略官方仓库托管在 GitHub 上地址是 llvm/llvm-project。仓库非常庞大完整克隆包含全部历史记录体积超过 1GB如果你只想要最近的快照建议用--depth参数做浅克隆git clone --depth1 --branch llvmorg-15.0.7 https://github.com/llvm/llvm-project.git我需要特别提醒版本选择的问题。很多初学者直接跟踪 main 分支这其实会给学习带来很大困扰因为 main 分支处于持续开发状态某个 API 可能这周还是这样用下周就变了。官方文档和网上大量教程基于的版本也不统一你在编译时报错后去搜索引擎找答案很可能找到的解法不适用于你的版本。建议学习和做实验时选择一个稳定的 release 版本比如 15.0.7等把整个流程跑通了再决定是否跟进 main 分支。克隆完成后你会看到仓库下有这些核心子目录llvm/主体代码包括 IR 定义、优化 Pass、后端框架、通用工具clang/C/C/Objective-C 前端lld/链接器compiler-rt/运行时库用于 sanitizer、profile 等功能libcxx/、libcxxabi/、libunwind/C 标准库实现mlir/MLIR 框架用于构建可扩展的编译基础设施flang/、polly/、openmp/其他子项目这些子项目可以独立构建也可以在同一个 CMake 项目中统一构建。第一次建议只构建核心的llvm和clang把其他子项目关掉能大幅缩短编译时间。2.2 CMake 配置的关键参数与坑点LLVM 使用 CMake 构建配置命令可以在llvm/CMakeLists.txt基础上进行。下面这是我实测下来比较合理的一份配置cmake -G Ninja \ -DCMAKE_BUILD_TYPERelease \ -DLLVM_ENABLE_PROJECTSclang;lld \ -DLLVM_TARGETS_TO_BUILDX86;RISCV \ -DLLVM_INSTALL_UTILSON \ -DCMAKE_INSTALL_PREFIX$HOME/llvm-15.0.7 \ ../llvm-project/llvm逐一说明这些参数的意义。-G Ninja比默认的 Unix Makefiles 快得多并行性好强烈建议用。-DCMAKE_BUILD_TYPERelease决定优化等级如果你要做开发调试这个要改成Debug或RelWithDebInfo但代价是编译时间和生成的二进制体积都会显著增加。-DLLVM_ENABLE_PROJECTS决定除了核心 LLVM 之外还要构建哪些子项目这里我用的是clang;lld。-DLLVM_TARGETS_TO_BUILD可以大大缩短构建时间的选项默认编译所有架构后端会消耗大量时间建议只保留你需要的X86;RISCV。-DCMAKE_INSTALL_PREFIX设置安装路径方便后续使用。这里有一个非常隐蔽的坑LLVM_ENABLE_PROJECTS和LLVM_EXTERNAL_PROJECTS有时候容易混淆前者用于仓库内构建后者用于外部独立项目。如果你用错了CMake 配置阶段可能不会报错但实际构建时不会包含你想构建的组件。还有一个容易忽略但影响实际使用体验的参数是LLVM_INSTALL_UTILS。把它设为 ON 后llvm-config、llvm-lit这些工具会一并安装后续跑测试或者用 CMake 引用 LLVM 库都会省事很多。2.3 一次完整的构建过程与耗时预期配置完成后执行构建ninja这个命令会全量编译。我个人的经验是在 8 核 16 线程的机器上Release 模式、只构建 X86 和 RISC-V 后端的前提下首次全量构建 LLVM 和 Clang 大约需要 40~60 分钟。如果你是在服务器上构建可以先cmake --build . --target llvm-config只构建某个工具链速度会快很多。如果你用默认的 Makefile 而不是 Ninja并行编译记得make -j$(nproc)否则会串行执行几个小时都不一定跑得完。构建完成后ninja install会把产物安装到上面设置的CMAKE_INSTALL_PREFIX路径下。验证安装是否成功$HOME/llvm-15.0.7/bin/clang --version看到版本信息后一个基础的 LLVM 工具链就准备好了。2.4 Debug 模式与开发调试场景的特殊配置如果你打算阅读 LLVM 源码、写 Pass 或者参与开发Release 模式并不合适。建议单独为开发创建一个构建目录使用 Debug 模式cmake -G Ninja \ -DCMAKE_BUILD_TYPEDebug \ -DLLVM_ENABLE_PROJECTSclang \ -DLLVM_TARGETS_TO_BUILDX86 \ -DLLVM_OPTIMIZED_TABLEGENON \ ../llvm-project/llvm注意最后这个LLVM_OPTIMIZED_TABLEGENON它的作用是先用 Release 模式构建 TableGen 工具再用它们去生成 Debug 版本的代码能显著减少 Debug 构建的等待时间。如果没有这个参数Debug 模式下的 TableGen 运行速度会慢到怀疑人生。Debug 模式下断言、调试信息都是开启的编译期错误信息更丰富但二进制体积大、运行速度慢。如果你只是想跑一下测试不建议用 Debug。3. 从引擎盖下看 IR 的真实结构使用 llvm-as、llvm-dis 与 opt 驱动调试流程安装完 LLVM 之后大多数人会迫不及待想写一个 Pass或者至少看看 IR 长什么样。IR 是整个编译器中端和后端的数据出入口理解 IR 的形态是深入 LLVM 的基础。3.1 IR 的三种形态LLVM IR 有三种等价的表示形态内存中的数据结构、可读的文本形式.ll文件和二进制位码形式.bc文件。文本形式适合人阅读和调试二进制形式适合存储和传输。clang 可以直接生成 IR 文本cat hello.c EOF #include stdio.h int add(int a, int b) { return a b; } int main() { printf(%d\n, add(1, 2)); return 0; } EOF clang -S -emit-llvm hello.c -o hello.ll打开hello.ll你会看到一段类似这样的内容节选define i32 add(i32 %a, i32 %b) { entry: %add add nsw i32 %a, %b ret i32 %add }define i32 add(i32 %a, i32 %b)定义了一个返回 32 位整数、接收两个 32 位整数参数的函数%add是虚拟寄存器名字代表%a %b的结果nsw是 no signed wrap 的标志表示这个加法不允许有符号溢出这个标志为后续优化提供额外信息。3.2 用 opt 运行单条优化指令观察效果opt是 LLVM 中一个看似简单却极为强大的工具它允许你对 IR 文件运行一个或多个 Pass观察 IR 的变换过程。例如删除死代码opt -passesdce hello.ll -S -o hello_dce.ll对比前后内容你会看到main中一些无用的计算被移除。-passesdce指定了要跑的 Pass-S表示输出文本形式-o指定输出文件。不同版本的 opt 在 Pass 名称上有变化。旧版用-dce新版用-passesdce前者是 legacy 接口后者是新 Pass 接口。LLVM 15 已经对 legacy pass 大幅收紧了后面写自定义 Pass 时很可能需要直接使用新接口。再试一个更直观的优化常量传播。define i32 test() { %a add i32 1, 2 ret i32 %a }保存为const.ll运行opt -passesconstprop const.ll -S你会发现%a add i32 1, 2被替换成了3。这个保存为const.ll的示例文件就是最小化的 IR 样例非常适合学习 Pass 的行为。3.3 用 llc 观察指令选择的最终产物llc负责把 IR 降级为汇编代码。在跨平台或者嵌入式场景下通常用它查看不同后端的输出llc hello.ll -o hello.s查看生成的汇编你能看到%add对应的机器指令。如果想观察不同后端的行为可以加-marchriscv64llc hello.ll -marchriscv64 -o hello_riscv.s用同一份 IR 在不同架构之间切换输出是理解 LLVM 后端的一个窗口。机器码生成质量的差异既取决于 IR 是否包含足够的语义信息也取决于后端描述文件是否精细。3.4 自定义一个极简 Pass从零到跑通写一个自定义的 LLVM Pass 是很多人学习 LLVM 的第一步。在当前版本中推荐方式是使用 New Pass Manager 接口。下面这个示例展示如何写一个简单的模块级打印 Pass#include llvm/IR/Function.h #include llvm/IR/Module.h #include llvm/Pass.h #include llvm/Passes/PassBuilder.h #include llvm/Passes/PassPlugin.h using namespace llvm; namespace { struct HelloPass : public PassInfoMixinHelloPass { PreservedAnalyses run(Module M, ModuleAnalysisManager MAM) { for (auto F : M) { if (!F.isDeclaration()) { errs() Hello from: F.getName() \n; } } return PreservedAnalyses::all(); } }; } // namespace extern C ::llvm::PassPluginLibraryInfo LLVM_ATTRIBUTE_WEAK llvmGetPassPluginInfo() { return { LLVM_PLUGIN_API_VERSION, HelloPass, LLVM_VERSION_STRING, [](PassBuilder PB) { PB.registerPipelineParsingCallback( [](StringRef Name, ModulePassManager MPM, ArrayRefPassBuilder::PipelineElement) { if (Name hello-pass) { MPM.addPass(HelloPass()); return true; } return false; }); }}; }编译这个 Pass 需要链接 LLVM 库通常会通过 CMake 处理。核心就是注册一个PassPlugin并告诉 PassBuilder 在遇到hello-pass这个名称时创建对应的 Pass。运行方式opt -load-pass-plugin./libHelloPass.so -passeshello-pass hello.ll -S这里有一个常见认知误区新 Pass 架构下插件名称不固定为全小写就是合法的必须和注册时的字符串完全匹配。如果插件加载成功但 Pass 没跑优先排查注册字符串是否一致。4. 从 IR 到机器码的后端征程指令选择的两大策略与 llvmpipe 的软件渲染真相理解 LLVM 后端是怎么工作的比单纯跑几个命令有意思得多。后端工作的第一步是指令选择——把 IR 中平台无关的操作映射为平台相关的指令序列。这一步骤在不做任何优化的情况下也绕不开因为 LLVM IR 里的加法和目标机器的加法指令并不是一一对应的有些机器支持直接对内存操作数做加法有些必须先加载到寄存器有些机器有独立的浮点寄存器堆有些则复用通用寄存器。4.1 有向无环图覆盖与 SelectionDAG传统方法是把 IR 转换为 SelectionDAG这是一个有向无环图节点是操作边是数据依赖。指令选择就变成在 DAG 上找到一组匹配模式用目标指令覆盖尽可能多的节点。这种方式能做很多精细的优化比如模式匹配到乘加合并指令或者在一条指令里同时完成加载和算术操作。它的缺点是速度慢因为图覆盖本质上是复杂的组合搜索而且生成的代码难以预测。4.2 全球指令选择更快的路线为了解决 SelectionDAG 的性能问题LLVM 引入了 GlobalISel。它采用更直接的逐步匹配方式先把 IR 泛化为机器指令这一步几乎不做复杂匹配然后再通过多个小的 Pass 逐步降低机器指令的抽象程度最终变成可被指令选择器匹配的形式。实际效果对比在早期实现中GlobalISel 生成的代码质量比 SelectionDAG 低 5%~10%但随着版本迭代这个差距在缩小尤其是针对 AArch64 架构已经比较成熟。llc默认选择哪种方案可以通过-fast-isel或-global-isel等参数控制。如果你做交叉编译且编译器编译速度是瓶颈可以尝试 GlobalISel如果追求最终代码质量SelectionDAG 仍是更稳固的选择。4.3 llvmpipe一个用 LLVM IR 做软件光栅化的极致示例前面说的都是编译器后端但 LLVM 的用途远不止编译源码。Mesa 项目中的llvmpipe就是一个软件渲染器它把图形管线的着色器编译成 LLVM IR然后交给 LLVM 的 JIT 引擎生成当前 CPU 的机器码用 SIMD 指令比如 AVX2、AVX-512去并行处理像素或顶点。我在用 llvmpipe 跑开源渲染测试时关注到的一个细节是llvmpipe 的运行时信息里能看到类似LLVM 15.0.7的版本号以及它使用的向量位宽信息。这意味着它确实把 LLVM 当作一个运行时编译引擎而不是仅仅在构建期使用。llvmpipe 为什么用 LLVM因为它要面对大量不同的着色器组合如果为每种组合都写手工汇编工作量是不可想象的。通过 LLVM JIT它可以按需把着色器程序编译成当前 CPU 的指令那是通用的做法能在性能与可维护性之间取得一个很好的平衡。LLVM 从头到尾参与源码编译和运行时 JIT这样一个理念现在非常普及。苹果的 Metal 3、很多机器学习推理引擎、数据库执行引擎都采用类似思路把热点路径编译成机器码来换取性能。4.4 后端的寄存器分配一个容易忽略但影响巨大的环节指令选择之后是寄存器分配它决定哪些虚拟寄存器使用物理寄存器、哪些溢出到栈上。LLVM 的默认分配器是 Greedy Register Allocator。它在处理大型函数、大量虚拟寄存器时需要在复杂度和分配质量之间做取舍。如果你的自定义后端出现莫名性能下降先别急着改指令选择描述用llc -debug-onlyregalloc看一下寄存器分配的 dump往往能直接定位问题——比如某个临时变量的生命周期过长导致缓存压力过大。5. 工具链家族的其他成员lld、compiler-rt 与 MLIR 让 llvm-project 不再只是编译器很多人以为 llvm-project 就是 Clang 加优化器其实项目的版图远不止此。真正让 llvm-project 成为一个工具链全家桶的是 lld、compiler-rt、MLIR 这些围绕 IR 构建的子项目。5.1 lld现代链接器的标杆链接器常常被忽视但链接速度快慢直接影响大型项目的构建体验。lld 的设计目标是内聚、快速、内存占用可控。它支持 ELF、Mach-O、COFF、Wasm 等多种格式并且很多地方利用了并行处理。我实测下来一个中等规模 C 项目使用默认的 GNU ld 链接耗时比 lld 多出不少切换后明显感受到构建时间缩短。启用方式很简单clang -fuse-ldlld hello.c -o hello如果你想深入体验 lld 的处理器可以试试ld.lld --time-trace它会生成 Chrome trace 格式的时间分析文件让你直观看到链接过程的每一段耗时。对于大型商业项目这个数据非常有决策价值。5.2 compiler-rtsanitizer 背后的运行时compiler-rt 是一个容易被忽略但日常开发离不开的子项目。AddressSanitizer、UndefinedBehaviorSanitizer、ThreadSanitizer 这些工具运行时都来自这里。它们不依赖特定的操作系统库因此可以用于交叉编译和嵌入式环境。使用方式clang -fsanitizeaddress hello.c -o hello_asan ./hello_asan一旦有内存越界、use-after-free 等问题ASan 会给出详细报告。相比 valgrindASan 的性能开销低得多可以作为 CI 流程的常规检查项。5.3 MLIR一种构建编译器的编译器MLIR 是 LLVM 社区近年来引入的一个子项目全称是 Multi-Level Intermediate Representation。它试图解决的核心问题是某些领域如机器学习、HPC需要多层级抽象同时需要在不同层级上做优化。MLIR 允许你定义自己的方言这些方言可以分层级从高层语义逐步降低到 LLVM IR。我有一次想对一个数据流图做自定义优化如果直接用 LLVM IR优化逻辑会非常别扭因为 IR 层级太低了没法表达这是一个张量算子这种高层概念。但如果用 MLIR 定义一个小型方言在方言层做变换最后再 lower 到 LLVM IR整个过程优雅很多。MLIR 的学习曲线比普通 LLVM 开发更陡但它解决的是传统编译器框架难以处理的扩展性问题。如果你要做领域专用编译基础设施MLIR 值得投入时间研究。5.4 Flang 与 OpenMP补齐更多语言和应用拼图flang为 Fortran 提供了 LLVM 前端支持让老牌科学计算语言也能吃到 LLVM 的优化。openmp子项目实现了 OpenMP 运行时库支持 offload 到 GPU 等异构设备。今天很多高性能计算项目正是以 LLVM 工具链为底座组合使用这些组件。如果你的工作涉及 HPC 或者异构计算这些子项目和 LLVM 主体是协同工作的而不是孤立的存在。6. 如果想啃源码从哪个文件切入如何调试和避开无头苍蝇式阅读LLVM 源码库非常庞大想通读几乎不可能绝大多数工程师也是带着具体问题去读的。但带着问题读和全然没有方向地乱翻效率差别很大。6.1 找入口读代码最有效的方式是跟随一条管线学习源码最佳路径是追踪一条真实的数据流。比如从 Clang 入口开始看clang/lib/CodeGen/CodeGenAction.cpp它会调用 AST 生成 IR然后追踪 IR 如何经过优化管线最终到后端。这条链路把前端、中端、后端串起来是理解全貌最好的方式。对后端感兴趣可以读llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp这是传统指令选择的核心逻辑所在对优化管线感兴趣可以读llvm/lib/Passes/PassBuilder.cpp里的buildPerModuleDefaultPipeline定义了默认优化等级的 Pass 组合。6.2 利用 assert 和调试输出LLVM 内部大量的assert和LLVM_DEBUG宏是调试的线索。你可能会看到类似下面的代码LLVM_DEBUG(dbgs() Processing instruction: I \n);这些输出默认是关闭的需要用-debug参数或者环境变量打开。例如opt -passesloop-unroll -debug-onlyloop-unroll myfile.ll -S-debug-only可以根据不同的调试分类筛选输出避免被海量日志淹没。Debug 构建模式下这些信息更加完整这也是我前面强调要单独准备一个 Debug 构建目录的原因。6.3 小步改造跑测试验证读源码的理想状态是带着 issue 去读。比如你想了解某个 Pass 为什么不生效就在源码里打 log 看完整执行路径。每一次修改后都建议用ninja check或llvm-lit跑相关测试例如llvm-lit -sv test/Transforms/LoopUnroll测试框架会验证你的改动是否符合预期。在 LLVM 生态中没有测试伴随的修改很难评估影响面也很容易在后续集成中埋下隐患。6.4 关于 LLVM 社区协作的一点经验如果阅读过程中遇到无法解决的问题Stack Overflow 和 LLVM Discourse 是很好的求助渠道。但提问前建议准备好最小复现用例一个能触发问题的hello.ll文件、运行的opt或llc命令、LLVM 版本号。LLVM 社区对帮我 debug这类空泛提问不太耐心但对提供了完整复现步骤的 issue 通常响应很快。7. 向量化与 SIMD 语境中的 LLVM256-bit 位宽、llvmpipe 日志与真实性能调优很多人在网络检索中会因为llvmpipe出现256 bits这样的字符串而好奇 LLVM 与 SIMD 的关系。这部分我展开讲讲因为它既是理解 LLVM 后端优化级别的窗口也是实际性能调优经常打交道的区域。7.1 IR 里的向量类型与自动向量化LLVM IR 支持向量类型比如8 x float代表 8 个 float 组成的向量。当你写出适合向量化的循环时优化器有机会把它转成 SIMD 指令。比如在 X86 平台上一个处理 8 个 float 的循环可能会被翻译成一条使用 YMM 寄存器256 位宽度的指令。自动向量化有两种方式循环向量化它检测循环体内没有循环迭代间的依赖时将一个迭代处理一个元素改成同时处理多个元素SLP 向量化它在基本块内发现多条独立标量指令可以合并为向量计算时进行合并。前者更适合简单的数值循环后者更适合结构体数组或多字段计算场景。7.2 查看向量化信息与 llvmpipe 日志的关联用 clang 查看某段代码是否会被向量化可以加-Rpassloop-vectorize系列的选项相关做法通常有clang -O3 -marchnative -Rpassloop-vectorize -Rpass-missedloop-vectorize vec.c这样会注明哪些循环被向量化、哪些没有以及理由。-marchnative让编译器根据当前 CPU 的特性生成指令这是做性能调优时常用的参数能让自动向量化发挥更充分的功效。如果你看到提示说无法证明循环无依赖或者循环结构不适合向量化就需要在代码层面进行调整比如手动拆分循环或者引入断言让别名分析更准确。当我们看到 llvmpipe 日志中的256 bits时往往意味着 LLVM 后端确实生成了 AVX2 或 AVX-512 的向量指令来加速像素处理也就是这里的256 bit代表向量寄存器的位宽。在渲染繁忙的帧中这种向量化带来的加速非常可观。7.3 向量寄存器的历史包袱与性能陷阱引入 256 位指令时有一个众所周知的性能陷阱早期 AVX 实现中上下文的切换和频率调节会导致在 256 位 AVX 指令和寄存器间切换时产生惩罚效应。虽然新的微架构缓解了大部分问题但在密集计算场景中用 SIMD 指令就一定快仍然是不成立的。因为启用向量化意味着更多寄存器占用、潜在的内存对齐要求、指令解码带宽消耗。实际性能测试需要以基准数据为准而不是只看指令条数。我调优性能时的经验是先用perf stat采集指令数、周期、缓存命中率再对热点函数用objdump -d或llvm-objdump检查生成的汇编确认是否真正生成了预期的向量指令并合理利用了寄存器资源。很多时候编译器生成的向量代码和手写 SIMD 有差距但可读性和维护性优势明显——这也是 LLVM 的价值所在它能帮你用更安全的抽象逼近高性能。7.4 跨平台向量化的可移植性问题在不同 CPU 上向量宽度和指令集是不同的。LLVM 的解决方案是靠 target-specific 的 intrinsic 和 target-independent 的向量类型结合。4 x float映射到 ARM NEON 是 128 位映射到 AVX2 是 128 位相同源码可以移植到不同平台算力发挥取决于平台宽度。如果你的代码依赖固定宽度比如必须跑 512 位指令x86 的 AVX-512 与 ARM 的 SVE 是差异明显的需要额外处理。LLVM 提供了target属性的方式去声明函数希望使用的指令集或者用__attribute__((target(avx512f)))在函数粒度控制生成策略适合需要精细控制性能的场景。8. 从学习到生产力不同岗位怎么用好 llvm-project很多刚开始接触的人会被LLVM 太大了劝退但其实不用全学。根据自己的具体工作场景挑对应的模块下手完全可以边做边学在实践里成长。8.1 如果你是语言实现者你在实现一门新语言目标是生成本地代码。建议直接看 Kaleidoscope 教程它是 LLVM 官方教程虽然基于旧版 API但核心思路没变先用 ORC JIT 跑通解释执行再用 MCJIT 或 ORC 编译为本地代码最后接入 Clang 做 ABI 层的互操作。重点学习IRBuilder的用法和模块/函数/基本块的组织方式。这个教程建议配合官方 LLVM IR 语言参考阅读遇到不理解的指令就查文档。做完一遍后会形成比较完整的心智模型。8.2 如果你做基础设施或者工具链那大概率需要把 Clang、lld、compiler-rt 组合在一起使用。你的目标不是从零写编译器而是定制工具链行为比如修改代码生成策略、定制 sanitizer 钩子、接入新的链接节。在这个场景下理解 llvm-project 的模块边界更重要。比如你想给某种新硬件提供一个完整的交叉编译工具链需要关注LLVM_TARGETS_TO_BUILD与 sysroot 的定义用 clang 的--target参数完成配置文件切换。工具链的每个部分都是可拆开的这种组合能力对产品落地有很大价值。8.3 如果你是做 HPC 或图形/深度学习方向的工程师如果你是数据密集计算相关方向的工程师你的关注点可能在自动向量化、循环优化、GPU offload、MLIR 这些更高层的抽象能力上。这类背景下重点不要花太多时间在深入 C 源码以及底层代码生成而是先学会用opt、llc、llvm-mca这些工具分析自己的性能瓶颈。llvm-mca是一个很有意思的工具它可以做一个静态的性能分析——不需要真正运行程序就能基于指令调度模型预测执行吞吐量。写汇编优化的人经常用到它。8.4 如果你是学生或者研究者做研究的人有得天独厚的优势可以放慢速度去读论文和源码交叉验证。比如研究指令选择算法可以把 SelectionDAG 的代码和论文对应着读。一个重要建议把 LLVM 当作一个实验平台而不是一个待破解的黑盒。每个结论都要用工具验证比如对 IR 跑变换、对汇编做性能测试、对目标平台做扫描。研究型工作最大的优势是可以沉下心看细节LLVM 提供了完整的可见性是编译器领域做实验的好土壤。9. 版本演进视角从 LLVM 15.0.7 观察项目长期稳定的架构模式版本号本身没有特殊性但通过一个特定的 Release 版本可以看出 LLVM 项目的演进节奏和工程管理方式。LLVM 以半年为节奏发布主要版本每个版本都有明确的新特性列表和兼容性说明。9.1 Release 分支哲学稳定与激进并存LLVM 在开发期很激进API 频繁变化但一到 Release 周期变更会全部冻结进入测试和 bug 修复阶段。这也解释了为什么用 main 分支跑生产项目不是好主意。选择 release 版本来学习、部署是一个可靠的生产策略。15.0.7 作为 15 系列的修复版本集成了若干 bug 修复属于那个周期里很稳定的一个点。9.2 新 Pass 架构的推进与新开发的兼容性思考围绕 LLVM 15新 Pass 架构已经非常成熟legacy Pass 处于淘汰边缘。如果你在参考某本旧书籍或旧博客注意区分代码的时间和 API 版本。新 Pass 的主要好处是更好的并行分析能力和简化的 API 边界这也是 LLVM 为了适应多线程编译场景做出的架构调整。如果你编写自定义 Pass建议从一开始就使用新 Pass 接口避免在 legacy 和新框架之间做无效迁移。9.3 互相引用历史版本资料时的坑这么多年来网上积累了海量的 LLVM 教程但很多教程里出现的 API 已面目全非。最典型的是 Pass 注册宏从RegisterPass到PassRegistry再到llvmGetPassPluginInfo差异很大。看教程时先看它的发布日期和 LLVM 版本如果不是针对你当前版本先不要直接抄写代码而是去当时版本的文档或源码里确认 API 是否仍然适用。10. 写代码之外社区协作、贡献流程与学习资源的实用建议最后说一些代码以外但长期受益的经验。10.1 贡献代码的正确打开方式如果想给 LLVM 贡献代码建议遵循官方贡献指南的流程。第一步往往不是提交代码而是先上 Discourse 或 GitHub issue 讨论设计。LLVM 社区对架构有很强的把关意识一个 pass 的设计如果和现有架构不一致即使代码正确也可能被要求大幅调整。代码风格方面LLVM 用clang-format统一格式提交前运行git-clang-format可以省去很多 review 反复。代码的所有权意识和模块责任人的把关对长期项目质量至关重要。10.2 必须收藏的资源列表LLVM Language Reference ManualIR 语法的权威定义常查常新。LLVM Developer Policy理解了它才能理解社区的很多决策逻辑。LLVM Weekly每周更新的社区资讯汇总能帮你跟踪生态动态。Stack Overflow 的 llvm 标签查排错思路效率高但提问前先确认版本。各种会议的视频如 LLVM Developers Meeting信息密度很高适合过渡阶段快速提升。10.3 学习路径的节奏控制我的建议是不要一口气想掌握全部模块。先用几天时间把 IR 语法和 opt 工具玩熟再花一周做一个简单的自定义 Pass之后根据需求接触 Clang、lld 或 MLIR。每深入一个模块都会反过来加深你对 LLVM 整体架构的认识这种感觉和单纯的文档阅读完全不是一回事。如果遇到卡点很多情况不是你的思路有问题而是版本差异或上下文信息缺失。先记录现象、复现最小案例、对照源码逻辑90% 的问题可以这样解决。剩下 10% 再去社区提问带着完整上下文的问题被认真回答的概率会大很多。从我自己的经历来说接触 LLVM 的初期是最容易被它就是编译器这个定式给限制住的。真正开始用它 JIT 渲染、做领域编译器、搭工具链之后才发现 LLVM 不只是一个程序而是一整套让编译器变得可以像积木一样灵活搭建的基础设施。现在回看从第一份 Release 构建到慢慢读通 IR、写完一个可以在opt中加载的 Pass这条路其实并没有想象中那么难。LLVM 这个项目最迷人的地方在于它把一个复杂到极致的系统切分成了清晰的模块每个模块都能独立演进又通过 IR 这个接口彼此连接。先用起来、再读代码、再深入设计每一步都有新东西可挖。这篇文章写到这里其实更想传达到的是LLVM 没那么遥不可及它更像一套开放的积木每个人都能找到自己需要的那几块拼出自己的解决方案。