LLVM 这个名字我在不同场合见过太多次了。有人把它当编译器有人以为它是个虚拟机还有人一听“llvm-project”就下意识觉得这是个高不可攀的巨型项目只敢远观不敢上手。这几年的实际体验告诉我LLVM 的价值恰恰在于它没有那么玄乎它本质上是一整套构建编译器所需的基础设施只是它的组织方式和传统编译器项目不太一样。如果你打算认真研究现代编译技术或者工作中要跟工具链打交道llvm-project 是你绕不开的一个项目早点吃透它对后面的帮助很大。这篇文章我不打算做那种“从入门到精通”的全覆盖那既不现实也没有必要。我更想结合我自己从零开始接触 llvm-project、构建它、在它上面做二次开发的实际经历把那些文档里写得不够直白、论坛里零散讨论过的东西串起来讲一遍。包括 monorepo 结构怎么理解、从源码构建 LLVM 时那些容易让人心态崩溃的配置项、LLVM IR 为什么是整个架构的灵魂以及一个完整的最小 Pass 开发流程。顺带把 llvmpipe 这件事也讲清楚很多人看到日志里出现 llvmpipe 字样会误以为 LLVM 出了毛病其实不是那么回事。1. 重新认识 llvm-project它不是“一个编译器”而是一套编译器工厂1.1 Low Level Virtual Machine 这个名字留下的误会先纠正一个流传很广的误解。LLVM 的全称曾是 Low Level Virtual Machine听起来像是一个虚拟机项目。但今天的 LLVM 跟虚拟机已经基本上没有关系了它是一整套用于构建编译器、链接器、运行时库的工具链组件集合。这个命名上的历史遗留问题误导了很多人包括我自己最早接触的时候也困惑过既然是 Virtual Machine那我的程序是不是跑在一个虚拟机上显然不是。你写一个 C 文件用 clang 编出来的可执行文件直接在 CPU 上跑中间没有虚拟机这一层。准确地说llvm-project 是围绕“中间表示IR”和“后端代码生成”打造的一套可复用基础设施。它允许你用不同的前端语言前端生成统一的 IR然后在 IR 层面做各种优化最后再分派到不同的硬件后端生成机器码。这套设计的直接产物就是 ClangC/C/Objective-C 前端、LLVM 优化器与后端、LLD 链接器、libc 标准库实现、compiler-rt 运行时库、MLIR 等等。可以把 llvm-project 理解成一条模块化的汽车生产线。你不需要从零开始设计发动机、底盘、变速箱生产线的框架已经在那里了你只需要把自己的“发动机”前端语言支持接上去或者把自己的“新车型”新硬件架构后端接上去就能产出一辆能跑的车。相比 GCC 那种把前后端耦合在同一个仓库里的传统编译器这种工厂化的设计让扩展成本低了很多。1.2 Monorepo 迭代管理一个仓库装下整个工具链生态现在的 LLVM 项目在 GitHub 上以llvm/llvm-project的形式存在采用单体仓库monorepo管理方式。这一点是 2019 年前后完成的重要转变我记得更早的时候 LLVM 是分多个仓库管理的包括 llvm、clang、lldb、libcxx 各自独立每次跨仓库提交一个关联改动要开一堆 PR很痛苦。现在统一到一个仓库里跨子项目的改动可以一次性提交构建系统也可以统一处理各组件之间的依赖关系。对想深入源码的人来说monorepo 降低了一件事的门槛你可以直接在一个 checkout 里看到 Clang 前端如何生成 IR、优化器如何处理 IR、后端如何把 IR 变成汇编。不用再去好几个仓库之间跳来跳去对版本。llvm-project 仓库内主要子项目的组织关系大致如下子项目路径作用我的理解llvm/核心库、优化器、后端、opt/llc等工具整个项目的心脏clang/C/C/Objective-C 编译器前端最常用的入口lld/高性能链接器链接速度比 GNU ld 快得多libcxx/C 标准库实现和 Clang 搭配使用效果最好compiler-rt/运行时支持库、sanitizer 实现排查内存问题的神器mlir/面向 AI 和自定义编译器的多层 IR 框架目前最活跃的方向之一flang/Fortran 前端科学计算领域相关lldb/调试器和 LLVM 生态深度集成polly/基于多面体模型的循环优化偏学术但很有启发性clang-tools-extra/clang-tidy、clangd 等辅助工具日常开发非常依赖其中clang-tools-extra之所以单独拆出来一个目录是因为它不属于编译器核心流程而是服务于开发者日常工程体验的工具集。比如clangd现在很多编辑器都在用补齐了 C 的智能补全和跳转体验。从开发角度看在 monorepo 里做贡献的流程大概是fork 仓库到自己的 GitHub本地git clone创建一个 feature 分支写代码然后git push到自己的 fork再到上游开 Pull Request。上游对代码格式要求非常严格用的是clang-format和clang-tidy一起把关所以提交之前本地跑一遍检查是很有必要的。2. 从源码构建 LLVM一次帮你把依赖、配置和编译参数全部理清2.1 为什么建议自己构建而不是直接装包很多人用过 Ubuntu 的 apt 安装llvm或者 macOS 上的 Homebrew 安装llvm15会觉得“这不就装好了吗何必自己编译”如果你的需求只是跑一下clang编译普通的 C 程序确实没有必要自己构建。但如果你想做下面任何一件事自己从源码构建几乎是必然选择修改 LLVM 源码实验自己的新 Pass基于 LLVM 版本做交叉编译或定制工具链需要调整默认 target在非主流平台比如某些嵌入式环境或特殊 Linux 发行版上使用 LLVM调试 LLVM 自身的问题需要带 debug 信息的可执行文件用最新的 release 分支而非系统自带的旧版本。我自己第一次从源码构建是因为想给一个课程项目写一个自定义的 LLVM Pass。当时系统自带的 LLVM 是 10 版本而课程要求 14版本不匹配导致llvm-config给出的路径和自带的头文件对不上折腾了很久最后还是老老实实自己编译了。版本不匹配是 LLVM 开发里很典型的一个坑。LLVM 内部的 API 变化非常快甚至同一个大版本的不同小版本之间某些接口都会有微妙改动。写 Pass 的时候最好和你本地安装的 LLVM 完全同源否则链接阶段经常报一堆“undefined reference”或者声明与定义不匹配的错误。不要问我怎么知道的。2.2 构建前的准备与依赖检查如果要构建 LLVM建议准备一台至少 8 核 CPU、16GB 内存、30GB 以上空闲磁盘的机器。如果条件差一些也能编但耗时会长很多。我自己在 4 核 8GB 的笔记本上尝试过完整构建 Release 版 LLVMClang大概花了三个多小时期间内存一度逼近上限。依赖方面不同系统略有差异但核心依赖比较一致CMake建议 3.20 以上LLVM 版本越新对 CMake 版本要求越高一个能用的 C/C 编译器GCC 或 Clang 均可官方支持两者Ninja 构建系统比 make 快很多强烈推荐Python 3构建脚本和测试脚本需要用到zlib、libxml2 等常见开发库按发行版包管理器装上即可。以 Ubuntu 为例安装依赖的命令大致是sudo apt update sudo apt install cmake ninja-build python3 python3-pip build-essential \ zlib1g-dev libxml2-dev libncurses-dev如果是 Fedora则对应为sudo dnf install cmake ninja-build python3 python3-pip gcc-c \ zlib-devel libxml2-devel ncurses-devel2.3 CMake 配置的推荐姿势与参数解读LLVM 的构建系统基于 CMake配置方式是在源码根目录下创建一个 build 目录然后在其中运行cmake。我比较推荐的配置命令是这样的git clone https://github.com/llvm/llvm-project.git cd llvm-project mkdir build cd build cmake -G Ninja \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_INSTALL_PREFIX$HOME/llvm-install \ -DLLVM_ENABLE_PROJECTSclang;lld;clang-tools-extra \ -DLLVM_TARGETS_TO_BUILDX86;AArch64 \ -DLLVM_ENABLE_ASSERTIONSON \ -DLLVM_CCACHE_BUILDON \ ../llvm逐条解释一下这些参数的作用-G Ninja指定用 Ninja 作为构建工具。Ninja 的并行构建效率很高而且增量编译速度远快于 make。-DCMAKE_BUILD_TYPEReleaseRelease 模式。如果要调试 LLVM 自身或者写 Pass其实建议用RelWithDebInfo带调试信息的 Release这样既有优化后的性能又能用 gdb 打断点看变量。-DCMAKE_INSTALL_PREFIX安装路径。后续ninja install会把这些工具装到这里。-DLLVM_ENABLE_PROJECTS指定额外构建哪些子项目。注意LLVM 核心库默认一定会构建但 Clang、LLD 这些默认不构建需要在这里显式列出。-DLLVM_TARGETS_TO_BUILD指定需要生成代码的目标架构。默认会构建所有支持的后端包括 AMDGPU、BPF、Mips、PowerPC、RISCV、SystemZ、WebAssembly 等。如果只是日常使用只保留X86和AArch64就足够了可以显著减少编译时间。-DLLVM_ENABLE_ASSERTIONSON开启断言。调试阶段强烈建议开启很多 API 使用错误会在运行时直接报出来而不是静默产生错误结果。但 Release 发布版通常关闭它因为断言会拖慢性能。-DLLVM_CCACHE_BUILDON启用 ccache。如果你打算频繁改代码重新编译ccache 能省下大量重复编译时间真的是用过就回不去。提示如果你第一次构建不要犹豫直接加上-DLLVM_CCACHE_BUILDON。哪怕你只是做一次性的完整构建ccache 也能帮你节省后续所有增量编译的时间。配置完成后执行ninja如果机器性能不错可以并行度高一点ninja -j$(nproc)这个过程会比较久我建议第一次构建的时候不要把终端关了。如果中断继续跑ninja会从上一次断点继续。2.4 我踩过的构建相关的几个坑头一个坑和磁盘空间有关。默认构建全会生成大量目标文件和静态库我见过build目录膨胀到 60GB 以上的情况。所以一开始就要注意不要在空间紧张的分区下建 build 目录。另外如果你的系统是 Windows要额外注意 Visual Studio 版本和 CMake 生成器的匹配以及 Windows 上文件路径长度限制的问题。LLVM 源码里有些路径特别深Windows 默认的 MAX_PATH 260 字符限制会直接导致构建失败需要开启长路径支持。第二个坑和内存有关。链接clang这种巨型可执行文件时链接器要一次性把所有目标文件加载进内存如果内存不足会直接 OOM。我自己在 8GB 内存的机器上链接clang时系统直接卡死后来加了 swap 才勉强过去。建议如果你内存不大先只构建clang不要一次构建clanglldclang-tools-extra全套构建任务分几次进行会稳妥很多。第三个坑是系统 GCC 版本太老导致编译失败。LLVM 新版对编译器的要求也在提高比如 LLVM 19 要求至少 GCC 7.5 或 Clang 7 以上。如果你在老系统上编译新版 LLVM可能要先更新系统的编译工具链形成一个“先有鸡还是先有蛋”的小死结。解决办法是先用系统包管理器装一个较新的 Clang 或 GCC再用它来构建 LLVM。这个循环是常见操作不用慌。3. 理解 LLVM 三段式架构为什么说 IR 是整个项目的灵魂3.1 三段式设计与 GCC 传统路线的差异LLVM 的架构核心是“三段式”前端Frontend、优化器Optimizer、后端Backend。对应到代码仓库里前端主要是 Clang优化器是 LLVM 中处理 IR 的那一堆 Pass后端是生成目标机器码的部分。前端负责把源代码解析成 AST抽象语法树再做语义分析最后生成 LLVM IR中间表示。优化器对 IR 做一遍又一遍的 Pass 处理试图减少冗余计算、消除死代码、优化循环等等目标是不改变程序语义的前提下让程序跑得更快或者体积更小。后端把优化后的 IR 转换为目标机器的汇编代码再交给汇编器变成目标文件最后由链接器组合成可执行文件。GCC 也有类似的思路但 GCC 的 GIMPLE 中间表示主要是服务于 GCC 自身的外部工具要复用这套流程很困难。而 LLVM 从一开始就把 IR 设计成一个稳定的、可外部读取和修改的表示形式。这意味着你可以自己写一个工具读取.ll文件分析或改写 IR然后再把它喂回 LLVM 工具链继续处理。这种开放性是 LLVM 能成为一个“生态”的根本原因。3.2 LLVM IR可读、可控、可验证的中间表示LLVM IR 有三种存在形式可读文本形式.ll文件主要用于调试和理解二进制位码形式.bc文件体积小、加载快内存中的表示即LLVMContext里组织好的Module、Function、BasicBlock、Instruction等 C 对象。看一段最简单的 C 代码和它的 IR 对照int add(int a, int b) { return a b; }用clang -S -emit-llvm add.c -o add.ll命令生成; ModuleID add.c source_filename add.c target datalayout e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128 target triple x86_64-unknown-linux-gnu define i32 add(i32 noundef %a, i32 noundef %b) { entry: %add add nsw i32 %a, %b ret i32 %add }这个 IR 清楚地表现了几件事define i32 add表示定义了一个返回i32的函数函数名是addentry是一个基本块%add add nsw i32 %a, %b是把两个i32类型的值相加结果存到一个虚拟寄存器里ret i32 %add是返回结果。其中nsw表示“no signed wrap”即这个加法不会发生有符号溢出这个标记能帮助优化器在后续做更多代数化简。相比直接看汇编IR 保留了类型信息同时去掉了具体的寄存器分配、指令调度等后端细节。因此绝大多数优化 Pass 可以在 IR 层做而无需关心目标架构。同一个优化 Pass在 x86 上用在 ARM 上也能用在 RISC-V 上同样能用。这正是 LLVM 节省各后端重复劳动的核心手段。3.3 IR 生成与优化流程的完整工具链视角当你运行clang时它内部实际上是调用了前端生成 IR然后调用优化器对 IR 做优化。如果想单独看每一步可以用clang -S -emit-llvm foo.c -o foo.ll # 生成可读 IR opt -passesmem2reg,instcombine foo.ll -S -o foo_opt.ll # 跑优化 llc foo_opt.ll -o foo.s # 生成汇编这个流程解释了为什么 LLVM 的组件可以拆开使用clang负责前端opt是优化器入口llc是后端入口。每个工具都可以独立运行方便你做各种定制和研究。如果你对某段 C 代码的优化效果感到好奇可以分别在优化前后生成 IR 对比比如clang -O0 -S -emit-llvm test.c -o test_O0.ll clang -O2 -S -emit-llvm test.c -o test_O2.ll diff test_O0.ll test_O2.ll通过对比输出你能直观看到-O2下优化器帮你做了多少事情循环展开、内联、常量传播、死代码消除等等。这种“看 IR 变化来理解优化”的学习方式比直接看编译原理课本要实在得多。4. 实战写一个最简单的 LLVM Function Pass并把它跑起来4.1 Pass 是什么为什么开发 Pass 是常见的切入点LLVM 的优化器本质上是一个 Pass 流水线。一个 Pass 就是对 IR 做一次遍历和可能的修改比如“循环不变式外提”是一个 Pass“指令合并”是一个 Pass“死代码消除”也是一个 Pass。你写自定义 Pass就是在 LLVM 的优化流程中插入自己的分析或变换逻辑。写一个自定义 Pass 是学习 LLVM 最有效也最有成就感的途径因为你可以立刻看到自己写的代码在真实编译器流水线中被调起来并能通过 IR 输出验证效果。同时写 Pass 也是很多公司基于 LLVM 做定制优化的常见方式比如为某个专用芯片增加特殊的指令选择规则或者为内部编程语言实现新的优化策略。4.2 环境准备用 CMake 构建一个插件型 PassLLVM 的 Pass 可以以插件形式动态加载不需要重新编译整个 LLVM。我们只需要编译一个共享库然后用opt -load-pass-plugin...加载它。我以一个非常简单的 Pass 为例它的功能是遍历每个函数的每条指令打印出指令的操作码和所在函数名。这个 Pass 不做任何代码变换但足以验证环境是否正常、API 是否匹配以及你对 IR 结构理解是否正确。首先建立目录结构llvm-pass-demo/ ├── CMakeLists.txt └── src/ └── DemoPass.cppCMakeLists.txt内容如下cmake_minimum_required(VERSION 3.20) project(LLVMDemoPass) find_package(LLVM REQUIRED CONFIG) message(STATUS Found LLVM ${LLVM_PACKAGE_VERSION}) message(STATUS Using LLVMConfig.cmake in: ${LLVM_DIR}) include_directories(${LLVM_INCLUDE_DIRS}) add_definitions(${LLVM_DEFINITIONS}) add_library(DemoPass MODULE src/DemoPass.cpp) if(LLVM_ENABLE_RTTI) target_compile_options(DemoPass PRIVATE -fno-rtti) else() target_compile_options(DemoPass PRIVATE -fno-rtti) endif() target_link_libraries(DemoPass PRIVATE LLVMCore LLVMSupport LLVMPasses) set_target_properties(DemoPass PROPERTIES PREFIX )这里find_package(LLVM REQUIRED CONFIG)会去LLVM_DIR指向的位置找 LLVM 的 CMake 配置。要让它生效需要确保LLVM_DIR指向你构建出的lib/cmake/llvm目录。add_library(DemoPass MODULE ...)表示构建一个模块类型的动态库适合作为插件被opt加载。PREFIX 是为了让生成的.so文件不带lib前缀这样加载命令可以写成-load-pass-plugin./DemoPass.so比较清爽。DemoPass.cpp的代码如下#include llvm/IR/Function.h #include llvm/IR/Instruction.h #include llvm/IR/Instructions.h #include llvm/IR/LLVMContext.h #include llvm/IR/Module.h #include llvm/IR/PassManager.h #include llvm/Passes/PassBuilder.h #include llvm/Passes/PassPlugin.h #include llvm/Support/raw_ostream.h using namespace llvm; namespace { class DemoPass : public PassInfoMixinDemoPass { public: PreservedAnalyses run(Function F, FunctionAnalysisManager AM) { outs() Visiting function: F.getName() \n; for (BasicBlock BB : F) { for (Instruction I : BB) { outs() opcode: I.getOpcodeName() , operands: I.getNumOperands() \n; } } return PreservedAnalyses::all(); } }; } // namespace extern C ::llvm::PassPluginLibraryInfo llvmGetPassPluginInfo() { return {LLVM_PLUGIN_API_VERSION, DemoPass, LLVM_VERSION_STRING, [](PassBuilder PB) { PB.registerPipelineParsingCallback( [](StringRef Name, FunctionPassManager FPM, ArrayRefPassBuilder::PipelineElement) { if (Name demo-pass) { FPM.addPass(DemoPass()); return true; } return false; }); }}; }这段代码有几个关键点需要解释PassInfoMixinDemoPass是基于新 Pass Manager 的写法。LLVM 14 之后新 Pass Manager 已经全面接管优化流水线旧式的FunctionPass已经逐步被淘汰。写新 Pass 的时候建议直接用新的 API不要在新项目里写旧式 Pass。run(Function F, FunctionAnalysisManager AM)是每个函数都要执行一遍的入口FunctionAnalysisManager参数允许你在必要的时候请求其他分析结果比如AM.getResultLoopAnalysis(F)。PreservedAnalyses::all()表示这个 Pass 没有修改任何 IR所以优化器可以保留所有之前的分析结果。如果一个 Pass 改了 IR你需要返回PreservedAnalyses::none()或者指定保留哪些分析。这个细节影响性能但不影响正确性很多人刚开始会忽略。llvmGetPassPluginInfo这个函数是插件与 LLVM 之间的接合点。它返回一个PassPluginLibraryInfo其中包含插件 API 版本、插件名字、LLVM 版本和注册回调。在回调里我们用registerPipelineParsingCallback注册了一个可识别的 Pass 名字demo-pass这样我们在opt命令行中可以通过--passesdemo-pass来调用它。4.3 编译、加载和运行效果验证编译这个 Pass 之前需要确保LLVM_DIR指向正确的路径。如果你按前面的步骤把 LLVM 安装到了$HOME/llvm-install那么配置命令如下cd llvm-pass-demo cmake -S . -B build -DLLVM_DIR$HOME/llvm-install/lib/cmake/llvm cmake --build build编译成功后会生成build/DemoPass.so。然后我们写一个测试用的 C 文件int add(int a, int b) { int c a b; return c; } int main(void) { return add(2, 3); }先用clang生成 IR然后加载插件跑一遍clang -S -emit-llvm test.c -o test.ll opt -load-pass-pluginbuild/DemoPass.so --passesdemo-pass test.ll -S -o /dev/null正常情况下你会看到类似这样的输出 Visiting function: add opcode: add, operands: 2 opcode: ret, operands: 1 Visiting function: main opcode: call, operands: 1 opcode: ret, operands: 1这说明你的插件被成功加载并执行了也说明 IR 遍历逻辑正确理解到了每条指令的操作码和操作数数量。有一个细节值得注意如果编译插件时 LLVM 的 CMake 报错找不到包多半是LLVM_DIR没设置对。去找一下你安装目录下有没有lib/cmake/llvm/LLVMConfig.cmake这个文件路径指向那一层目录即可。如果你没有安装 LLVM 到指定 prefix也可以让LLVM_DIR指向 build 目录中的lib/cmake/llvm。4.4 调试 Pass 时的常用技巧写 Pass 的时候最常用的调试手段就是打印输出。LLVM 里不要用 C 的printf而应该用llvm::outs()和llvm::errs()因为它们能保证输出的时机和缓冲行为与 LLVM 的日志系统一致。如果你要看 LLVM 自带的某个 Pass 是否执行可以用--debug-pass-manager选项它会打印出 pass manager 的完整执行流程。此外opt --print-after-all是一个非常强大的调试神器它会在每个 Pass 执行后打印出整个模块的 IR你可以快速定位是哪个 Pass 在哪一步改变了 IR。不过这个输出量非常大通常要和--filter-print-funcs配合使用只打印某个具体函数的 IR 变化opt -load-pass-pluginbuild/DemoPass.so \ --passesdemo-pass,instcombine \ --print-after-all --filter-print-funcsadd \ test.ll -S -o /dev/null这样你可以精确看到demo-pass执行前后、instcombine执行前后add函数 IR 的差异。5. llvmpipe 到底是什么那个让你误以为“LLVM 坏了”的软件渲染器5.1 日志里的 llvmpipe 与 LLVM 本身的关系有一些读者可能是在显卡驱动日志、glxinfo输出或者 Chrome 的 GPU 进程日志里看到了llvmpipe这个词才会去搜索 LLVM。这个疑问很有代表性LLVM 和显卡是怎么扯上关系的llvmpipe 并不是 LLVM 工程本身的一部分它是 Mesa 3D 图形库中的一个软件渲染器实现。名字里的 “llvm” 是因为它借助 LLVM 的 JIT即时编译能力把图形渲染管线中的着色器编译成当前 CPU 能执行的机器码。你可以理解为当你的系统没有可用的硬件 GPU 驱动或者处于虚拟机、远程桌面等环境时Mesa 会退回到 llvmpipe用 CPU 来模拟 GPU 的功能。例如在 Linux 下运行glxinfo | grep OpenGL renderer如果看到类似OpenGL renderer string: llvmpipe (LLVM 15.0.7, 256 bits)这代表当前的 OpenGL 渲染器是 llvmpipe括号里的LLVM 15.0.7是 Mesa 所链接的 LLVM 版本256 bits是 CPU 的 SIMD 向量宽度256 位对应 AVX2。所以看到 llvmpipe 不代表 LLVM 项目出了什么问题也不一定代表你的显卡坏了。它只是说明图形栈正在使用 CPU 软件渲染作为回退方案。5.2 触发 llvmpipe 的常见场景与处置建议从实际经验来看以下几个场景最容易遇到 llvmpipe服务器或容器环境里没有 GPU但某些程序仍然请求 OpenGL/Vulkan 上下文虚拟机里没有启用 GPU 直通而且虚拟显卡驱动没有正确加载Linux 桌面环境下 GPU 驱动没有装好内核模块没有正确探测到显卡用远程桌面比如 VNC 或某些云桌面方案时GPU 加速不可用。如果你确实需要硬件加速可以按这个顺序排查先确认有没有独立显卡lspci | grep VGA再看系统负载glxinfo是否真的检测到了硬件渲染器然后是安装合适的驱动比如mesa-vulkan-drivers或 NVIDIA 的专有驱动。这些配置做完后重启 X 或 Wayland 会话再用glxinfo查看渲染器是不是变回了硬件型号。如果你的场景里并不需要 GPU 加速比如只是跑一个离线的 OpenGL 离屏渲染任务那么 llvmpipe 反而是个好消息它起码保证了程序不会因为没有 GPU 而直接失败退出。而且 llvmpipe 在正确配置的机器上性能并不差做一些离屏渲染或 CI 测试完全够用。我就在 CI 环境里用 llvmpipe 跑 OpenGL 相关的单元测试稳定得很。5.3 llvmpipe 用到的“256 bits”是什么日志里那个256 bits经常让人困惑以为它表示显存带宽或颜色深度之类的东西。其实它指的是 JIT 生成代码时 SIMD 向量寄存器的位宽。LLVM 后端在编译着色器时会尽量把多个像素的计算打包成向量指令用上 CPU 的 AVX2256 位、AVX-512如果需要且 CPU 支持等指令集。256 bits说明当前 llvmpipe 编译路径使用了 256 位宽的 SIMD 寄存器一次可以并行处理 8 个 32 位浮点数的运算。这个数字越大说明一次能并行处理的数据越多软件渲染的吞吐量就越高。但这并不代表你的 CPU 不支持更高位宽的向量而是 llvmpipe 在检测到 CPU 特性之后自动选择的一个合适档位。6. 进阶方向从会用到能改LLVM 生态的几条扩展路径6.1 后端的扩展TableGen 与新指令集支持如果你关注的不是优化而是想给一个新开发或非主流的处理器架构提供编译器支持那核心工作会落到 LLVM 后端。后端涉及的代码包括寄存器定义、指令集描述、指令选择、指令调度、汇编解析器等等。LLVM 用 TableGen 这门领域特定语言来描述这些信息而不是直接用 C 写死。TableGen 文件.td文件负责声明寄存器、指令、指令格式和模式匹配规则。举个例子在X86InstrInfo.td里能看到大量指令定义每条指令定义了助记符、操作数类型、编码和选择模式。而指令选择的核心是把 SelectionDAG 或 GlobalISel 中的 IR 节点匹配到具体的目标指令。修改这些.td文件再运行 TableGen 生成对应的 C 代码是后端开发的基本操作。这条路径比写前端或优化 Pass 要陡峭得多涉及计算机体系结构的知识需要沉下心看懂架构手册。但收益也大如果你想从事编译器后端开发这部分是硬功夫几乎没有捷径。6.2 前端的扩展Clang 与自定义语言支持如果想把一门新语言编译到 LLVM IR你有两条路一是复用 Clang 的框架把你的语言解析成 Clang 的 AST然后生成 IR二是完全独立写一个前端生成 LLVM IR 文件交给 LLVM 优化器处理。前者工作量大但能直接享用 Clang 的语义分析能力后者灵活度高不少小众语言就是这么做的。如果你只是想给小语言加一些实验性语法更轻量的做法是用 MLIR 的 Toy 教程起步。MLIR 本身是 LLVM 之上构建的一套可扩展中间表示框架非常适合做领域特定编译器和更高级别的抽象。6.3 工具链集成LLD 与 Sanitizer 的日常使用价值抛开源码开发不谈即便你只是在做一个普通的 C/C 项目llvm-project 里的 LLD 和 Sanitizer 也值得单独拎出来用好。LLD 的链接速度非常惊艳。我参与的一个大型 C 项目用 GNU ld 链接耗时 40 多秒切到 LLD 之后降到 7-8 秒。对日常开发来说这种体验提升是立竿见影的。用法很简单在 CMake 里设置-fuse-ldlld即可。Sanitizer 则是排查内存问题的利器。AddressSanitizerASan能检测 use-after-free、堆缓冲区溢出、栈缓冲区溢出等问题通常在 CI 中跑一轮 ASan 构建很多隐性问题就会原形毕露。它需要你在编译和链接时加上-fsanitizeaddress运行测试时会直接输出具体出错位置和调用栈。7. 学 LLVM 的路径建议少走弯路的几件小事结合我自己摸爬滚打的过程最后说几点实在的建议。第一不要一上来就啃 LLVM 的源码目录结构尤其是llvm/lib/Transforms/下面那几十个目录很容易迷失。更好的学习路径是先跑通一个最小 Pass理解 IR 的基本形式再针对你感兴趣的方向去读对应源码。以点带面效率远高于从头到尾通读。第二一定要自己亲手生成和修改 IR。很多人看了大量 IR 相关文章但自己从没手动打开过.ll文件也没有试着改改里面的数字看会发生什么。其实你只需要随便写个小函数clang -S -emit-llvm生成 IR然后手动把常数值改一改再llc生成汇编这种实验做几次IR 与机器码的对应关系就会熟很多。第三善用llvm-config和 CMake 的find_package。对做 LLVM 开发的人来说环境配置的坑往往比代码本身的坑更多。务必确认你写 Pass 时用的头文件版本和最终opt可执行文件的版本完全一致。不一致的时候各种奇异链接错误和运行时崩溃都会来问候你。第四关注 LLVM 的 release note。每个版本发布时llvm/docs/ReleaseNotes.rst都会列出破坏性变更和新增功能。升级 LLVM 版本前先扫一眼这个文件能帮你提前预判哪些代码需要改。LLVM 这个项目最迷人的地方在于它把“编译器”这个听起来非常古老和封闭的领域做成了一个高度模块化、可扩展的开放平台。你不需要掌握所有组件完全可以只从某一个点切入比如先读懂一个 Pass比如先弄明白opt工具怎么用再顺着自己的需求逐渐向外扩展。这个过程不会太快但每往前走一步你能做的事情都会多一个量级。
LLVM与llvm-project入门：从源码构建到Pass开发实战
LLVM 这个名字我在不同场合见过太多次了。有人把它当编译器有人以为它是个虚拟机还有人一听“llvm-project”就下意识觉得这是个高不可攀的巨型项目只敢远观不敢上手。这几年的实际体验告诉我LLVM 的价值恰恰在于它没有那么玄乎它本质上是一整套构建编译器所需的基础设施只是它的组织方式和传统编译器项目不太一样。如果你打算认真研究现代编译技术或者工作中要跟工具链打交道llvm-project 是你绕不开的一个项目早点吃透它对后面的帮助很大。这篇文章我不打算做那种“从入门到精通”的全覆盖那既不现实也没有必要。我更想结合我自己从零开始接触 llvm-project、构建它、在它上面做二次开发的实际经历把那些文档里写得不够直白、论坛里零散讨论过的东西串起来讲一遍。包括 monorepo 结构怎么理解、从源码构建 LLVM 时那些容易让人心态崩溃的配置项、LLVM IR 为什么是整个架构的灵魂以及一个完整的最小 Pass 开发流程。顺带把 llvmpipe 这件事也讲清楚很多人看到日志里出现 llvmpipe 字样会误以为 LLVM 出了毛病其实不是那么回事。1. 重新认识 llvm-project它不是“一个编译器”而是一套编译器工厂1.1 Low Level Virtual Machine 这个名字留下的误会先纠正一个流传很广的误解。LLVM 的全称曾是 Low Level Virtual Machine听起来像是一个虚拟机项目。但今天的 LLVM 跟虚拟机已经基本上没有关系了它是一整套用于构建编译器、链接器、运行时库的工具链组件集合。这个命名上的历史遗留问题误导了很多人包括我自己最早接触的时候也困惑过既然是 Virtual Machine那我的程序是不是跑在一个虚拟机上显然不是。你写一个 C 文件用 clang 编出来的可执行文件直接在 CPU 上跑中间没有虚拟机这一层。准确地说llvm-project 是围绕“中间表示IR”和“后端代码生成”打造的一套可复用基础设施。它允许你用不同的前端语言前端生成统一的 IR然后在 IR 层面做各种优化最后再分派到不同的硬件后端生成机器码。这套设计的直接产物就是 ClangC/C/Objective-C 前端、LLVM 优化器与后端、LLD 链接器、libc 标准库实现、compiler-rt 运行时库、MLIR 等等。可以把 llvm-project 理解成一条模块化的汽车生产线。你不需要从零开始设计发动机、底盘、变速箱生产线的框架已经在那里了你只需要把自己的“发动机”前端语言支持接上去或者把自己的“新车型”新硬件架构后端接上去就能产出一辆能跑的车。相比 GCC 那种把前后端耦合在同一个仓库里的传统编译器这种工厂化的设计让扩展成本低了很多。1.2 Monorepo 迭代管理一个仓库装下整个工具链生态现在的 LLVM 项目在 GitHub 上以llvm/llvm-project的形式存在采用单体仓库monorepo管理方式。这一点是 2019 年前后完成的重要转变我记得更早的时候 LLVM 是分多个仓库管理的包括 llvm、clang、lldb、libcxx 各自独立每次跨仓库提交一个关联改动要开一堆 PR很痛苦。现在统一到一个仓库里跨子项目的改动可以一次性提交构建系统也可以统一处理各组件之间的依赖关系。对想深入源码的人来说monorepo 降低了一件事的门槛你可以直接在一个 checkout 里看到 Clang 前端如何生成 IR、优化器如何处理 IR、后端如何把 IR 变成汇编。不用再去好几个仓库之间跳来跳去对版本。llvm-project 仓库内主要子项目的组织关系大致如下子项目路径作用我的理解llvm/核心库、优化器、后端、opt/llc等工具整个项目的心脏clang/C/C/Objective-C 编译器前端最常用的入口lld/高性能链接器链接速度比 GNU ld 快得多libcxx/C 标准库实现和 Clang 搭配使用效果最好compiler-rt/运行时支持库、sanitizer 实现排查内存问题的神器mlir/面向 AI 和自定义编译器的多层 IR 框架目前最活跃的方向之一flang/Fortran 前端科学计算领域相关lldb/调试器和 LLVM 生态深度集成polly/基于多面体模型的循环优化偏学术但很有启发性clang-tools-extra/clang-tidy、clangd 等辅助工具日常开发非常依赖其中clang-tools-extra之所以单独拆出来一个目录是因为它不属于编译器核心流程而是服务于开发者日常工程体验的工具集。比如clangd现在很多编辑器都在用补齐了 C 的智能补全和跳转体验。从开发角度看在 monorepo 里做贡献的流程大概是fork 仓库到自己的 GitHub本地git clone创建一个 feature 分支写代码然后git push到自己的 fork再到上游开 Pull Request。上游对代码格式要求非常严格用的是clang-format和clang-tidy一起把关所以提交之前本地跑一遍检查是很有必要的。2. 从源码构建 LLVM一次帮你把依赖、配置和编译参数全部理清2.1 为什么建议自己构建而不是直接装包很多人用过 Ubuntu 的 apt 安装llvm或者 macOS 上的 Homebrew 安装llvm15会觉得“这不就装好了吗何必自己编译”如果你的需求只是跑一下clang编译普通的 C 程序确实没有必要自己构建。但如果你想做下面任何一件事自己从源码构建几乎是必然选择修改 LLVM 源码实验自己的新 Pass基于 LLVM 版本做交叉编译或定制工具链需要调整默认 target在非主流平台比如某些嵌入式环境或特殊 Linux 发行版上使用 LLVM调试 LLVM 自身的问题需要带 debug 信息的可执行文件用最新的 release 分支而非系统自带的旧版本。我自己第一次从源码构建是因为想给一个课程项目写一个自定义的 LLVM Pass。当时系统自带的 LLVM 是 10 版本而课程要求 14版本不匹配导致llvm-config给出的路径和自带的头文件对不上折腾了很久最后还是老老实实自己编译了。版本不匹配是 LLVM 开发里很典型的一个坑。LLVM 内部的 API 变化非常快甚至同一个大版本的不同小版本之间某些接口都会有微妙改动。写 Pass 的时候最好和你本地安装的 LLVM 完全同源否则链接阶段经常报一堆“undefined reference”或者声明与定义不匹配的错误。不要问我怎么知道的。2.2 构建前的准备与依赖检查如果要构建 LLVM建议准备一台至少 8 核 CPU、16GB 内存、30GB 以上空闲磁盘的机器。如果条件差一些也能编但耗时会长很多。我自己在 4 核 8GB 的笔记本上尝试过完整构建 Release 版 LLVMClang大概花了三个多小时期间内存一度逼近上限。依赖方面不同系统略有差异但核心依赖比较一致CMake建议 3.20 以上LLVM 版本越新对 CMake 版本要求越高一个能用的 C/C 编译器GCC 或 Clang 均可官方支持两者Ninja 构建系统比 make 快很多强烈推荐Python 3构建脚本和测试脚本需要用到zlib、libxml2 等常见开发库按发行版包管理器装上即可。以 Ubuntu 为例安装依赖的命令大致是sudo apt update sudo apt install cmake ninja-build python3 python3-pip build-essential \ zlib1g-dev libxml2-dev libncurses-dev如果是 Fedora则对应为sudo dnf install cmake ninja-build python3 python3-pip gcc-c \ zlib-devel libxml2-devel ncurses-devel2.3 CMake 配置的推荐姿势与参数解读LLVM 的构建系统基于 CMake配置方式是在源码根目录下创建一个 build 目录然后在其中运行cmake。我比较推荐的配置命令是这样的git clone https://github.com/llvm/llvm-project.git cd llvm-project mkdir build cd build cmake -G Ninja \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_INSTALL_PREFIX$HOME/llvm-install \ -DLLVM_ENABLE_PROJECTSclang;lld;clang-tools-extra \ -DLLVM_TARGETS_TO_BUILDX86;AArch64 \ -DLLVM_ENABLE_ASSERTIONSON \ -DLLVM_CCACHE_BUILDON \ ../llvm逐条解释一下这些参数的作用-G Ninja指定用 Ninja 作为构建工具。Ninja 的并行构建效率很高而且增量编译速度远快于 make。-DCMAKE_BUILD_TYPEReleaseRelease 模式。如果要调试 LLVM 自身或者写 Pass其实建议用RelWithDebInfo带调试信息的 Release这样既有优化后的性能又能用 gdb 打断点看变量。-DCMAKE_INSTALL_PREFIX安装路径。后续ninja install会把这些工具装到这里。-DLLVM_ENABLE_PROJECTS指定额外构建哪些子项目。注意LLVM 核心库默认一定会构建但 Clang、LLD 这些默认不构建需要在这里显式列出。-DLLVM_TARGETS_TO_BUILD指定需要生成代码的目标架构。默认会构建所有支持的后端包括 AMDGPU、BPF、Mips、PowerPC、RISCV、SystemZ、WebAssembly 等。如果只是日常使用只保留X86和AArch64就足够了可以显著减少编译时间。-DLLVM_ENABLE_ASSERTIONSON开启断言。调试阶段强烈建议开启很多 API 使用错误会在运行时直接报出来而不是静默产生错误结果。但 Release 发布版通常关闭它因为断言会拖慢性能。-DLLVM_CCACHE_BUILDON启用 ccache。如果你打算频繁改代码重新编译ccache 能省下大量重复编译时间真的是用过就回不去。提示如果你第一次构建不要犹豫直接加上-DLLVM_CCACHE_BUILDON。哪怕你只是做一次性的完整构建ccache 也能帮你节省后续所有增量编译的时间。配置完成后执行ninja如果机器性能不错可以并行度高一点ninja -j$(nproc)这个过程会比较久我建议第一次构建的时候不要把终端关了。如果中断继续跑ninja会从上一次断点继续。2.4 我踩过的构建相关的几个坑头一个坑和磁盘空间有关。默认构建全会生成大量目标文件和静态库我见过build目录膨胀到 60GB 以上的情况。所以一开始就要注意不要在空间紧张的分区下建 build 目录。另外如果你的系统是 Windows要额外注意 Visual Studio 版本和 CMake 生成器的匹配以及 Windows 上文件路径长度限制的问题。LLVM 源码里有些路径特别深Windows 默认的 MAX_PATH 260 字符限制会直接导致构建失败需要开启长路径支持。第二个坑和内存有关。链接clang这种巨型可执行文件时链接器要一次性把所有目标文件加载进内存如果内存不足会直接 OOM。我自己在 8GB 内存的机器上链接clang时系统直接卡死后来加了 swap 才勉强过去。建议如果你内存不大先只构建clang不要一次构建clanglldclang-tools-extra全套构建任务分几次进行会稳妥很多。第三个坑是系统 GCC 版本太老导致编译失败。LLVM 新版对编译器的要求也在提高比如 LLVM 19 要求至少 GCC 7.5 或 Clang 7 以上。如果你在老系统上编译新版 LLVM可能要先更新系统的编译工具链形成一个“先有鸡还是先有蛋”的小死结。解决办法是先用系统包管理器装一个较新的 Clang 或 GCC再用它来构建 LLVM。这个循环是常见操作不用慌。3. 理解 LLVM 三段式架构为什么说 IR 是整个项目的灵魂3.1 三段式设计与 GCC 传统路线的差异LLVM 的架构核心是“三段式”前端Frontend、优化器Optimizer、后端Backend。对应到代码仓库里前端主要是 Clang优化器是 LLVM 中处理 IR 的那一堆 Pass后端是生成目标机器码的部分。前端负责把源代码解析成 AST抽象语法树再做语义分析最后生成 LLVM IR中间表示。优化器对 IR 做一遍又一遍的 Pass 处理试图减少冗余计算、消除死代码、优化循环等等目标是不改变程序语义的前提下让程序跑得更快或者体积更小。后端把优化后的 IR 转换为目标机器的汇编代码再交给汇编器变成目标文件最后由链接器组合成可执行文件。GCC 也有类似的思路但 GCC 的 GIMPLE 中间表示主要是服务于 GCC 自身的外部工具要复用这套流程很困难。而 LLVM 从一开始就把 IR 设计成一个稳定的、可外部读取和修改的表示形式。这意味着你可以自己写一个工具读取.ll文件分析或改写 IR然后再把它喂回 LLVM 工具链继续处理。这种开放性是 LLVM 能成为一个“生态”的根本原因。3.2 LLVM IR可读、可控、可验证的中间表示LLVM IR 有三种存在形式可读文本形式.ll文件主要用于调试和理解二进制位码形式.bc文件体积小、加载快内存中的表示即LLVMContext里组织好的Module、Function、BasicBlock、Instruction等 C 对象。看一段最简单的 C 代码和它的 IR 对照int add(int a, int b) { return a b; }用clang -S -emit-llvm add.c -o add.ll命令生成; ModuleID add.c source_filename add.c target datalayout e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128 target triple x86_64-unknown-linux-gnu define i32 add(i32 noundef %a, i32 noundef %b) { entry: %add add nsw i32 %a, %b ret i32 %add }这个 IR 清楚地表现了几件事define i32 add表示定义了一个返回i32的函数函数名是addentry是一个基本块%add add nsw i32 %a, %b是把两个i32类型的值相加结果存到一个虚拟寄存器里ret i32 %add是返回结果。其中nsw表示“no signed wrap”即这个加法不会发生有符号溢出这个标记能帮助优化器在后续做更多代数化简。相比直接看汇编IR 保留了类型信息同时去掉了具体的寄存器分配、指令调度等后端细节。因此绝大多数优化 Pass 可以在 IR 层做而无需关心目标架构。同一个优化 Pass在 x86 上用在 ARM 上也能用在 RISC-V 上同样能用。这正是 LLVM 节省各后端重复劳动的核心手段。3.3 IR 生成与优化流程的完整工具链视角当你运行clang时它内部实际上是调用了前端生成 IR然后调用优化器对 IR 做优化。如果想单独看每一步可以用clang -S -emit-llvm foo.c -o foo.ll # 生成可读 IR opt -passesmem2reg,instcombine foo.ll -S -o foo_opt.ll # 跑优化 llc foo_opt.ll -o foo.s # 生成汇编这个流程解释了为什么 LLVM 的组件可以拆开使用clang负责前端opt是优化器入口llc是后端入口。每个工具都可以独立运行方便你做各种定制和研究。如果你对某段 C 代码的优化效果感到好奇可以分别在优化前后生成 IR 对比比如clang -O0 -S -emit-llvm test.c -o test_O0.ll clang -O2 -S -emit-llvm test.c -o test_O2.ll diff test_O0.ll test_O2.ll通过对比输出你能直观看到-O2下优化器帮你做了多少事情循环展开、内联、常量传播、死代码消除等等。这种“看 IR 变化来理解优化”的学习方式比直接看编译原理课本要实在得多。4. 实战写一个最简单的 LLVM Function Pass并把它跑起来4.1 Pass 是什么为什么开发 Pass 是常见的切入点LLVM 的优化器本质上是一个 Pass 流水线。一个 Pass 就是对 IR 做一次遍历和可能的修改比如“循环不变式外提”是一个 Pass“指令合并”是一个 Pass“死代码消除”也是一个 Pass。你写自定义 Pass就是在 LLVM 的优化流程中插入自己的分析或变换逻辑。写一个自定义 Pass 是学习 LLVM 最有效也最有成就感的途径因为你可以立刻看到自己写的代码在真实编译器流水线中被调起来并能通过 IR 输出验证效果。同时写 Pass 也是很多公司基于 LLVM 做定制优化的常见方式比如为某个专用芯片增加特殊的指令选择规则或者为内部编程语言实现新的优化策略。4.2 环境准备用 CMake 构建一个插件型 PassLLVM 的 Pass 可以以插件形式动态加载不需要重新编译整个 LLVM。我们只需要编译一个共享库然后用opt -load-pass-plugin...加载它。我以一个非常简单的 Pass 为例它的功能是遍历每个函数的每条指令打印出指令的操作码和所在函数名。这个 Pass 不做任何代码变换但足以验证环境是否正常、API 是否匹配以及你对 IR 结构理解是否正确。首先建立目录结构llvm-pass-demo/ ├── CMakeLists.txt └── src/ └── DemoPass.cppCMakeLists.txt内容如下cmake_minimum_required(VERSION 3.20) project(LLVMDemoPass) find_package(LLVM REQUIRED CONFIG) message(STATUS Found LLVM ${LLVM_PACKAGE_VERSION}) message(STATUS Using LLVMConfig.cmake in: ${LLVM_DIR}) include_directories(${LLVM_INCLUDE_DIRS}) add_definitions(${LLVM_DEFINITIONS}) add_library(DemoPass MODULE src/DemoPass.cpp) if(LLVM_ENABLE_RTTI) target_compile_options(DemoPass PRIVATE -fno-rtti) else() target_compile_options(DemoPass PRIVATE -fno-rtti) endif() target_link_libraries(DemoPass PRIVATE LLVMCore LLVMSupport LLVMPasses) set_target_properties(DemoPass PROPERTIES PREFIX )这里find_package(LLVM REQUIRED CONFIG)会去LLVM_DIR指向的位置找 LLVM 的 CMake 配置。要让它生效需要确保LLVM_DIR指向你构建出的lib/cmake/llvm目录。add_library(DemoPass MODULE ...)表示构建一个模块类型的动态库适合作为插件被opt加载。PREFIX 是为了让生成的.so文件不带lib前缀这样加载命令可以写成-load-pass-plugin./DemoPass.so比较清爽。DemoPass.cpp的代码如下#include llvm/IR/Function.h #include llvm/IR/Instruction.h #include llvm/IR/Instructions.h #include llvm/IR/LLVMContext.h #include llvm/IR/Module.h #include llvm/IR/PassManager.h #include llvm/Passes/PassBuilder.h #include llvm/Passes/PassPlugin.h #include llvm/Support/raw_ostream.h using namespace llvm; namespace { class DemoPass : public PassInfoMixinDemoPass { public: PreservedAnalyses run(Function F, FunctionAnalysisManager AM) { outs() Visiting function: F.getName() \n; for (BasicBlock BB : F) { for (Instruction I : BB) { outs() opcode: I.getOpcodeName() , operands: I.getNumOperands() \n; } } return PreservedAnalyses::all(); } }; } // namespace extern C ::llvm::PassPluginLibraryInfo llvmGetPassPluginInfo() { return {LLVM_PLUGIN_API_VERSION, DemoPass, LLVM_VERSION_STRING, [](PassBuilder PB) { PB.registerPipelineParsingCallback( [](StringRef Name, FunctionPassManager FPM, ArrayRefPassBuilder::PipelineElement) { if (Name demo-pass) { FPM.addPass(DemoPass()); return true; } return false; }); }}; }这段代码有几个关键点需要解释PassInfoMixinDemoPass是基于新 Pass Manager 的写法。LLVM 14 之后新 Pass Manager 已经全面接管优化流水线旧式的FunctionPass已经逐步被淘汰。写新 Pass 的时候建议直接用新的 API不要在新项目里写旧式 Pass。run(Function F, FunctionAnalysisManager AM)是每个函数都要执行一遍的入口FunctionAnalysisManager参数允许你在必要的时候请求其他分析结果比如AM.getResultLoopAnalysis(F)。PreservedAnalyses::all()表示这个 Pass 没有修改任何 IR所以优化器可以保留所有之前的分析结果。如果一个 Pass 改了 IR你需要返回PreservedAnalyses::none()或者指定保留哪些分析。这个细节影响性能但不影响正确性很多人刚开始会忽略。llvmGetPassPluginInfo这个函数是插件与 LLVM 之间的接合点。它返回一个PassPluginLibraryInfo其中包含插件 API 版本、插件名字、LLVM 版本和注册回调。在回调里我们用registerPipelineParsingCallback注册了一个可识别的 Pass 名字demo-pass这样我们在opt命令行中可以通过--passesdemo-pass来调用它。4.3 编译、加载和运行效果验证编译这个 Pass 之前需要确保LLVM_DIR指向正确的路径。如果你按前面的步骤把 LLVM 安装到了$HOME/llvm-install那么配置命令如下cd llvm-pass-demo cmake -S . -B build -DLLVM_DIR$HOME/llvm-install/lib/cmake/llvm cmake --build build编译成功后会生成build/DemoPass.so。然后我们写一个测试用的 C 文件int add(int a, int b) { int c a b; return c; } int main(void) { return add(2, 3); }先用clang生成 IR然后加载插件跑一遍clang -S -emit-llvm test.c -o test.ll opt -load-pass-pluginbuild/DemoPass.so --passesdemo-pass test.ll -S -o /dev/null正常情况下你会看到类似这样的输出 Visiting function: add opcode: add, operands: 2 opcode: ret, operands: 1 Visiting function: main opcode: call, operands: 1 opcode: ret, operands: 1这说明你的插件被成功加载并执行了也说明 IR 遍历逻辑正确理解到了每条指令的操作码和操作数数量。有一个细节值得注意如果编译插件时 LLVM 的 CMake 报错找不到包多半是LLVM_DIR没设置对。去找一下你安装目录下有没有lib/cmake/llvm/LLVMConfig.cmake这个文件路径指向那一层目录即可。如果你没有安装 LLVM 到指定 prefix也可以让LLVM_DIR指向 build 目录中的lib/cmake/llvm。4.4 调试 Pass 时的常用技巧写 Pass 的时候最常用的调试手段就是打印输出。LLVM 里不要用 C 的printf而应该用llvm::outs()和llvm::errs()因为它们能保证输出的时机和缓冲行为与 LLVM 的日志系统一致。如果你要看 LLVM 自带的某个 Pass 是否执行可以用--debug-pass-manager选项它会打印出 pass manager 的完整执行流程。此外opt --print-after-all是一个非常强大的调试神器它会在每个 Pass 执行后打印出整个模块的 IR你可以快速定位是哪个 Pass 在哪一步改变了 IR。不过这个输出量非常大通常要和--filter-print-funcs配合使用只打印某个具体函数的 IR 变化opt -load-pass-pluginbuild/DemoPass.so \ --passesdemo-pass,instcombine \ --print-after-all --filter-print-funcsadd \ test.ll -S -o /dev/null这样你可以精确看到demo-pass执行前后、instcombine执行前后add函数 IR 的差异。5. llvmpipe 到底是什么那个让你误以为“LLVM 坏了”的软件渲染器5.1 日志里的 llvmpipe 与 LLVM 本身的关系有一些读者可能是在显卡驱动日志、glxinfo输出或者 Chrome 的 GPU 进程日志里看到了llvmpipe这个词才会去搜索 LLVM。这个疑问很有代表性LLVM 和显卡是怎么扯上关系的llvmpipe 并不是 LLVM 工程本身的一部分它是 Mesa 3D 图形库中的一个软件渲染器实现。名字里的 “llvm” 是因为它借助 LLVM 的 JIT即时编译能力把图形渲染管线中的着色器编译成当前 CPU 能执行的机器码。你可以理解为当你的系统没有可用的硬件 GPU 驱动或者处于虚拟机、远程桌面等环境时Mesa 会退回到 llvmpipe用 CPU 来模拟 GPU 的功能。例如在 Linux 下运行glxinfo | grep OpenGL renderer如果看到类似OpenGL renderer string: llvmpipe (LLVM 15.0.7, 256 bits)这代表当前的 OpenGL 渲染器是 llvmpipe括号里的LLVM 15.0.7是 Mesa 所链接的 LLVM 版本256 bits是 CPU 的 SIMD 向量宽度256 位对应 AVX2。所以看到 llvmpipe 不代表 LLVM 项目出了什么问题也不一定代表你的显卡坏了。它只是说明图形栈正在使用 CPU 软件渲染作为回退方案。5.2 触发 llvmpipe 的常见场景与处置建议从实际经验来看以下几个场景最容易遇到 llvmpipe服务器或容器环境里没有 GPU但某些程序仍然请求 OpenGL/Vulkan 上下文虚拟机里没有启用 GPU 直通而且虚拟显卡驱动没有正确加载Linux 桌面环境下 GPU 驱动没有装好内核模块没有正确探测到显卡用远程桌面比如 VNC 或某些云桌面方案时GPU 加速不可用。如果你确实需要硬件加速可以按这个顺序排查先确认有没有独立显卡lspci | grep VGA再看系统负载glxinfo是否真的检测到了硬件渲染器然后是安装合适的驱动比如mesa-vulkan-drivers或 NVIDIA 的专有驱动。这些配置做完后重启 X 或 Wayland 会话再用glxinfo查看渲染器是不是变回了硬件型号。如果你的场景里并不需要 GPU 加速比如只是跑一个离线的 OpenGL 离屏渲染任务那么 llvmpipe 反而是个好消息它起码保证了程序不会因为没有 GPU 而直接失败退出。而且 llvmpipe 在正确配置的机器上性能并不差做一些离屏渲染或 CI 测试完全够用。我就在 CI 环境里用 llvmpipe 跑 OpenGL 相关的单元测试稳定得很。5.3 llvmpipe 用到的“256 bits”是什么日志里那个256 bits经常让人困惑以为它表示显存带宽或颜色深度之类的东西。其实它指的是 JIT 生成代码时 SIMD 向量寄存器的位宽。LLVM 后端在编译着色器时会尽量把多个像素的计算打包成向量指令用上 CPU 的 AVX2256 位、AVX-512如果需要且 CPU 支持等指令集。256 bits说明当前 llvmpipe 编译路径使用了 256 位宽的 SIMD 寄存器一次可以并行处理 8 个 32 位浮点数的运算。这个数字越大说明一次能并行处理的数据越多软件渲染的吞吐量就越高。但这并不代表你的 CPU 不支持更高位宽的向量而是 llvmpipe 在检测到 CPU 特性之后自动选择的一个合适档位。6. 进阶方向从会用到能改LLVM 生态的几条扩展路径6.1 后端的扩展TableGen 与新指令集支持如果你关注的不是优化而是想给一个新开发或非主流的处理器架构提供编译器支持那核心工作会落到 LLVM 后端。后端涉及的代码包括寄存器定义、指令集描述、指令选择、指令调度、汇编解析器等等。LLVM 用 TableGen 这门领域特定语言来描述这些信息而不是直接用 C 写死。TableGen 文件.td文件负责声明寄存器、指令、指令格式和模式匹配规则。举个例子在X86InstrInfo.td里能看到大量指令定义每条指令定义了助记符、操作数类型、编码和选择模式。而指令选择的核心是把 SelectionDAG 或 GlobalISel 中的 IR 节点匹配到具体的目标指令。修改这些.td文件再运行 TableGen 生成对应的 C 代码是后端开发的基本操作。这条路径比写前端或优化 Pass 要陡峭得多涉及计算机体系结构的知识需要沉下心看懂架构手册。但收益也大如果你想从事编译器后端开发这部分是硬功夫几乎没有捷径。6.2 前端的扩展Clang 与自定义语言支持如果想把一门新语言编译到 LLVM IR你有两条路一是复用 Clang 的框架把你的语言解析成 Clang 的 AST然后生成 IR二是完全独立写一个前端生成 LLVM IR 文件交给 LLVM 优化器处理。前者工作量大但能直接享用 Clang 的语义分析能力后者灵活度高不少小众语言就是这么做的。如果你只是想给小语言加一些实验性语法更轻量的做法是用 MLIR 的 Toy 教程起步。MLIR 本身是 LLVM 之上构建的一套可扩展中间表示框架非常适合做领域特定编译器和更高级别的抽象。6.3 工具链集成LLD 与 Sanitizer 的日常使用价值抛开源码开发不谈即便你只是在做一个普通的 C/C 项目llvm-project 里的 LLD 和 Sanitizer 也值得单独拎出来用好。LLD 的链接速度非常惊艳。我参与的一个大型 C 项目用 GNU ld 链接耗时 40 多秒切到 LLD 之后降到 7-8 秒。对日常开发来说这种体验提升是立竿见影的。用法很简单在 CMake 里设置-fuse-ldlld即可。Sanitizer 则是排查内存问题的利器。AddressSanitizerASan能检测 use-after-free、堆缓冲区溢出、栈缓冲区溢出等问题通常在 CI 中跑一轮 ASan 构建很多隐性问题就会原形毕露。它需要你在编译和链接时加上-fsanitizeaddress运行测试时会直接输出具体出错位置和调用栈。7. 学 LLVM 的路径建议少走弯路的几件小事结合我自己摸爬滚打的过程最后说几点实在的建议。第一不要一上来就啃 LLVM 的源码目录结构尤其是llvm/lib/Transforms/下面那几十个目录很容易迷失。更好的学习路径是先跑通一个最小 Pass理解 IR 的基本形式再针对你感兴趣的方向去读对应源码。以点带面效率远高于从头到尾通读。第二一定要自己亲手生成和修改 IR。很多人看了大量 IR 相关文章但自己从没手动打开过.ll文件也没有试着改改里面的数字看会发生什么。其实你只需要随便写个小函数clang -S -emit-llvm生成 IR然后手动把常数值改一改再llc生成汇编这种实验做几次IR 与机器码的对应关系就会熟很多。第三善用llvm-config和 CMake 的find_package。对做 LLVM 开发的人来说环境配置的坑往往比代码本身的坑更多。务必确认你写 Pass 时用的头文件版本和最终opt可执行文件的版本完全一致。不一致的时候各种奇异链接错误和运行时崩溃都会来问候你。第四关注 LLVM 的 release note。每个版本发布时llvm/docs/ReleaseNotes.rst都会列出破坏性变更和新增功能。升级 LLVM 版本前先扫一眼这个文件能帮你提前预判哪些代码需要改。LLVM 这个项目最迷人的地方在于它把“编译器”这个听起来非常古老和封闭的领域做成了一个高度模块化、可扩展的开放平台。你不需要掌握所有组件完全可以只从某一个点切入比如先读懂一个 Pass比如先弄明白opt工具怎么用再顺着自己的需求逐渐向外扩展。这个过程不会太快但每往前走一步你能做的事情都会多一个量级。
