深入理解LLVM与llvmpipe：从IR到256位SIMD的编译艺术

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 IR（Intermediate 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 * 2，Clang 会把它变成类似下面的 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_SOFTWARE=1 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 语法或者 API，llvmpipe 的源码里就需要跟着做适配。所以看到 “LLVM 15.0.7” 这个版本号，本质上是在告诉你：这个 llvmpipe 是用 LLVM 15 系列的 API 编译出来、并且在运行时动态调用 LLVM 15.0.7 的库。

3.3 256 位意味着什么：从 SSE 到 AVX2 的跨度

很多第一次接触 llvmpipe 的朋友会问：这个 “256 bits” 到底是啥意思？这里其实指的是 SIMD 向量宽度。SIMD（Single Instruction, Multiple Data，单指令多数据）是一种让 CPU 同一条指令同时处理多份数据的技术。你在写普通 C 代码时，比如给两个数组做加法，传统写法是一个循环一个元素地加；但如果开了 SIMD，CPU 可以一次性加载 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.7

4.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_TYPE=Release \ -DLLVM_ENABLE_PROJECTS="clang;lld" \ -DLLVM_TARGETS_TO_BUILD="X86" \ -DLLVM_ENABLE_ASSERTIONS=ON \ -DCMAKE_INSTALL_PREFIX=~/llvm-15.0.7 \ ../llvm

CMAKE_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_PATH：

LD_LIBRARY_PATH=~/llvm-15.0.7/lib LIBGL_ALWAYS_SOFTWARE=1 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_BUILD="X86"。

此外还有个隐藏很深的问题：链接 libLLVM.so 的时候，链接器本身会吃大量内存，当内存不够时链接阶段会失败，提示 ld 进程被 killed。这时候无论你怎么降并行度都没用，因为链接阶段是单任务的。最好的办法是考虑用 lld 来链接 LLVM，碰巧 lld 本身也在 LLVM 项目里。你可以预先在一个系统里装上 lld，然后在 build 目录里重新配置 CMake 加一个 -DLLVM_USE_LINKER=lld。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 常见错误与解决方案速查

为了查阅方便，我把自己多年间在不同机器上踩过的错误归成了下面这张表，每一行都是实际遇到过、并且验证过修复方案的问题。

这张表其实说明了一件事：大多数构建失败都不是 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 把它编译成 IR：

clang -O0 -S -emit-llvm foo.c -o foo.ll

打开 foo.ll，你会发现这里面每一步都被完整地记录了下来：加法存在一个临时变量里，乘法又存在另一个临时变量里，最后减法得到返回值。整个过程一板一眼，一个优化 Pass 都没有跑。

然后我们对它跑一遍简单的优化：

opt -S -passes=instcombine foo.ll -o foo.opt.ll

再打开 foo.opt.ll，你会看到指令组合优化把多条 IR 指令合并成了一条或更少条，很可能已经把 x 和 y 这种中间变量直接化简掉，整个函数体变成了一个简单的算术表达式。这种“看得到”的优化过程，比任何讲述编译原理的文字都更容易让人理解编译器到底在给你做什么。

如果你愿意再进一步，可以用 opt 配合 -print-after-all 查看每一个 Pass 对 IR 做了什么：

opt -S -passes=instcombine,gvn -print-after-all foo.ll -o /dev/null

这会输出大量中间 IR 快照，像放电影一样展示每一步优化前后。第一次看这个输出可能会因为信息量太大而晕头转向，但坚持看几次之后，你会对 LLVM 整个优化体系产生非常直观的认知。

6.2 验证 256 位向量代码生成

我曾经在一篇技术笔记里记录过如何用 llvmpipe 和 LLVM 15.0.7 验证 256 位向量代码生成的过程。这其实是验证 LLVM 后端能力的一个特别直观的方式。

首先确认 CPU 支持 AVX2：

grep -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_SOFTWARE=1 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 上做长期开发，建议从一开始就养成配置好调试环境的习惯。构建一份 Debug+Assertions 的 LLVM，再配合 LLDB 去单步调试，远比“编译器报错我再猜”要高效。很多编译器内部的问题，只有看到 IR 和优化过程的真实状态才能定位。

我自己的经验是：LLVM 不是一本可以一口气读完的书，它是一个可以反复走进走出的生态系统。每次重新构建一个版本，每次用 opt 手动跑一个优化，每次看到 llvmpipe 熬出一帧画面，都是在和这个庞大的工具链建立更深的连接。这些经验没法靠纯粹看文档获得，一定要自己动手折腾几轮才能沉淀下来。希望这篇从项目本身聊到具体构建、再到实际验证的文章，能帮你在 LLVM 的世界里少走一点弯路，也让你在下次看到 “llvmpipe (LLVM 15.0.7, 256 bits)” 这行字的时候，心里清楚它背后到底是怎样一场编译艺术的演出。