我用接近一年的时间断断续续读完了 llvm-project 的几个核心仓库又从零开始把 LLVM 15.0.7 完整构建过两遍期间还顺带折腾了 Clang、LLD、compiler-rt、libc 和 MLIR 这些子项目。这篇文章不是教材也不是源码注释翻译而是把我自己从“只知道 clang 能编译 C”到“能看懂 LLVM 代码结构、能自己写简单 Pass、能调链接错误、能分辨 llvmpipe 和 GPU 驱动的区别”这段过程中的理解整理出来希望对想碰 LLVM 但一直觉得无从下手的读者有点帮助。1. 先搞清楚 llvm-project 到底是个什么东西很多人第一次接触 LLVM心里是懵的有人说它是一个编译器有人说它是一个虚拟机还有人管它叫“底层虚拟机”。这些说法都不太准确。LLVM 的全称虽然确实是 Low Level Virtual Machine但现在的 LLVM 已经远远超出“虚拟机”这个概念更准确的说法是一套模块化的编译器基础设施。所谓“基础设施”意思是它不直接给你一个开箱即用的完整编译器而是提供一大堆积木让你能拼出编译器、代码分析工具、代码生成工具、运行时库甚至 GPU 驱动里的着色器编译器。llvm-project 这个仓库就是所有这些积木的集合。它并不是一个单一项目而是被拆成很多子项目的“超级仓库”。我最初看的时候经常被目录吓到llvm-project 根目录下有几十个文件夹不能每个都看得先知道谁负责干什么。1.1 子项目地图llvm-project 家族的组成先列一个我后来确认过、又按实际用途简化过的子项目地图llvm核心库包含 IR、优化 Pass、目标描述、代码生成、汇编器、链接器等底层功能。整个 LLVM 存在于llvm/lib和llvm/tools/opt里。我们常说的“LLVM Core”就是它。clangC、C、Objective-C 的前端负责解析源码生成 AST最后翻译成 LLVM IR。这是绝大多数人最熟悉的入口日常clang -O2 main.c走的就是它。lld新的链接器特点是快。日常构建 C 项目如果觉得 GNU ld 太慢换成 lld 有立竿见影的效果。libcC 标准库实现专门给 Clang 配合用的。compiler-rt编译器运行时库里面包含很多内置函数、sanitizer地址消毒器、未定义行为消毒器等的实现、profile 相关的运行时还有libfuzzer。mlir多层 IR 框架多用于做机器学习编译器也承载了很多芯片厂商的编译器项目。lldb调试器对应 GNU 那一堆里的 gdb。clang-tools-extraclangd、clang-tidy、include-what-you-use 这类工具。polly多面体优化主要做循环变换。flangFortran 前端。llvmpipe软件光栅化器它属于 Mesa 那边经常提到但 LLVM 本身也提供底层支持。它用 LLVM 的 JIT 能力把图形着色器编译成 CPU 指令运行在没有 GPU 的环境里。这张图里的子项目之间不是简单的并列关系。llvm 核心库是底座clang 和前端们把高级语言翻译到 IRllvm 接着做优化和 codegenlld 负责把目标文件合成可执行文件compiler-rt 提供运行时支援mlir 又把 IR 概念向上抽象了几层。整个是一个从语言到二进制的流水线。1.2 为什么值得专门去研究它我从实际开发里的体验来说之所以值得花时间研究 LLVM不只是因为它“很火”或者“GCC 太老土”。更实际的原因有三个第一它让你真正理解编译过程的每一层。你写的一行x y不是直接变成一条指令而是先被 Clang 解析成 AST然后被降级成 IR经过一系列优化再被翻译成目标机器的指令。每一层都对应一段可读的代码或文本你可以把中间状态打印出来这一点比 GCC 或者 MSVC 透明太多。第二它已经成为工业界的通用底座。除了 Apple 的编译工具链之外Android NDK、Rust 的后端、Zig、Swift甚至很多私有芯片的编译器都基于 LLVM 构建。学会了 LLVM 的结构这些工具链对你就不是黑盒。第三它的代码组织方式是很大的设计样本。llvm-project 里的 TableGen、Pass 架构、优化流水线、指令选择框架每一样单独拎出来都够写几十篇深度文章。能读懂这套架构对写大型 C 工程也有帮助。2. 把 LLVM 当成一条“翻译流水线”来理解我在读源码的过程中最深的感受是LLVM 的一切设计都是为了把“编译”这件事拆分成清晰、可组合、可复用的阶段。整个 LLVM 的核心设计思想可以用一个非常朴素的比喻讲清楚你有一篇中文文章要翻译成英文但你不是直接从中文逐词翻成英文而是先翻译成“一种所有人都能看懂的国际通用语”然后在这门通用语里做润色、精简、调整语序最后再翻译成英文。这门“通用语”就是 LLVM IR前面负责把各种高级语言翻译成 IR 的是前端后面负责把 IR 翻译成各 CPU 指令的是后端。2.1 三段式架构前端、中端、后端LLVM 把传统编译器区别得最清楚的地方就是三部分独立前端Frontend负责语法分析、语义分析、生成 AST最后生成 LLVM IR。Clang 是 C/C/ObjC 的前端Rust 也有基于 LLVM 的后端前端语言可能是 Rust 自己的 HIR/MIR。中端Optimizer / Middle-end拿到 IR 之后不知道它是 C 写的还是 Rust 写的只做与语言无关的优化。函数内联、循环展开、常量传播、死代码消除都在这里做。后端Backend / CodeGen把优化后的 IR 变成目标机器的汇编或机器码需要处理指令选择、寄存器分配、指令调度等硬核问题。这种拆分最大的好处是如果芯片厂商想支持一门新语言只要写前端如果想支持一个新架构只要写后端。两边互相独立不用从头造轮子。2.2 LLVM IR 看起来到底是什么样子我最早被吓到的地方就是 IR因为总感觉它既不像汇编也不像 C。后来把例子跑了一遍才意识到它其实很有规律。一个最简单的 C 函数int add(int a, int b) { return a b; }用clang -S -emit-llvm add.c -o add.ll编译再打开add.ll你会看到类似这样的 IRdefine i32 add(i32 noundef %a, i32 noundef %b) { entry: %add add nsw i32 %a, %b ret i32 %add }这里面值得留意的点add前带表示全局函数或全局变量%a、%b前带%表示局部值。i32是 32 位整数类型。add nsw i32 %a, %b这条指令做了加法nsw表示“no signed wrap”无符号溢出这是一个给优化器用的标志。更重要的设计是 SSA静态单赋值形式每个变量只能被赋值一次。比如一段复杂的 C 代码经过 Clang 生成 IR 后所有临时中间结果都会变成一个新的%1、%2、%3……这种形式天生就适合做数据流分析和优化减少了很多其他编译器需要额外分析的麻烦。2.3 优化流水线Pass 是怎么一个个串起来的中端优化在 LLVM 里是以“Pass”为单位组织的。一个 Pass 就是对 IR 做一趟遍历或变换比如做完死代码消除的 pass再做一遍循环展开的 pass每个 pass 都是相对独立的模块。LLVM 的优化流程可以在命令行里显式控制。用opt工具单独跑某个 pass 是非常常见的调试手段。假设我写了一个 pass 路径想看它单独作用的效果可以这样clang -S -emit-llvm foo.c -o foo.ll opt -passesinstcombine -S foo.ll -o foo_optimized.ll-passes参数指定 pipeline旧版本也可以用-instcombine这种短横线名称但我个人建议新代码一律用-passes的 new pass manager 语法。因为 LLVM 15 之后 old pass manager 相关接口已经逐步移除了很多网上的资料还停留在旧写法踩坑得很明显。Pass 的返回值、依赖关系、如何声明这些代码写多了之后会形成肌肉记忆。对于第一次接触的人来说关键是理解一个事实编译器优化不是一次性把一个函数变成最优的而是不同 pass 反复作用互相配合收敛到更好的结果。所以你在一个 pass 里看到的效果很有限但整个流水线叠加起来提升非常明显。3. 从 llvm-project 仓库获取源码并构建一次完整的 LLVM聊完设计思想该动手了。源码级别的实践第一步就是拉代码和构建。这一步有很多细节稍不注意就是几个小时的等待之后才发现配置错了。我在这里把过程完整捋一遍。3.1 从 GitHub 拉取代码llvm-project 的官方仓库在 GitHub路径就是代码库本身。直接完整 clone 有点大仓库带历史可能在几个 GB 级别。我习惯做浅克隆只拿最新的历史记录这样省时间又省磁盘git clone --depth1 --branch llvmorg-15.0.7 https://github.com/llvm/llvm-project.git这里我特意选了llvmorg-15.0.7这个 tag因为之前很多实验都基于 15.0.7 验证过。如果读者想用更新的版本也没问题但构建选项有些地方可能有细微差异需要看对应版本的文档。浅克隆之后如果不小心切分支可能会因为深度限制报错。所以如果是想深度研究某个模块的 git 历史建议再单独git fetch --unshallow。3.2 环境准备与磁盘规划构建 LLVM 最容易被低估的是磁盘和内存。我头一次构建没规划好直接在磁盘剩 40G 的时候开跑结果中途爆了。这里说一下我的经验值完整构建所有子项目源码之外需要大约 30~50GB 磁盘空间。如果只构建clang、lld、llvm这几个目标大概 20GB 左右就够。内存少于 8GB 的话建议限制并行任务的并发数否则容易 OOM。系统方面Linux 上需要cmake、ninja、gcc或clang、python3以及zlib、libxml2之类的开发库。macOS 上安装 Xcode Command Line Tools 就行。Windows 上比较麻烦得用 Visual Studio 的生成器我一般不推荐在 Windows 上直接全量编译除非特定场景。3.3 用 CMake Ninja 完成构建的推荐配置LLVM 官方文档推荐用 CMake 和 Ninja我自己也是这么用的。下面是一个经过实测、比较平衡的配置cd llvm-project mkdir build cd build cmake -G Ninja -DCMAKE_BUILD_TYPERelease \ -DLLVM_ENABLE_PROJECTSclang;lld \ -DLLVM_TARGETS_TO_BUILDX86;AArch64 \ -DLLVM_ENABLE_ASSERTIONSON \ -DCMAKE_C_COMPILERclang \ -DCMAKE_CXX_COMPILERclang \ ../llvm然后ninja clang lld如果想把所有项目都编了可以直接ninja。但我不建议一开始就这么干因为时间很长。只编clang和lld可以很快拿到可用的工具链。配置里几个选项的解释LLVM_ENABLE_PROJECTS指定要构建哪些子项目。子项目之间用分号分隔而且必须放在引号里否则 CMake 解析容易出现诡异问题。LLVM_TARGETS_TO_BUILD指定后端目标架构。全量构建默认会包含很多 target我一般只留 X86 和 AArch64能大幅缩短编译时间。LLVM_ENABLE_ASSERTIONS开启断言。开发调试时强烈建议打开能让很多错误提前暴露。但如果只要一个朴素的 release 工具链为了性能也可以关掉。CMAKE_BUILD_TYPERelease影响优化等级和调试信息Release 模式下 pass 运行最快。编译过程中时常会遇到单个 C 文件把内存吃满的问题。如果系统内存紧张我一般用-j 4或-j 8来控制并行度比如ninja -j8 clang lldNinja 的默认并行度可能直接拉满所有核心机器差一点就卡死了新手很容易在这里被劝退。3.4 构建完成后怎么确认装好了构建生成的工具默认在build/bin目录下。我刚构建完的时候习惯先跑一个版本命令确认./bin/clang --version ./bin/llc --version ./bin/opt --version然后写个 hello world 测试int main() { return 42; }./bin/clang -O2 hello.c -o hello ./hello echo $?能输出42基本说明工具链是可用的。4. 实操用 clang / opt / llc 亲手拆解一段代码的编译过程前面构建出了工具链现在用来做一件最有意思的事情亲手把一段代码从 C 语言变成最终汇编并且每一步都亲眼看一看。这个流程能让你把“三段式架构”从概念变成体感。4.1 生成 IR 并观察优化效果先准备一份带点计算的 C 代码方便看到优化的变化int square(int x) { return x * x; } int compute(int n) { int sum 0; for (int i 0; i n; i) { sum square(i); } return sum; }第一步生成未优化的 IRclang -S -emit-llvm test.c -o test.ll打开test.ll你会看到square和compute两个函数以及store、load这类指令。未优化时循环里的变量全在栈上存取看起来很啰嗦。第二步生成优化后的 IRclang -S -emit-llvm -O2 test.c -o test_opt.ll这时候square很可能已经被内联到compute里循环也做了很多变换。我对比过两版 IR差异非常明显。这个对比是理解“优化 pass 的作用”最直观的实验。4.2 使用 opt 单独执行某个 Pass如果想单独看某个 pass 的效果可以用opt。例如我想看mem2reg提升内存为寄存器的 pass的作用clang -S -emit-llvm -Xclang -disable-O0-optnone test.c -o test.ll opt -passesmem2reg -S test.ll -o test_mem2reg.ll不过我实际用clang -O0生成的 IR 里函数会带optnone属性直接跑很多 pass 不生效。所以我上面用了-Xclang -disable-O0-optnone来去掉这个属性。这个细节是我踩过坑之后才明白的。如果你自己写了新的 LLVM pass想快速验证一般就是把opt挂载上你的 pass 插件然后输入 IR 文件看输出 IR 是否符合预期。这是 LLVM 开发最正常的调试循环。4.3 用 llc 查看最终后端生成的汇编llc是 LLVM 的静态编译器后端工具能把 IR 变成汇编或者目标文件。看汇编最直接clang -S -emit-llvm -O2 test.c -o test.ll llc test.ll -o test.s打开test.s你能看到 X86 汇编。如果想看 ARM64 的可以指定目标llc test.ll -mtripleaarch64-linux-gnu -o test_arm64.s这里的-mtriple指定目标三元组。它能帮你在 x86 机器上生成其他架构的汇编不需要交叉编译器也能研究指令选择过程。4.4 链接中的 LLD 与常见错误排查当代码从.s变成.o最后就需要链接。LLVM 自带的链接器是 lld它在处理大型 C 项目时往往比 GNU ld 快很多。日常使用我经常这么切换clang -O2 -fuse-ldlld main.cpp -o main如果项目用 CMake 构建在配置时可以这样设cmake -DCMAKE_EXE_LINKER_FLAGS-fuse-ldlld ..LLD 除了快错误信息也一般更友好。特别是链接 C 时最常见的“undefined reference”它会给出更清晰的符号归属信息。但也别指望它全知全能遇到 LTO 相关问题时错误信息一样会很绕。我见过最崩溃的链接错误是符号版本脚本和 LTO 一起使用时产生的奇怪报错当时只能一点点把-flto去掉排查最后发现是 ld.lld 对某个 section 保留策略的处理跟 GNU ld 不同。5. 再深一层手写一个最简单的 LLVM Pass如果只是用工具链其实不需要懂太多内部原理。但真正的乐趣和深度都在写 Pass 和改后端代码里。我建议每一位想深入了解 LLVM 的读者都亲手写一个简单的 function pass哪怕只是打印函数名。5.1 Pass 的种类Module、Function、Loop、BasicBlockLLVM 的 Pass 有几种作用粒度ModulePass作用于整个 module。适合做全局分析。FunctionPass/FunctionAnalysisManagerPass作用于每个函数。大多数优化都是这个级别。LoopPass作用于循环。BasicBlockPass作用于基本块。现代 LLVM 使用 New Pass Manager注册方式已经模板化了。写 pass 时一般从一个AnalysisInfoMixin或者PassInfoMixin派生然后实现run方法。5.2 准备一个可以独立编译的 Function Pass下面这个例子我验证过能直接在 LLVM 15 上跑。它遍历所有函数打印函数名和参数数量#include llvm/IR/Function.h #include llvm/IR/Module.h #include llvm/IR/LegacyPassManager.h #include llvm/Pass.h #include llvm/Passes/PassBuilder.h #include llvm/Passes/PassPlugin.h #include llvm/Support/raw_ostream.h using namespace llvm; namespace { class PrintFunctionPass : public PassInfoMixinPrintFunctionPass { public: PreservedAnalyses run(Function F, FunctionAnalysisManager AM) { errs() Function: F.getName() , args: F.arg_size() \n; return PreservedAnalyses::all(); } }; } // namespace extern C ::llvm::PassPluginLibraryInfo LLVM_ATTRIBUTE_WEAK llvmGetPassPluginInfo() { return {LLVM_PLUGIN_API_VERSION, PrintFunctionPass, LLVM_VERSION_STRING, [](PassBuilder PB) { PB.registerPipelineParsingCallback( [](StringRef Name, FunctionPassManager FPM, ArrayRefPassBuilder::PipelineElement) { if (Name print-function) { FPM.addPass(PrintFunctionPass()); return true; } return false; }); }}; }这段代码里关键的几个概念:PassInfoMixin是 New Pass Manager 的 mixin 基类。run方法返回PreservedAnalyses表示这个 pass 保留了哪些分析结果。如果不确定最保守的是返回PreservedAnalyses::all()表示什么都不破坏。但如果你修改了函数内容就该返回PreservedAnalyses::none()否则容易导致后续 pass 用了过期的分析结果产生很难查的 bug。最后那个llvmGetPassPluginInfo是动态库插件导出的标准入口编译之后可以用opt -load-pass-plugin加载。5.3 编译插件并在 opt 中使用把上面的文件保存为PrintFunctionPass.cpp用clang编译成动态库clang -shared -fPIC \ -I/path/to/llvm-project/llvm/include \ -I/path/to/llvm-project/build/include \ PrintFunctionPass.cpp \ -o libPrintFunctionPass.so注意build/include是 CMake 构建过程中生成的头文件目录里面有llvm/Config/llvm-config.h等文件。源码 include 目录加上 build include 目录缺一不可。然后找一个 IR 文件加载插件跑一下opt -load-pass-plugin./libPrintFunctionPass.so \ -passesprint-function \ -disable-output test.ll如果看到控制台打印了函数名和参数数量说明 pass 工作正常。这一步跑通之后你就真正具备了“给 LLVM 添加自定义编译优化能力”的基础。后面的方向可以是写常量折叠、死代码消除、内联策略自定义等等。不管哪种调试思路都一样编成插件用 opt 加载看 IR 变化。5.4 关于 Legacy Pass 的兼容性经验网上很多教程还在用legacy::FunctionPass和RegisterPass那套接口。在 LLVM 14 之后legacy pass manager 在新代码里已经逐渐被边缘化。我自己第一次写 pass 时参考的是旧文章代码能编过但是警告一大堆运行方式也和旧版本不一样。所以我的建议是直接用New Pass Manager接口写新代码。旧代码可以看懂思想但不用照着抄。遇到接口差异最有效的办法是去llvm/include/llvm/Passes/PassBuilder.h里查函数声明它比任何旧教程都可靠。6. 深入理解 llvmpipe 与 256-bit 向量LLVM 在图形/性能领域的影子聊到这里“llvm-project” 的核心脉络已经讲得差不多了。但有网友在热词里提到llvmpipe (llvm 15.0.7, 256 bits)这个组合很有意思它把 LLVM 引向了一个很多人不太注意的领域图形渲染与高性能计算。6.1 llvmpipe 是什么和 LLVM 有什么关系llvmpipe 是 Mesa 项目里的一个软件渲染器它用 LLVM 的 JIT 引擎在 CPU 上动态生成渲染代码。当系统没有可用 GPU 驱动时或者用户强制用软件渲染时llvmpipe 会把 OpenGL / Vulkan 的着色器编译成 CPU 指令然后靠多核 CPU 完成光栅化。我在一台无 GPU 的虚拟机上跑过 Vulkan 应用mesa 会自动加载 llvmpipe虽然帧率很低但至少能跑。它背后的工作原理可以这样理解GPU 驱动里有一个着色器编译器把 GLSL 翻译成 GPU 指令而 llvmpipe 把这个编译器目标从 GPU 指令替换成了 LLVM IR再用 LLVM 的 JIT 生成当前 CPU 的机器码。所以 llvmpipe 不是 llvm-project 仓库里的一个目录Mesa 在调用 LLVM 的 API但它完全建立在 LLVM 的基础能力之上。可以说没有 LLVM软件渲染就很难做到这种跨 CPU 架构的动态优化能力。6.2 “256 bits” 指的是什么热词里提到 “256 bits”指的是 LLVM 后端在 x86 平台上可以利用 256 位向量寄存器 AVX2/AVX 等指令集进行 SIMD 计算。llvmpipe 编译出的代码会尽量把多个像素、多个顶点的计算打包到同一组向量指令里。如果你在 x86 机器上跑clang -marchnativeLLVM 后端的向量化器会识别代码里的并行模式生成 YMM 寄存器相关的指令。这些 256 位寄存器可以一次处理 8 个 32 位整数或者 8 个单精度浮点数这就是性能飞升的基础。我可以拿一个简单的例子说明向量化void add_array(float *a, float *b, float *c, int n) { for (int i 0; i n; i) { c[i] a[i] b[i]; } }用clang -O3 -mavx2 -S编译生成的汇编里会看到很多vaddps ymm0, ymm1, ymm2这样的指令。vaddps是一次性对 256 位寄存器里的多个单精度浮点数做加法。如果没有开向量化可能就是addss一次次处理单精度浮点性能差一个量级。“llvm 15.0.7, 256 bits” 这种信息通常出现在打印 log 或者软件渲染的 debug 输出里表示当前的 llvmpipe 构建基于 LLVM 15.0.7而且它认为当前 CPU 支持 256 位向量指令。如果 CPU 支持 AVX-512还可能出现 512 bits 的字样性能更强。6.3 向量宽度对软件渲染和通用代码优化的启示从这里能引出一个关键经验在 x86 平台上做性能优化首先要想代码是否适合做 SIMD 向量化其次才是考虑缓存、多线程这些东西。LLVM 的自动向量化能力很强但前提是循环结构足够规整不存在过多的复杂依赖和分支。我给普通开发者的建议是优先开启-O2或-O3让 LLVM 自动向量化。尝试用-marchnative让编译器使用本机 CPU 支持的指令集但要注意部署环境是否一致否则二进制可能在其他机器上无法运行。如果循环的迭代之间没有依赖可以适当使用#pragma clang loop vectorize(enable)引导编译器向量化。要是追求极致性能可以手动写__m256类型的内部函数但开发成本高而且可读性差非必要不推荐。llvmpipe 的例子也说明LLVM 不仅可以把高级语言编译成目标文件还能在运行时 JIT 编译这对很多软件项目都是隐藏能力。类似的应用还包括 OpenCL CPU 设备、WebAssembly 的 JIT 编译等。7. 给刚入门的开发者源码阅读顺序与避坑指南最后一块内容讲一点我个人的学习路径和踩坑记录。如果你准备长期和 llvm-project 打交道一个合理的阅读顺序能帮你少走很多弯路。7.1 推荐阅读顺序我自己的顺序大致是先读llvm/include/llvm/IR下的头文件了解Module、Function、BasicBlock、Instruction、Value、Type这些核心类的关系。这是所有其他模块的基础。再看llvm/lib/IR下的实现理解这些类怎么被创建和操作。然后跑一遍官方的llvm/examples/Kaleidoscope教程这是一个完整的“实现一门新语言并生成 LLVM IR”的教程。能真正让人把前端的语义和后端的 IR 生成串联起来。接着写一个简单 Pass像上面那个插件体会 pass 机制。再往深走就可以研究llvm/lib/Transforms/InstCombine、llvm/lib/CodeGen/SelectionDAG等具体模块。这套顺序的好处是每一步的知识都能被下一步用到不会出现“读了很多概念但用不起来”的情况。7.2 常见坑C 模板、TableGen、CMake 构建第一条坑LLVM 用了大量现代 C 特性模板元编程、CRTP、Mixin 都很常见。如果平时主要写业务代码刚开始读 LLVM 源码会有很强的陌生感。不用焦虑先看函数名、注释以及面向使用者的接口别一上来就扎进特别深的模板实现里。第二条坑TableGen是 LLVM 自定义的一种描述语言用于描述指令集、寄存器、Pass 参数等。在后端开发里几乎无处不躲。不熟悉的时候会觉得很别扭但它其实就是一种高级 DSL生成的.inc文件才是真正参与编译的代码。如果看不懂某个.td文件可以看它生成的.inc有时候能豁然开朗。第三条坑CMake 配置出错。最经典的问题是LLVM_ENABLE_PROJECTS的值必须用引号包裹否则分号会被 shell 拆成两个参数。另外修改了 CMake 缓存后不会自动清理旧配置遇到诡异问题可以直接删掉 build 目录重建。第四条坑构建太慢。缓解办法是不要默认构建所有 target只保留需要的目标使用ccache缓存编译结果增量构建尽量只跑ninja clang或ninja lld这种局部目标。我自己第一次全量构建花了几个小时二次基于 ccache 构建快到可以接受。7.3 快速定位代码的实用工具平时阅读和调试 LLVM我常用的工具有llvm-dis把 bitcode.bc转回 IR 文本。llvm-as把 IR 文本转成 bitcode。opt -print-after-all打印每个 pass 之后的 IR。这在排查“哪个 pass 把代码变坏了”时极其有用。clang -Rpassloop-vectorize -Rpass-missedloop-vectorize打印向量化成功/失败的诊断信息做性能分析时很爽。llvm-symbolizer配合 sanitizer 输出的堆栈信息使用能还原出源码行号。有些问题还需要用git log和git bisect定位引入嫌疑的 commit。特别是你在新版本上发现行为变化但旧版本正常的时候bisect 是最科学的办法。8. 一个老实践者的最后建议研究 llvm-project 不是一蹴而就的事。它体量巨大领域横跨编译原理、操作系统、底层体系结构、语言标准、图论优化、并发编程。任何人都不可能在一两篇文章里“学会 LLVM”但反过来只要你坚持每天花一点时间去读、去编、去跑它的回报也比大多数技术栈都更扎实。我到现在仍记得第一次自己写的 pass 成功改变 IR 输出的那种兴奋感。那时候我终于明白那些看似深不可测的编译优化不过是成千上万个严格定义的 Pass 在按规则反复“修理”代码。LLVM 最大的价值不在于某一个优化特别神而在于它把整个编译过程体系化了、工程化了、工业化了你不需要成为天才才能参与只要有耐心人人都能在这套体系里找到自己可以改进和贡献的位置。如果你现在还在观望我的建议只有一个立刻新建一个 build 目录先跑一遍 LLVM 15.0.7 的构建然后写一个打印函数名的 pass加载进 opt 里看一眼输出。走完这一圈你就已经比昨天更接近 LLVM 的核心了。