1. LLVM 项目到底是个什么东西如果你去 LLVM 官网会看到一句话The LLVM Project is a collection of modular and reusable compiler and toolchain technologies。翻译过来其实特别直白LLVM 是一个模块化、可复用的编译器和工具链技术集合。这话听起来正经但它的分量只有真正去编译过、去调试过、去折腾过它的人才知道。我最早接触 LLVM 还是在大学课堂上老师发了一份源代码说你们自己把它编译出来。我当时以为这就是一个“编译器”而已跟 GCC 差不多的东西。结果一打开源码就傻眼了这哪是一个编译器这是一整座工厂里面光是目录就能把人看到眼花llvm、clang、lld、libc、compiler-rt、polly、mlir、flang……每一个目录单独拿出来都能撑起一个开源项目。那种感觉就像是以为你在学怎么开一辆车结果发现你被丢进了一座汽车制造厂里面从零件铸造到整车组装什么都有。后来做编译器方向的工作才慢慢理解 LLVM 的真正价值。它不是一个像黑盒子一样的编译器而是一整套“可拼装的编译基础设施”。传统编译器的套路是前端把源码变成中间表示后端把中间表示变成机器码中间再插一个优化器。大多数编译器这三部分是焊死的你要想改任何一块都得把整条链路重新弄一遍。而 LLVM 不一样它的前端、中端、后端是被刻意拆开、用标准接口连起来的这意味着你可以单独替换任意一部分。最典型的例子就是 Clang它其实只是 LLVM 生态里的一个 C/C/Objective-C 前端。苹果在造它的时候初衷就是想做一个比 GCC 更开放、更容易改的前端。而 LLVM 的核心是一个叫 LLVM IRIntermediate Representation的中间表示和一套极其强大的优化器。前端随便换只要最后能生成 LLVM IR后面所有优化和后端工作就都能直接继承。这一点在现实世界中的影响太深了几乎改变了整个编译工具链行业的玩法。什么人需要关注 LLVM如果你只是写写应用代码那确实用不到它你只是它的终端受益者。但如果你是搞编译器的、做高性能计算的、做算子优化的、做嵌入式工具链的、研究程序语言设计的或者说你用了 Android Studio、Xcode、Visual Studio 里的某个新特性那么你每天的工作都可能踩在 LLVM 的肩膀上。连 Rust、Swift、Julia 这样的新一代语言都把自己的代码生成部分交给了 LLVM。这篇文章聊的既是整个 LLVM 项目的大轮廓也是 LLVM 15.0.7 这个具体版本里我认为值得玩味的几个细节尤其是 llvmpipe 和 256 位向量支持这条路到底是怎么一路走过来的。2. LLVM 核心组件与关键设计思想2.1 LLVM IR为什么中间表示如此关键如果你只能记住 LLVM 的一个概念那一定要记住 LLVM IR。它长得很像汇编语言但不是针对任何真实 CPU 的汇编它有寄存器、有指令、有基本块但又比汇编抽象得多。它保留了变量类型、函数调用关系、控制流结构等高层信息同时又把具体 CPU 的细节全部抹掉了。举个例子你在 C 语言里写一句 a b c * 2Clang 会把它变成类似下面的 LLVM IR%1 load i32, i32* %b, align 4 %2 load i32, i32* %c, align 4 %3 mul i32 %2, 2 %4 add i32 %1, %3 store i32 %4, i32* %a, align 4这里的 niload、mul、add、store 都是 LLVM IR 指令i32 表示 32 位整数。这个 IR 的好处是它既能被优化器分析又能被后端翻译成任何目标机器的指令。x86 的人可以用它生成 AVX 指令ARM 的人可以用它生成 NEON 指令RISC-V 的人可以用它生成 vector extension 指令。在整个编译过程中前端负责“理解”源码语义后端负责“适配”硬件能力而 IR 就是这两者之间最干净的接口。这种设计最直接的收益是后端团队的辛苦可以同时服务所有语言前端团队的努力也可以同时覆盖所有硬件。苹果当年能在短短几年内让 Clang 达到生产级稳定性很大程度上就是靠了 LLVM 后端本来就成熟的缘故。为什么大家都要搞 IR因为硬件和语言都在不停地变化如果一个编译器在两三百年间只维护一套前后端紧耦合的代码改动任何一个指令集扩展都要重写一整套东西那它迟早会被时代拖垮。LLVM IR 的模块化设计把这种“变化”隔离在了接口和模块内部这是它这么多年还能越活越年轻的最重要原因。2.2 优化管线Pass Pipeline与 LLVM 15 的变化优化器本身也是一个值得展开的话题。LLVM 的优化器不是一整个巨型算法而是一个个“Pass”优化趟串联起来的管线。每个 Pass 只负责做一件小事有的 Pass 负责删掉永远不可能执行的代码有的负责把乘法改成移位有的负责把循环里不变的表达式提到循环外面有的负责做内联。优化管线设计得好的地方在于你可以像搭积木一样给不同的编译场景选择不同的 Pass 组合。编译时用 -O0就是几乎不跑任何优化 Pass只做语法分析和基础翻译用 -O2就跑一长串标准优化链在编译速度和运行速度之间取一个平衡用 -O3再额外开启更多激进的向量化、循环变换优化。在 LLVM 15 这个版本上优化管线的变化值得一说。前一年有人吐槽说 LLVM 14 的某些代码生成路径在某些基准上不如 GCC于是 LLVM 开发者在 15 里重点做了几类改进一个是把循环优化器LoopPassManager管得更细了另一个是提升了函数属性推断的准确性还有就是对 Swift、Rust 等语言的前端代码生成做了大量适配。另外一个经常被忽略的东西是 ModulePass 和 FunctionPass 的区别。ModulePass 能看见整个编译单元也就是一个源文件编译形成的那个模块FunctionPass 只能看见一个函数。绝大多数的标量优化比如常量传播、死代码消除都是 FunctionPass因为在一个函数内部做分析简单高效。但跨函数的优化比如函数内联、全局常量传播就需要 ModulePass 来看更大的图景。编译器领域的很多性能提升其实都是因为编译器能“看得更远”能跨函数、跨模块地做分析而在 LLVM 15 中这套全局分析的机制做了不少完善。2.3 后端代码生成指令选择、寄存器分配、指令调度很多人以为后端就是把 IR 翻译成汇编就行了实际上这中间的复杂度绝对不输给前端。一个 IR 指令可能在目标机器上有好几种实现方式你得从中选择最优的那个这就叫指令选择。IR 里的虚拟寄存器数量可以无限多但真实 CPU 的寄存器数量就那么几十个谁的值该放在寄存器里谁该被挤到内存里这就叫寄存器分配。现代 CPU 有流水线、有乱序执行、有的指令延迟大有的指令吞吐高指令和指令之间怎么排序性能最好这就叫指令调度。这三件事在后端代码生成里环环相扣。LLVM 15 时代x86 后端对 AVX-512 和 AVX2 的支持已经非常成熟判断一个 IR 运算能不能被降级成一条向量指令需要后端做复杂的模式匹配。而 llvmpipe 这个项目的重要工作正是落在“如何把图形渲染的计算转换成 LLVM IR 又转换成 CPU 向量指令”这件事上后端的质量直接决定了它在不在 CPU 上的表现。3. llvmpipe 是什么为什么它是 LLVM 项目中很不一般的存在聊到 llvmpipe很多人会一愣这不是 Mesa 3D 项目里的东西吗怎么和 LLVM 又扯上关系了实际上 llvmpipe 的全名是 LLVMpipe它是一个基于 LLVM 的 CPU 软件光栅化渲染器属于 Mesa 3D 图形库的一部分。这句话很短信息量很大。让我用大白话说清楚它到底干了件什么事一台电脑没有独立显卡、也没有任何厂商提供的硬件驱动甚至写一个最基础的 OpenGL 程序都会直接黑屏报错的时候llvmpipe 还能让这些图形程序正常跑起来。因为它不用 GPU纯靠 CPU 来执行所有的图形计算包括顶点变换、光栅化、片段着色、纹理采样、深度测试这些本该由 GPU 硬件完成的活儿。你可以在环境变量里显式启用它比如LIBGL_ALWAYS_SOFTWARE1 glxinfo | grep renderer string正常情况下你会看到类似这样的输出OpenGL renderer string: llvmpipe (LLVM 15.0.7, 256 bits)之前的渲染器也可能是某个显卡型号的字符串但一旦启用了软件渲染这一行就会换成 llvmpipe。这里的 “LLVM 15.0.7” 指的是 llvmpipe 在运行时调用的是 LLVM 15.0.7 版本的 JIT 编译能力“256 bits” 则说明它认为自己可以生成并执行 256 位宽度的 SIMD 向量指令。为什么要用 llvmpipe最常见的是三种场景。第一种是云服务器很多云主机没有 GPU 直通但业务方又需要一个 OpenGL 环境来做离线的渲染任务这时候软件渲染就是唯一出路。第二种是 CI/CD 测试自动化测试里不能保证每台机器都有 GPU你要验证某个 OpenGL 应用没有崩溃、没有内存错误就用 llvmpipe 兜底。第三种是驱动开发的 debug 利器当硬件驱动出问题、渲染结果不对时用软件渲染器做对比能迅速判断问题出在驱动还是应用。而 llvmpipe 之所以能工作得不错靠的就是 LLVM 的 JIT 能力。Mesa 的图形上层把 GLSL 着色器编译成 TGSI 或者 NIR 中间表示然后再转换成 LLVM IR最后交给 LLVM 的 JIT 去生成可以在当前 CPU 上运行的机器码。整套流程把图形渲染问题变成了“即时编译问题”而即时编译这个领域恰恰是 LLVM 最拿手的事情。3.1 llvmpipe 在 Mesa 中的定位Mesa 3D 是一个大型开源图形库集合它给自己的定位是各种图形 API 的开源实现。llvmpipe 在 Mesa 里是一个纯软件驱动和它并列的通常还有软渲染驱动。区别在于Mesa 里还留了一个古董级的 swrast 驱动它做渲染时是纯 C 代码逐像素算的性能表现极其有限基本上只适合用来验证功能正确性。llvmpipe 则把重活甩给 LLVM用 JIT 对每个着色器动态生成高度优化的机器码实际性能能比 swrast 快一个数量级甚至更高。这也决定了两个人驱动在 Mesa 里的角色不同swrast 是“保底”llvmpipe 是“生产力”。在一些无 GPU 环境里做离屏渲染、跑测试用例llvmpipe 是目前开源社区里质量和兼容性最好的软件渲染方案之一。llvmpipe 另外一个比较大的特点是很“讲究”。它虽然跑在 CPU 上但依然实现了完整的 OpenGL 管线包括三维裁剪、透视除法、纹理采样、混合、抗锯齿等。设计上它把绘图命令拆成了一个个小标题的 task再用线程池并行处理每个 tile所以多核 CPU 的性能优势它能吃得很透。有一段时间我用一个 8 核的机器跑离屏渲染测试llvmpipe 的帧数在同 CPU 上比旧软渲染驱动快了几倍核心各有明显占用这一点是真的让人佩服。3.2 LLVM 15.0.7 与 llvmpipe 的版本配合在我长期维护的一台无 GPU 测试服务器上系统里装的是 Mesa 自带的 llvmpipe对应的版本恰好就是带 LLVM 15.0.7 的版本。这个配合在 Ubuntu 等发行版里比较常见glxinfo 输出里能直接看到。它意味着 llvmpipe 的着色器 JIT 链路用的是 LLVM 15 的优化器和代码生成器。从实际体验上讲这一代组合在几年前的软渲染里属于非常能打的选手。它的优化管线能使不少 GLSL 着色器在 CPU 上跑出可接受的帧率尤其是几何复杂度不高、着色器比较重的场景优势更明显。换句话说如果图形程序的瓶颈在片段着色器上llvmpipe 的 JIT 可以把一份 GLSL 代码编译成针对当前 CPU 特性的向量指令然后在 256 位的 SIMD 流水线上并行执行多个像素的计算。llvmpipe 之所以愿意绑定 LLVM 的版本是因为它的接口一直在动态变化。每年 LLVM 新版本都可能调整 IR 语法或者 APIllvmpipe 的源码里就需要跟着做适配。所以看到 “LLVM 15.0.7” 这个版本号本质上是在告诉你这个 llvmpipe 是用 LLVM 15 系列的 API 编译出来、并且在运行时动态调用 LLVM 15.0.7 的库。3.3 256 位意味着什么从 SSE 到 AVX2 的跨度很多第一次接触 llvmpipe 的朋友会问这个 “256 bits” 到底是啥意思这里其实指的是 SIMD 向量宽度。SIMDSingle Instruction, Multiple Data单指令多数据是一种让 CPU 同一条指令同时处理多份数据的技术。你在写普通 C 代码时比如给两个数组做加法传统写法是一个循环一个元素地加但如果开了 SIMDCPU 可以一次性加载 4 个 32 位浮点数然后一条指令把它们全部加起来数据并列执行吞吐量直接翻好几倍。在这条路上x86 架构经历了几个阶段SSE 是 128 位一次处理 4 个 32 位浮点数AVX 把宽度扩展到了 256 位一次能处理 8 个 32 位浮点数AVX-512 则进一步延伸到 512 位一次能处理 16 个。llvmpipe 在 glxinfo 输出里写 “256 bits”意味着它在生成机器码时选择了 AVX 或者 AVX2 级别的 256 位向量指令来执行像素计算。也就是说如果 CPU 支持 AVX2那么你的 8 个像素颜色分量可能在一条指令里就被更新了。这一点非常关键因为在 CPU 上做图形渲染最大的瓶颈往往是每帧要计算的像素太多了而像素之.间的计算彼此独立恰好是 SIMD 最擅长处理的模式。我之前在自己的开发机上跑过一段 GLSL 片段着色器里面有一个很重的噪声函数控制台输出 llvmpipe 的渲染器字符串同样是 “LLVM 15.0.7, 256 bits”。后来把 CPU 换成支持 AVX-512 的型号glxinfo 输出会变成 “512 bits”实际渲染的帧数提升非常明显。这就说明 llvmpipe 并不是把图形代码编译成死板 CPU 指令就完事它是真的会看当前 CPU 支持什么向量指令集然后动态选择最优宽度去生成机器码。这也是 LLVM JIT 的一个经典优势编译时知道目标机器长什么样比通用的二进制分发版本能做更多针对性优化。4. 动手实践自己构建 LLVM 15.0.74.1 环境准备与版本选择想深入理解 LLVM光看文档是不够的最好是自己真正编译一遍。在开始编译前你要做两件事第一确认自己的系统环境第二想清楚自己为什么要构建 LLVM。如果你只是为了正常写 C/C 程序直接用系统包管理器装的 clang 就够了。如果你是为了学习 LLVM 的设计、想改点代码跑测试、或者想对比不同版本的优化效果那才需要自己构建。LLVM 15.0.7 是 15.0 系列的最后一个补丁版本整体稳定性比 15.0.0 好了不少。选择这个版本构建还有一个好处它的 CMake 配置相对成熟对系统环境的依赖不像新版那么苛刻踩坑概率会低一些。我自己在 Ubuntu 22.04 和 CentOS 7 上都编过这个版本过程都比较顺利。依赖方面构建 LLVM 本体需要这些基础工具cmake建议 3.20 以上、gcc 或 clang、python3、zlib 开发头文件。构建 Clang 和 lld 还需要 libxml2 开发头文件。如果你要跑测试还需要 lit、FileCheck 这些 LLVM 自带的测试工具。我用一条命令检查依赖是否齐全sudo apt-get install -y build-essential cmake ninja-build python3 zlib1g-dev libxml2-dev需要注意ninja 和 make 二选一即可。ninja 在并行编译时的并发控制更细腻增量编译速度也更快新手我建议直接用 ninja。4.2 CMake 配置的关键参数拿到源码和解压之后第一步是创建一个独立的构建目录。这一步非常重要强烈建议不要在源码目录里直接构建否则以后想清理构建产物会非常痛苦。我习惯的目录结构是这样tar -xf llvm-project-15.0.7.src.tar.xz mv llvm-project-15.0.7.src llvm-project mkdir llvm-project/build cd llvm-project/build然后在 build 目录里执行 cmake。这个命令最核心的几个参数值得说清楚cmake -G Ninja \ -DCMAKE_BUILD_TYPERelease \ -DLLVM_ENABLE_PROJECTSclang;lld \ -DLLVM_TARGETS_TO_BUILDX86 \ -DLLVM_ENABLE_ASSERTIONSON \ -DCMAKE_INSTALL_PREFIX~/llvm-15.0.7 \ ../llvmCMAKE_BUILD_TYPE 用 Release因为 Debug 版本的 LLVM 体积巨大、编译时间几乎是 Release 的几倍而且很多优化在你调试时会拖慢整体执行速度。只有在你是 LLVM 开发者、需要断点调试编译过程本身时才考虑 Debug。LLVM_ENABLE_PROJECTS 让你指定构建哪些子项目。默认只有 LLVM 核心库是不带 Clang 的。如果你想用自己构建的编译器就把 clang 加进去。lld 是 LLVM 自己的链接器构建的语言工具链如果想要完整的工具链体验可以一并加上。LLVM_TARGETS_TO_BUILD 用来控制后端目标。这里写 X86表示只需要生成 x86 的代码。这个参数能大幅缩短编译时间因为默认情况下 LLVM 会为几十个硬件平台生成后端代码只编译自己用的平台可以节省非常多的磁盘和 CPU 时间。LLVM_ENABLE_ASSERTIONS 建议打开。它会在编译好的 LLVM 库里启用大量运行时检查。对普通用户来说性能有点损失但对研究学习来说它可以帮你提前暴露很多“未定义行为”比如把空指针传给某个 API、用了非法的 IR 等。很多诡异 bug 在断言开启时会直接报出处省去大量排查时间。4.3 构建与安装过程CMake 配置完成后直接运行ninja -j8-j 的数值最好设为核心数加一左右太大会导致内存不够太小又很慢。我编 LLVM 15 时用 8 核大概跑了二十多分钟中间没有报错。如果你严守“只构建 X86 后端”这个参数时间还会更短如果默认构建所有目标那没个半小时以上跑不完。第一次构建 LLVM 时你一定要对硬件资源有点心理准备。它的 C 模板和宏展开会生成大量中间代码编译器和链接器都需要吃非常多的内存。网上说最少 4GB 内存能编译但我实际试过4GB 情况下链接 libLLVM.so 时随时可能被 OOM 杀掉。我的建议是至少 8GB 内存16GB 才比较舒适。如果内存不够可以少开几个并行任务ninja -j2 也是一种选择只是时间会拉长很多。构建完成后安装ninja install安装目录默认在 CMAKE_INSTALL_PREFIX 指定的路径也就是我上面写的 ~/llvm-15.0.7。安装完成之后验证一下~/llvm-15.0.7/bin/clang --version正常会显示类似clang version 15.0.7 Target: x86_64-unknown-linux-gnu Thread model: posix到这一步一套完全属于你自己的 LLVM 15.0.7 工具链就已经具备基本形态了。你可以用它来编译 C 程序也可以用它结合后文里的 opt 工具去手动观察优化效果。4.4 验证 llvmpipe 的 JIT 链路是否正常既然文章主题跟 llvmpipe 关系密切那么构建完 LLVM 后可以顺手验证一下自己的 LLVM 版本是否会被系统里的 Mesa 检测到。Mesa 在运行时动态加载 libLLVM.so然后把版本号和位宽信息填到渲染器字符串里。你可以用 ldconfig 或者直接看 Mesa 链接了哪个 LLVM 库ldd /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so | grep llvm如果你构建完安装了新的 LLVM想让 Mesa 优先使用你构建的版本可以设置 LD_LIBRARY_PATHLD_LIBRARY_PATH~/llvm-15.0.7/lib LIBGL_ALWAYS_SOFTWARE1 glxinfo | grep renderer如果一切正常渲染器字符串应该明确包含 LLVM 15.0.7 字样。这一步不会影响系统其他软件运行只是一个临时环境变量作用在单条命令上所以可以放心试验。它也能帮你确认一件事llvmpipe 的 JIT 是“运行时”调 LLVM 库的只要你提供兼容的 LLVM 15 版本它就能工作。5. 构建过程中常见问题与排查技巧编译 LLVM 的过程基本都会碰到几个典型问题。我把自己和一些同事踩过的坑整理了一下按出现频率从高到低列在下面。5.1 编译时间太长、内存爆炸这是新手最常遇到的问题。第一次构建 LLVM什么参数都不改直接 cmake 然后 make -j8结果编译到一半内存不够机器直接卡死或者某个编译进程被 OOM killer 杀掉。看到这类错误时第一反应不是去改源码而是先看清楚自己的内存容量。解决办法有两个方向。第一个是把并行度降下来比如 ninja -j2让同时运行的编译任务少一些峰值内存自然就下来了。第二个是缩减构建范围一定记得尽早在 CMake 配置里写 LLVM_TARGETS_TO_BUILDX86。此外还有个隐藏很深的问题链接 libLLVM.so 的时候链接器本身会吃大量内存当内存不够时链接阶段会失败提示 ld 进程被 killed。这时候无论你怎么降并行度都没用因为链接阶段是单任务的。最好的办法是考虑用 lld 来链接 LLVM碰巧 lld 本身也在 LLVM 项目里。你可以预先在一个系统里装上 lld然后在 build 目录里重新配置 CMake 加一个 -DLLVM_USE_LINKERlld。lld 的链接速度比 GNU ld 快很多内存占用也更稳我用它之后基本再没遇到过链接阶段被 OOM 的情况。5.2 测试失败与 lit 工具使用构建成功之后跑测试是很多入门者忽略的一步。LLVM 的测试框架叫 lit测试用例里有一堆 .ll 文件和 RUN 指令。跑测试的正确姿势是ninja check-llvm这个命令会运行 LLVM 核心所有测试。如果你构建的是 Release 版本测试一般都会通过但如果某条测试挂掉了先别急看测试日志是关键。lit 的输出非常详细会明确告诉你哪个测试文件、哪条 RUN 命令失败了以及预期输出和实际输出之间的 diff。我在实际使用中遇到过一类特别有意思的问题测试失败不是代码有 bug而是机器特性不同导致的。比如某些测试依赖 CPU 支持 AVX2 指令集如果机器不支持JIT 生成的代码和预期有差异测试就会挂。这类测试通常会有 SKIP 或者 XFAIL 标记你不用太较真。如果你是在 CI 环境里跑全量测试建议先查一下这台机器是否满足测试的硬件前提。如果你想单独跑某一个测试文件可以这样~/llvm-15.0.7/bin/llvm-lit -v ../llvm/test/Transforms/InstCombine/add.ll-v 会打印详细信息方便你看到 RUN 命令到底执行了什么。5.3 常见错误与解决方案速查为了查阅方便我把自己多年间在不同机器上踩过的错误归成了下面这张表每一行都是实际遇到过、并且验证过修复方案的问题。错误现象根本原因解决方案configure: error: ‘std::is_trivially_copyable’ has not been declared编译器版本过旧不支持 C17 新库特性把 GCC 升到 8 以上更稳妥的是用 GCC 10 以上ld: final link failed: No space left on device磁盘空间不足Debug 版本尤其容易触发换到更大的分区构建或者清空旧 build 目录fatal error: ‘zlib.h’ file not found缺少 zlib 开发头文件Ubuntu 下安装 zlib1g-devCentOS 下安装 zlib-develundefined reference to ‘LLVMInitializeX86TargetInfo’后端目标未包含或链接顺序问题确认 LLVM_TARGETS_TO_BUILD 包含 X86且链接时使用 llvm-config --libs 保证顺序assert failed: Reason: Should not reach here某个 Pass 遇到无法处理的 IR 形态升级到 15.0.7 最新补丁版本或检查前端的实际 IR 是否符合规范glxinfo 显示 llvmpipe 但版本不是 15.0.7Mesa 链接的系统 LLVM 不是你构建的版本检查 ldd 输出必要时用 LD_LIBRARY_PATH 显式指向自建库编译过程中 out of memory并行编译任务过多或链接内存不足降低 -j尝试 LLVM_USE_LINKERlld这张表其实说明了一件事大多数构建失败都不是 LLVM 本身的代码问题而是环境问题。只要把系统工具链、磁盘空间、内存、依赖库这四件事处理好构建本身非常顺畅。5.4 不要忽略 CMake 缓存还有一个常见但很难察觉的问题是你修改了 CMake 参数但编译出来的东西却没变化。原因是 CMake 把配置结果缓存在了 build 目录里的 CMakeCache.txt 中很多改动需要先清理缓存才能生效。我每次调 CMake 配置时都会在确认参数后执行一次rm -rf CMakeCache.txt CMakeFiles然后再重新跑 cmake。如果你只是改编译选项不清理的话新配置可能确实会起作用但如果你改了 LLVM_ENABLE_PROJECTS 这类的顶层开关比如从 clang;lld 改成 clang;lld;mlir不清理缓存几乎一定出问题。最省事的做法永远是新建一个 build 目录名字起得像 build-clang、build-full 这样的不同配置互不干扰这才是编译大型 C 项目的正确姿势。6. 对 LLVM 15.0.7 的深度体验与实践技巧6.1 用 opt 手动跑优化 pass自己构建完 LLVM 之后最大的乐趣是可以用 opt 这个工具去手动观察 IR 的变换。它就像一个“单兵显微镜”可以让你逐条地看优化器对 IR 做了什么。我们先写一个非常简单的 C 文件int foo(int a, int b, int c) { int x a b; int y x * c; int z y - a; return z; }用 clang 把它编译成 IRclang -O0 -S -emit-llvm foo.c -o foo.ll打开 foo.ll你会发现这里面每一步都被完整地记录了下来加法存在一个临时变量里乘法又存在另一个临时变量里最后减法得到返回值。整个过程一板一眼一个优化 Pass 都没有跑。然后我们对它跑一遍简单的优化opt -S -passesinstcombine foo.ll -o foo.opt.ll再打开 foo.opt.ll你会看到指令组合优化把多条 IR 指令合并成了一条或更少条很可能已经把 x 和 y 这种中间变量直接化简掉整个函数体变成了一个简单的算术表达式。这种“看得到”的优化过程比任何讲述编译原理的文字都更容易让人理解编译器到底在给你做什么。如果你愿意再进一步可以用 opt 配合 -print-after-all 查看每一个 Pass 对 IR 做了什么opt -S -passesinstcombine,gvn -print-after-all foo.ll -o /dev/null这会输出大量中间 IR 快照像放电影一样展示每一步优化前后。第一次看这个输出可能会因为信息量太大而晕头转向但坚持看几次之后你会对 LLVM 整个优化体系产生非常直观的认知。6.2 验证 256 位向量代码生成我曾经在一篇技术笔记里记录过如何用 llvmpipe 和 LLVM 15.0.7 验证 256 位向量代码生成的过程。这其实是验证 LLVM 后端能力的一个特别直观的方式。首先确认 CPU 支持 AVX2grep -o avx2 /proc/cpuinfo | head -1如果有输出就说明 CPU 支持。然后用一个简单的 C 程序让 clang 在编译时针对 AVX2 生成向量化代码void add_arrays(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 add.c -o add.s grep -E vaddps|vaddpd|ymm add.s如果有 vaddps把 8 个 32 位浮点数一次性相加或者 ymm 寄存器的出现就说明 LLVM 正在使用 256 位向量指令。把这些指令和以前 128 位的 SSE 版本对比你就会理解为什么 LLVM 15 时代用 256 位 SIMD 能在 CPU 图形渲染上带来越级性能提升。再打开 llvmpipe 的渲染器信息LIBGL_ALWAYS_SOFTWARE1 glxinfo | grep LLVM 15.0.7看到 “256 bits” 的时候你就明白其实 llvmpipe 干的活儿和你刚才 C 程序里做的一样把适合并行的数据打包到向量指令里只不过它是通过 JIT 在运行时做这件事比你在写代码里手动加 -mavx2 再编译要动态得多。6.3 我的一点个人建议真要说玩 LLVM 这么多年最大的体会就是不要害怕读源码。很多人一看 LLVM 仓库里几百万行代码就劝退了但你没必要从第一行看到最后一行。挑一个最感兴趣的模块比如某个优化 Pass、或者某个后端的指令选择文件啃透核心逻辑比泛泛地浏览所有目录有用得多。LLVM 社区里其实隐藏着一套非常好的“从问题到答案”的学习路径GitHub 上的 issue、Phabricator 上的 patch review、以及每年 LLVM Developers’ Meeting 的演讲视频。我经常用到的技巧是直接去搜某个 Pass 在某个版本里的 commit 记录看它的作者是怎么写 commit message、怎么组织 diff 的这比看教科书更能理解一个特性从想法到落地的全过程。另外如果你真的想在 LLVM 上做长期开发建议从一开始就养成配置好调试环境的习惯。构建一份 DebugAssertions 的 LLVM再配合 LLDB 去单步调试远比“编译器报错我再猜”要高效。很多编译器内部的问题只有看到 IR 和优化过程的真实状态才能定位。我自己的经验是LLVM 不是一本可以一口气读完的书它是一个可以反复走进走出的生态系统。每次重新构建一个版本每次用 opt 手动跑一个优化每次看到 llvmpipe 熬出一帧画面都是在和这个庞大的工具链建立更深的连接。这些经验没法靠纯粹看文档获得一定要自己动手折腾几轮才能沉淀下来。希望这篇从项目本身聊到具体构建、再到实际验证的文章能帮你在 LLVM 的世界里少走一点弯路也让你在下次看到 “llvmpipe (LLVM 15.0.7, 256 bits)” 这行字的时候心里清楚它背后到底是怎样一场编译艺术的演出。