去年我花了整整一个周末把 llvm-project 从源码完整编译了一遍。中间失败三次磁盘差点被塞爆但最终跑通 Clang 的那一刻我对“编译器”这三个字的理解直接被刷新了。这篇文章不打算讲太深的理论我就是想以第一视角聊聊这个仓库里到底有什么、为什么值得你花时间研究以及我踩过的那些坑。llvm-project 是如今几乎所有现代编程语言都绕不开的编译器基础设施。你可能没直接编译过它但你用过的 Rust、Swift、Kotlin/Native、Zig以及 Clang 本身底层统统翻译到 LLVM 的中间表示上。理解它等于看懂了这些语言的“共同底层”。如果你将来想写自定义优化、做静态分析或者只是想知道自己写的 C 在编译时到底经历了什么那这个项目就是最好的研究对象。在开始之前我说一下这篇文章适合谁看你不需要系统学过编译原理只要会写一点 C/C对命令行操作不陌生就能跟下来。代码和命令我会放出来你照着执行就行。1. llvm-project 到底是什么为什么值得花时间研究1.1 从一个最朴素的编译问题说起我经常会收到这样的问题编译器到底做了什么事为什么同一个 C 文件换一个-O2标志性能就差那么多传统的编译器比如 GCC会经过四个阶段预处理、编译、汇编、链接。预处理处理#include和宏然后把 C 代码翻译成汇编汇编器再转成机器码最后链接器把所有目标文件和库合并成可执行文件。这个流程本身没什么神秘但它有一个尴尬的约束前端和后端是绑死的。也就是说GCC 要支持一门新语言或者要支持一种新 CPU 架构都得在同一个代码库里面大改。LLVM 的思路就聪明在这里。它把编译器拆成了三段前端把源码翻译成一种统一的中间表示叫 LLVM IR。中端对 IR 做各种优化。后端把优化后的 IR 翻译成目标机器的汇编或机器码。这个架构有点像手机充电器。前端是各种插头后端是电源适配器IR 就是那个 USB-C 口。你只要让它输出这个统一接口后面随便接什么“协议”都行。新语言只需要写前端新 CPU 只需要写后端中间的千万行优化逻辑一次都不用动。1.2 不只是一个编译器而是一整套工具链生态很多人以为 LLVM 只是 Clang 背后的引擎其实 llvm-project 这个仓库里面装了一整套工具链。光说几个你们大概率用过的Clang 是 C/C/Objective-C 的前端现在 macOS 和很多 Android NDK 默认编译器都是它。lld 是链接器它的速度比传统 GNU ld 快好几倍我自己的大型 C 项目切换过去之后链接时间肉眼可见地缩短。lldb 是调试器跟 LLVM IR 结合得很紧密。libc 是 C 标准库实现macOS 上 Clang 默认用的就是它。compiler-rt 提供了一些底层运行时支持比如 sanitizersASan、UBSanC 开发者应该很熟悉。还有衍生项目 MLIR、Polly、Flang。尤其 MLIR 这两年特别火在 AI 芯片编译器领域出场率极高。你在面试芯片公司时大概率会被问到这个。1.3 什么人适合啃这个仓库我不建议所有人一上来就去读源码。但如果下面任意一条戳中你这个项目值得你深入你在做性能优化想让 C 生成更快的汇编得知道编译器优化 pass 的顺序。你所在团队在做静态分析或者代码扫描Clang 有一堆现成的检查器。你想学一门新语言怎么落地比如自己实现一个小型方言然后翻译到 LLVM IR 再生成机器码。你想理解 WebAssembly 或者 GPU 编译器的原理LLVM 都把后端抽象好了。我自己以前总觉得“编译器离我很远”直到被一个问题逼到去读 optimization pipeline 的源码才意识到现代语言工程有多依赖这套基础设施。2. 源码结构拆解先把这个仓库的地图记熟2.1 顶层目录都放了些啥克隆下来的llvm-project目录很大第一次进去会有点懵。我建议你先忽略那些名字古怪的子目录先看几个核心的就够了目录作用llvm/核心库和基础工具包括 IR、优化 pass、目标后端、opt/llc 等clang/C/C 编译器前端还包括静态分析器和重构工具lld/可执行文件链接器lldb/调试器libcxx/和libcxxabi/C 标准库和 ABI 兼容层compiler-rt/sanitizers、profile 运行时等底层库polly/面向循环优化的多面体模型框架mlir/面向机器学习编译器的中间表示框架flang/Fortran 前端bolt/二进制优化工具偏向性能分析场景我自己第一次看到这么多目录也有点发怵但实际操作中我们绝大多数时间只会碰llvm/和clang/。很多子项目是可以完全关掉的这我后面会讲。2.2 核心库 llvm/ 的正确打开方式如果你想读源码llvm/底下有几个目录最重要llvm/include/llvm/IR/IR 的定义就在这里比如Instruction、BasicBlock、Function这些核心类。llvm/lib/Transforms/各种优化 pass比如InstCombine、GVN、LoopVectorize。llvm/lib/Target/各 CPU 架构的后端实现X86、AArch64、RISCV 等。llvm/tools/平时用的命令行工具opt、llvm-as、llvm-dis、llc都在这。读源码不要从头按顺序读我建议从opt这个工具入手。因为它最直观我拿到一份 IR跑某个 pass看到 IR 变化整个过程像实验一样。这样你理解 pass 是怎么注册、怎么调度、怎么改 IR 的效率比直接躺在Instruction类的实现里高得多。2.3 clang/ 前端又拆成了几层Clang 目录的核心在clang/lib。它会先把 C/C 源码解析成 AST然后做语义分析最后通过 CodeGen 模块把 AST 翻译成 LLVM IR。这几个子目录值得关注clang/lib/ASTAST 节点定义你写一个clang -ast-dump命令能看到源码被拆成的语法树。clang/lib/Sema语义分析负责捕捉“类型不匹配”“未定义变量”这类错误。clang/lib/CodeGen把 AST 生成 IR 的地方这里最接近 LLVM 核心。clang/lib/Driver驱动层负责解析命令行参数、选择工具链、调用各种子工具。如果你对 clang-tidy 那种静态检查感兴趣可以看clang-tools-extra/下的 check 实现它提供了非常完整的回调接口方便你去写自定义检查规则。2.4 想少花点时间怎么只编译一部分很多人一上来直接全量构建结果不是内存爆了就是磁盘不够。实际用不到那么多子项目。在 CMake 配置阶段可以通过-DLLVM_ENABLE_PROJECTSclang;lld只选择要构建的项目。你不需要lldb就把lldb从分号列表里去掉不需要polly也不要加进去。这样能省掉大量编译时间。别问我是怎么知道的问就是我第一次把lldb也编进去了在“即将完成”的阶段卡了整整 30 分钟。3. 动手构建从源码跑通一个可用的 Clang3.1 准备工作与依赖安装构建 LLVM 需要这几个前提条件一台内存至少 8GB 的机器推荐 16GB。内存不够时 Ninja 可能直接 OOM或者编译进程被杀掉。磁盘至少剩余 50GB。Release 构建加 Clang 全套大概需要 20-30GB但保险起见留足。系统装了 Git、CMake、Ninja。有可用的 C/C 编译器。Linux 上可以用 GCCmacOS 上可以用自带 Clang。我自己用的是 Ubuntu 22.04先确认工具链sudo apt update sudo apt install build-essential cmake ninja-build python3 git确认版本cmake --version ninja --version gcc --versionLLVM 对 CMake 版本有要求太旧会直接报错。如果你用的发行版提供的 CMake 太老建议装较新的版本。3.2 用 CMake 配置构建参数逐个说明构建配置是这一步的重点。我用的是这个命令git clone https://github.com/llvm/llvm-project.git cd llvm-project cmake -S llvm -B build -G Ninja \ -DCMAKE_BUILD_TYPERelease \ -DLLVM_ENABLE_PROJECTSclang;lld \ -DLLVM_TARGETS_TO_BUILDX86 \ -DLLVM_ENABLE_ASSERTIONSON-S llvm指定源码目录是llvm/注意不是根目录因为 CMakeLists.txt 在llvm/下。-B build指定输出目录。-G Ninja用 Ninja 作为构建系统。Ninja 比 Make 快而且默认支持并行。除非你对 Make 有执念否则我强烈建议 Ninja。-DCMAKE_BUILD_TYPERelease释放模式。Debug 编译出的clang有完整调试符号但构建时间可能是 Release 的三倍以上体积也大得多。没有调试需求的话Release 是最合适的选择。-DLLVM_ENABLE_PROJECTSclang;lld只构建 Clang 和 lld。分号在 shell 里要加引号否则会被解释成命令分隔符。-DLLVM_TARGETS_TO_BUILDX86只生成 X86 后端。如果你在 ARM 机器上实验改成 AArch64 能省不少时间。全量生成所有 Target 也可以但没必要。-DLLVM_ENABLE_ASSERTIONSON开启断言。建议开着虽然会稍微影响性能但你做二次开发时断言真的能救你命——跑 pass 时如果 IR 不合法断言会先报警而不是让你面对一段玄学崩溃。3.3 构建过程实测进度、耗时与硬件门槛配置完成后直接ninja -C build clang lld只构建clang和lld这两个 target别直接跑裸ninja否则会把所有可选工具全部编一遍。我这台机器是 8 核 16 线程 CPU、16GB 内存Release 模式下构建 clang lld 用了大概 35 到 40 分钟。如果是 4 核大概要两小时起步你需要做好心理准备。构建过程中可以看看任务管理器Ninja 默认并行数等于 CPU 线程数。如果发现内存占用接近物理内存上限可以减少并行度ninja -C build -j 8 clang lld-j参数可以控制并发数。1GB 内存对应 1 个线程这个粗略公式我这几年用下来还算靠谱。构建完成后产物在build/bin/下。验证一下build/bin/clang --version能看到类似这样的输出clang version 18.0.0 (https://github.com/llvm/llvm-project.git ...) Target: x86_64-unknown-linux-gnu Thread model: posix3.4 验证产物写个小 C 程序让新编译链跑起来我通常写一个简单的斐波那契函数验证工具链#include stdio.h int fib(int n) { if (n 2) return n; return fib(n - 1) fib(n - 2); } int main(void) { printf(%d\n, fib(10)); return 0; }编译并运行build/bin/clang -O2 fib.c -o fib ./fib能正确输出55这套工具链就跑通了。接下来才是我最爱的部分——看看优化器到底对代码做了什么。4. 核心体验用工具链看懂优化器在做什么4.1 用 Clang 编译一个小函数对比不同优化级别为了直观感受优化器的工作我写了一个非常简单的函数int add_one(int x) { return x 1; }先以-O0编译生成汇编build/bin/clang -O0 -S add_one.c生成的汇编很长因为-O0把每个变量都放在内存里执行了很多冗余的加载和存储。其中核心片段大概是pushq %rbp movq %rsp, %rbp movl %edi, -4(%rbp) movl -4(%rbp), %eax addl $1, %eax popq %rbp retq这个版本把参数先存到栈上再读回来做加法。你可以看到大量堆栈操作。再以-O2编译build/bin/clang -O2 -S add_one.c优化后的汇编就干净多了leal 1(%rdi), %eax retq一条leal指令就完成了加一操作参数直接放在寄存器里根本没有访问内存。同一个 C 函数两级优化汇编差出四倍指令量。这就是编译器优化价值最直观的体现。4.2 IR 长什么样随手拆出一份来看看汇编能让你看到结果但优化器操作的对象不是汇编而是 IR。用下面的命令可以拿到一个函数的 LLVM IRbuild/bin/clang -O0 -S -emit-llvm add_one.c生成的文件里长这样define dso_local i32 add_one(i32 noundef %x) #0 { entry: %x.addr alloca i32, align 4 store i32 %x, ptr %x.addr, align 4 %0 load i32, ptr %x.addr, align 4 %add add nsw i32 %0, 1 ret i32 %add }读这种代码有个技巧先找define这是函数的入口再找基本块也就是entry:这种标签然后从上往下看所有%开头的变量它们是不可变的 SSA 值。能看到-O0下 IR 也在做 alloca 和 store/load非常啰嗦。这时候可以尝试用opt工具手动跑一个优化build/bin/opt -passesmem2reg add_one.ll -S -o add_one_opt.llmem2reg是一个把内存变量提升为寄存器变量的基础优化 pass。跑完之后再看文件alloca 和 load/store 基本消失了整个函数干净得像直接写出来的高级代码define dso_local i32 add_one(i32 noundef %x) #0 { %1 add nsw i32 %x, 1 ret i32 %1 }这时候你才真正明白优化器是拿 IR 在干什么事情。它不是靠魔法把性能变好而是把可读的高级语言代码逐步降级成更接近硬件的、更少冗余的计算过程。4.3 从 IR 到汇编llc 和指令选择IR 优化完最终还要翻译成目标机器的汇编这个活由后端完成。llc就是一个把 IR 转成汇编的工具。上手很简单build/bin/llc add_one_opt.ll -o add_one.s你可以在生成的汇编里看到熟悉的leal、retq。后端做的工作很复杂包括指令选择、寄存器分配、指令调度但命令行用起来就是这么简单。对于新手我的建议是先用clang -S和opt -passes这两个工具理解前端和中端后端那些细节可以放到以后再说。4.4 顺手试一下 Clang 自带的优化报告除了看 IRClang 还提供了一个特别适合性能分析的功能优化报告。给编译加一个标志build/bin/clang -O3 -Rpassloop-vectorize -Rpass-missedloop-vectorize -c matmul.c如果代码里的循环被向量化了你会看到 Clang 输出类似这样的信息matmul.c:12:3: remark: vectorized loop (vectorization width: 4, interleaved count: 2)这比反复看汇编猜优化器在想什么高效太多了。我经常用-Rpass系列来和编译器“对话”它在哪做了优化、在哪放弃优化、为什么放弃都有明确提示。5. 新手最容易踩的坑与排查实录5.1 构建慢到怀疑人生这个问题我见得太多了不只是新手连我这种老油条都经历过。症状是卡在某个文件上半天不动那是 CPU 单线程瓶颈。排查思路先确认你已经指定-G Ninja并且没有手动限制-j太低。再检查LLVM_ENABLE_PROJECTS少开几个项目会快非常多。如果还慢可以用ccache。配置编译时使用 ccache 后后续增量编译速度快到起飞。我第一次没装第二次装了之后直接被惊到。在 CMake 配置时加一行-DLLVM_CCACHE_BUILDON前提是你系统装了 ccache。几十行代码改动之后它们只需要几十秒而不是全量重编。5.2 编译过程中磁盘爆了LLVM 构建非常吃磁盘。Release Clang 通常要 20 到 30GBDebug 模式会翻倍。如果你在/分区构建极有可能把系统盘塞满。排查思路先看df -h确认剩余空间。如果不够把 build 目录放到空间更大的磁盘。用完之后直接删 build 目录就行不会污染系统。我也习惯把 build 目录放在独立分区这样万一系统盘空间紧张不会波及开发环境。另外当配置参数大改时建议删掉 build 目录重新来一遍而不是反复改 CMake 配置。保留旧缓存有时会导致一些二义性问题表现为莫名其妙的链接失败。5.3 CMake 和 GCC 版本太老LLVM 主分支对 CMake 和编译器版本要求很严格。我遇到过最典型的报错是CMake Error: Unsupported version of CMake这种问题没有捷径只能升级工具链。Ubuntu 上可以用 apt也可以通过 pip 装新版本 CMake。GCC 版本过老时LLVM 代码里用的新 C 标准会编译不过错误信息会指向某个奇怪的模板。不用怀疑人生大概率就是编译器版本太旧。5.4 Clang 编译程序时找不到标准库头文件自己编译的 Clang 默认会去系统里找标准库头文件但如果你用的是 libc 而不是系统的 libstdc可能碰到fatal error: vector file not found这种情况通常是因为 Clang 和 C 标准库的配合没配好。最简单的解决办法是不指定 libc让它用系统默认的 libstdc。如果你确实需要 libc那得先把libcxx和libcxxabi构建出来再用-stdliblibc显式指定。这个路径对新手有点绕我建议暂时先不用。5.5 打开断言后跑测试突然异常退出如果你后来自己改了 pass并且在LLVM_ENABLE_ASSERTIONSON模式下跑测试会遇到很多“断言失败”。这不算 bug恰恰说明你的代码有某一处违反 IR 约束。排查思路先看断言信息指向哪个文件、哪个函数大部分问题集中在 IR 类型不匹配、基本块缺少终结指令等。再用opt -verify对 IR 做验证它能告诉你 IR 哪里不合法。实在找不到就二分法先跑一个最小的测试用例逐步加代码把问题缩小到某一个 pass。这是调试 LLVM 开发的日常节奏习惯就好。6. 从“能用”到“会玩”三个工程经验分享6.1 不要迷信默认参数配置参数对应具体场景很多 LLVM 教程默认全量构建这其实就是我一开始犯的错。如果你只是做 C/C 日常编译LLVM_ENABLE_PROJECTSclang就足够了。做链接优化再考虑加lld做调试再考虑lldb做 MLIR 实验再加mlir。项目是按需拆分的没必要为不需要的组件买单。6.2 Debug 和 Release 的区别比你想象中大Debug 编译出的clang性能会差很多但如果你在改 LLVM 源码、调试 pass那 Debug 版本能提供更完整的符号和更清晰的断言。我现在的习惯是保留两个 build 目录一个 Release 日常编译用一个 Debug 做开发调试用。两个目录并存也就二十几GB但省心不少。6.3 放心大胆地改源码llvm-project 最大的魅力在于它是开源且模块化到极致的编译器。你不需要懂全部代码就能改一点东西并看到效果。你可以在某个 optimization pass 里加一行打印也能新增一个简单的自定义 pass通过opt加载进去运行。这个过程非常像做实验改一行跑一下看 IR 变化立刻得到反馈。成为 LLVM contributor 没有那么高不可攀很多新人就是从修注释和文档开始的。如果你也在研究这个项目我的建议是不要被仓库规模和术语吓倒先动手构建一个能用版本再拿手头代码看 IR从最小的函数开始理解优化器。这比我当年对着文档啃两个月再动手的效率高十倍。
去年我花了整整一个周末把 llvm-project 从源码完整编译了一遍。中间失败三次磁盘差点被塞爆但最终跑通 Clang 的那一刻我对“编译器”这三个字的理解直接被刷新了。这篇文章不打算讲太深的理论我就是想以第一视角聊聊这个仓库里到底有什么、为什么值得你花时间研究以及我踩过的那些坑。llvm-project 是如今几乎所有现代编程语言都绕不开的编译器基础设施。你可能没直接编译过它但你用过的 Rust、Swift、Kotlin/Native、Zig以及 Clang 本身底层统统翻译到 LLVM 的中间表示上。理解它等于看懂了这些语言的“共同底层”。如果你将来想写自定义优化、做静态分析或者只是想知道自己写的 C 在编译时到底经历了什么那这个项目就是最好的研究对象。在开始之前我说一下这篇文章适合谁看你不需要系统学过编译原理只要会写一点 C/C对命令行操作不陌生就能跟下来。代码和命令我会放出来你照着执行就行。1. llvm-project 到底是什么为什么值得花时间研究1.1 从一个最朴素的编译问题说起我经常会收到这样的问题编译器到底做了什么事为什么同一个 C 文件换一个-O2标志性能就差那么多传统的编译器比如 GCC会经过四个阶段预处理、编译、汇编、链接。预处理处理#include和宏然后把 C 代码翻译成汇编汇编器再转成机器码最后链接器把所有目标文件和库合并成可执行文件。这个流程本身没什么神秘但它有一个尴尬的约束前端和后端是绑死的。也就是说GCC 要支持一门新语言或者要支持一种新 CPU 架构都得在同一个代码库里面大改。LLVM 的思路就聪明在这里。它把编译器拆成了三段前端把源码翻译成一种统一的中间表示叫 LLVM IR。中端对 IR 做各种优化。后端把优化后的 IR 翻译成目标机器的汇编或机器码。这个架构有点像手机充电器。前端是各种插头后端是电源适配器IR 就是那个 USB-C 口。你只要让它输出这个统一接口后面随便接什么“协议”都行。新语言只需要写前端新 CPU 只需要写后端中间的千万行优化逻辑一次都不用动。1.2 不只是一个编译器而是一整套工具链生态很多人以为 LLVM 只是 Clang 背后的引擎其实 llvm-project 这个仓库里面装了一整套工具链。光说几个你们大概率用过的Clang 是 C/C/Objective-C 的前端现在 macOS 和很多 Android NDK 默认编译器都是它。lld 是链接器它的速度比传统 GNU ld 快好几倍我自己的大型 C 项目切换过去之后链接时间肉眼可见地缩短。lldb 是调试器跟 LLVM IR 结合得很紧密。libc 是 C 标准库实现macOS 上 Clang 默认用的就是它。compiler-rt 提供了一些底层运行时支持比如 sanitizersASan、UBSanC 开发者应该很熟悉。还有衍生项目 MLIR、Polly、Flang。尤其 MLIR 这两年特别火在 AI 芯片编译器领域出场率极高。你在面试芯片公司时大概率会被问到这个。1.3 什么人适合啃这个仓库我不建议所有人一上来就去读源码。但如果下面任意一条戳中你这个项目值得你深入你在做性能优化想让 C 生成更快的汇编得知道编译器优化 pass 的顺序。你所在团队在做静态分析或者代码扫描Clang 有一堆现成的检查器。你想学一门新语言怎么落地比如自己实现一个小型方言然后翻译到 LLVM IR 再生成机器码。你想理解 WebAssembly 或者 GPU 编译器的原理LLVM 都把后端抽象好了。我自己以前总觉得“编译器离我很远”直到被一个问题逼到去读 optimization pipeline 的源码才意识到现代语言工程有多依赖这套基础设施。2. 源码结构拆解先把这个仓库的地图记熟2.1 顶层目录都放了些啥克隆下来的llvm-project目录很大第一次进去会有点懵。我建议你先忽略那些名字古怪的子目录先看几个核心的就够了目录作用llvm/核心库和基础工具包括 IR、优化 pass、目标后端、opt/llc 等clang/C/C 编译器前端还包括静态分析器和重构工具lld/可执行文件链接器lldb/调试器libcxx/和libcxxabi/C 标准库和 ABI 兼容层compiler-rt/sanitizers、profile 运行时等底层库polly/面向循环优化的多面体模型框架mlir/面向机器学习编译器的中间表示框架flang/Fortran 前端bolt/二进制优化工具偏向性能分析场景我自己第一次看到这么多目录也有点发怵但实际操作中我们绝大多数时间只会碰llvm/和clang/。很多子项目是可以完全关掉的这我后面会讲。2.2 核心库 llvm/ 的正确打开方式如果你想读源码llvm/底下有几个目录最重要llvm/include/llvm/IR/IR 的定义就在这里比如Instruction、BasicBlock、Function这些核心类。llvm/lib/Transforms/各种优化 pass比如InstCombine、GVN、LoopVectorize。llvm/lib/Target/各 CPU 架构的后端实现X86、AArch64、RISCV 等。llvm/tools/平时用的命令行工具opt、llvm-as、llvm-dis、llc都在这。读源码不要从头按顺序读我建议从opt这个工具入手。因为它最直观我拿到一份 IR跑某个 pass看到 IR 变化整个过程像实验一样。这样你理解 pass 是怎么注册、怎么调度、怎么改 IR 的效率比直接躺在Instruction类的实现里高得多。2.3 clang/ 前端又拆成了几层Clang 目录的核心在clang/lib。它会先把 C/C 源码解析成 AST然后做语义分析最后通过 CodeGen 模块把 AST 翻译成 LLVM IR。这几个子目录值得关注clang/lib/ASTAST 节点定义你写一个clang -ast-dump命令能看到源码被拆成的语法树。clang/lib/Sema语义分析负责捕捉“类型不匹配”“未定义变量”这类错误。clang/lib/CodeGen把 AST 生成 IR 的地方这里最接近 LLVM 核心。clang/lib/Driver驱动层负责解析命令行参数、选择工具链、调用各种子工具。如果你对 clang-tidy 那种静态检查感兴趣可以看clang-tools-extra/下的 check 实现它提供了非常完整的回调接口方便你去写自定义检查规则。2.4 想少花点时间怎么只编译一部分很多人一上来直接全量构建结果不是内存爆了就是磁盘不够。实际用不到那么多子项目。在 CMake 配置阶段可以通过-DLLVM_ENABLE_PROJECTSclang;lld只选择要构建的项目。你不需要lldb就把lldb从分号列表里去掉不需要polly也不要加进去。这样能省掉大量编译时间。别问我是怎么知道的问就是我第一次把lldb也编进去了在“即将完成”的阶段卡了整整 30 分钟。3. 动手构建从源码跑通一个可用的 Clang3.1 准备工作与依赖安装构建 LLVM 需要这几个前提条件一台内存至少 8GB 的机器推荐 16GB。内存不够时 Ninja 可能直接 OOM或者编译进程被杀掉。磁盘至少剩余 50GB。Release 构建加 Clang 全套大概需要 20-30GB但保险起见留足。系统装了 Git、CMake、Ninja。有可用的 C/C 编译器。Linux 上可以用 GCCmacOS 上可以用自带 Clang。我自己用的是 Ubuntu 22.04先确认工具链sudo apt update sudo apt install build-essential cmake ninja-build python3 git确认版本cmake --version ninja --version gcc --versionLLVM 对 CMake 版本有要求太旧会直接报错。如果你用的发行版提供的 CMake 太老建议装较新的版本。3.2 用 CMake 配置构建参数逐个说明构建配置是这一步的重点。我用的是这个命令git clone https://github.com/llvm/llvm-project.git cd llvm-project cmake -S llvm -B build -G Ninja \ -DCMAKE_BUILD_TYPERelease \ -DLLVM_ENABLE_PROJECTSclang;lld \ -DLLVM_TARGETS_TO_BUILDX86 \ -DLLVM_ENABLE_ASSERTIONSON-S llvm指定源码目录是llvm/注意不是根目录因为 CMakeLists.txt 在llvm/下。-B build指定输出目录。-G Ninja用 Ninja 作为构建系统。Ninja 比 Make 快而且默认支持并行。除非你对 Make 有执念否则我强烈建议 Ninja。-DCMAKE_BUILD_TYPERelease释放模式。Debug 编译出的clang有完整调试符号但构建时间可能是 Release 的三倍以上体积也大得多。没有调试需求的话Release 是最合适的选择。-DLLVM_ENABLE_PROJECTSclang;lld只构建 Clang 和 lld。分号在 shell 里要加引号否则会被解释成命令分隔符。-DLLVM_TARGETS_TO_BUILDX86只生成 X86 后端。如果你在 ARM 机器上实验改成 AArch64 能省不少时间。全量生成所有 Target 也可以但没必要。-DLLVM_ENABLE_ASSERTIONSON开启断言。建议开着虽然会稍微影响性能但你做二次开发时断言真的能救你命——跑 pass 时如果 IR 不合法断言会先报警而不是让你面对一段玄学崩溃。3.3 构建过程实测进度、耗时与硬件门槛配置完成后直接ninja -C build clang lld只构建clang和lld这两个 target别直接跑裸ninja否则会把所有可选工具全部编一遍。我这台机器是 8 核 16 线程 CPU、16GB 内存Release 模式下构建 clang lld 用了大概 35 到 40 分钟。如果是 4 核大概要两小时起步你需要做好心理准备。构建过程中可以看看任务管理器Ninja 默认并行数等于 CPU 线程数。如果发现内存占用接近物理内存上限可以减少并行度ninja -C build -j 8 clang lld-j参数可以控制并发数。1GB 内存对应 1 个线程这个粗略公式我这几年用下来还算靠谱。构建完成后产物在build/bin/下。验证一下build/bin/clang --version能看到类似这样的输出clang version 18.0.0 (https://github.com/llvm/llvm-project.git ...) Target: x86_64-unknown-linux-gnu Thread model: posix3.4 验证产物写个小 C 程序让新编译链跑起来我通常写一个简单的斐波那契函数验证工具链#include stdio.h int fib(int n) { if (n 2) return n; return fib(n - 1) fib(n - 2); } int main(void) { printf(%d\n, fib(10)); return 0; }编译并运行build/bin/clang -O2 fib.c -o fib ./fib能正确输出55这套工具链就跑通了。接下来才是我最爱的部分——看看优化器到底对代码做了什么。4. 核心体验用工具链看懂优化器在做什么4.1 用 Clang 编译一个小函数对比不同优化级别为了直观感受优化器的工作我写了一个非常简单的函数int add_one(int x) { return x 1; }先以-O0编译生成汇编build/bin/clang -O0 -S add_one.c生成的汇编很长因为-O0把每个变量都放在内存里执行了很多冗余的加载和存储。其中核心片段大概是pushq %rbp movq %rsp, %rbp movl %edi, -4(%rbp) movl -4(%rbp), %eax addl $1, %eax popq %rbp retq这个版本把参数先存到栈上再读回来做加法。你可以看到大量堆栈操作。再以-O2编译build/bin/clang -O2 -S add_one.c优化后的汇编就干净多了leal 1(%rdi), %eax retq一条leal指令就完成了加一操作参数直接放在寄存器里根本没有访问内存。同一个 C 函数两级优化汇编差出四倍指令量。这就是编译器优化价值最直观的体现。4.2 IR 长什么样随手拆出一份来看看汇编能让你看到结果但优化器操作的对象不是汇编而是 IR。用下面的命令可以拿到一个函数的 LLVM IRbuild/bin/clang -O0 -S -emit-llvm add_one.c生成的文件里长这样define dso_local i32 add_one(i32 noundef %x) #0 { entry: %x.addr alloca i32, align 4 store i32 %x, ptr %x.addr, align 4 %0 load i32, ptr %x.addr, align 4 %add add nsw i32 %0, 1 ret i32 %add }读这种代码有个技巧先找define这是函数的入口再找基本块也就是entry:这种标签然后从上往下看所有%开头的变量它们是不可变的 SSA 值。能看到-O0下 IR 也在做 alloca 和 store/load非常啰嗦。这时候可以尝试用opt工具手动跑一个优化build/bin/opt -passesmem2reg add_one.ll -S -o add_one_opt.llmem2reg是一个把内存变量提升为寄存器变量的基础优化 pass。跑完之后再看文件alloca 和 load/store 基本消失了整个函数干净得像直接写出来的高级代码define dso_local i32 add_one(i32 noundef %x) #0 { %1 add nsw i32 %x, 1 ret i32 %1 }这时候你才真正明白优化器是拿 IR 在干什么事情。它不是靠魔法把性能变好而是把可读的高级语言代码逐步降级成更接近硬件的、更少冗余的计算过程。4.3 从 IR 到汇编llc 和指令选择IR 优化完最终还要翻译成目标机器的汇编这个活由后端完成。llc就是一个把 IR 转成汇编的工具。上手很简单build/bin/llc add_one_opt.ll -o add_one.s你可以在生成的汇编里看到熟悉的leal、retq。后端做的工作很复杂包括指令选择、寄存器分配、指令调度但命令行用起来就是这么简单。对于新手我的建议是先用clang -S和opt -passes这两个工具理解前端和中端后端那些细节可以放到以后再说。4.4 顺手试一下 Clang 自带的优化报告除了看 IRClang 还提供了一个特别适合性能分析的功能优化报告。给编译加一个标志build/bin/clang -O3 -Rpassloop-vectorize -Rpass-missedloop-vectorize -c matmul.c如果代码里的循环被向量化了你会看到 Clang 输出类似这样的信息matmul.c:12:3: remark: vectorized loop (vectorization width: 4, interleaved count: 2)这比反复看汇编猜优化器在想什么高效太多了。我经常用-Rpass系列来和编译器“对话”它在哪做了优化、在哪放弃优化、为什么放弃都有明确提示。5. 新手最容易踩的坑与排查实录5.1 构建慢到怀疑人生这个问题我见得太多了不只是新手连我这种老油条都经历过。症状是卡在某个文件上半天不动那是 CPU 单线程瓶颈。排查思路先确认你已经指定-G Ninja并且没有手动限制-j太低。再检查LLVM_ENABLE_PROJECTS少开几个项目会快非常多。如果还慢可以用ccache。配置编译时使用 ccache 后后续增量编译速度快到起飞。我第一次没装第二次装了之后直接被惊到。在 CMake 配置时加一行-DLLVM_CCACHE_BUILDON前提是你系统装了 ccache。几十行代码改动之后它们只需要几十秒而不是全量重编。5.2 编译过程中磁盘爆了LLVM 构建非常吃磁盘。Release Clang 通常要 20 到 30GBDebug 模式会翻倍。如果你在/分区构建极有可能把系统盘塞满。排查思路先看df -h确认剩余空间。如果不够把 build 目录放到空间更大的磁盘。用完之后直接删 build 目录就行不会污染系统。我也习惯把 build 目录放在独立分区这样万一系统盘空间紧张不会波及开发环境。另外当配置参数大改时建议删掉 build 目录重新来一遍而不是反复改 CMake 配置。保留旧缓存有时会导致一些二义性问题表现为莫名其妙的链接失败。5.3 CMake 和 GCC 版本太老LLVM 主分支对 CMake 和编译器版本要求很严格。我遇到过最典型的报错是CMake Error: Unsupported version of CMake这种问题没有捷径只能升级工具链。Ubuntu 上可以用 apt也可以通过 pip 装新版本 CMake。GCC 版本过老时LLVM 代码里用的新 C 标准会编译不过错误信息会指向某个奇怪的模板。不用怀疑人生大概率就是编译器版本太旧。5.4 Clang 编译程序时找不到标准库头文件自己编译的 Clang 默认会去系统里找标准库头文件但如果你用的是 libc 而不是系统的 libstdc可能碰到fatal error: vector file not found这种情况通常是因为 Clang 和 C 标准库的配合没配好。最简单的解决办法是不指定 libc让它用系统默认的 libstdc。如果你确实需要 libc那得先把libcxx和libcxxabi构建出来再用-stdliblibc显式指定。这个路径对新手有点绕我建议暂时先不用。5.5 打开断言后跑测试突然异常退出如果你后来自己改了 pass并且在LLVM_ENABLE_ASSERTIONSON模式下跑测试会遇到很多“断言失败”。这不算 bug恰恰说明你的代码有某一处违反 IR 约束。排查思路先看断言信息指向哪个文件、哪个函数大部分问题集中在 IR 类型不匹配、基本块缺少终结指令等。再用opt -verify对 IR 做验证它能告诉你 IR 哪里不合法。实在找不到就二分法先跑一个最小的测试用例逐步加代码把问题缩小到某一个 pass。这是调试 LLVM 开发的日常节奏习惯就好。6. 从“能用”到“会玩”三个工程经验分享6.1 不要迷信默认参数配置参数对应具体场景很多 LLVM 教程默认全量构建这其实就是我一开始犯的错。如果你只是做 C/C 日常编译LLVM_ENABLE_PROJECTSclang就足够了。做链接优化再考虑加lld做调试再考虑lldb做 MLIR 实验再加mlir。项目是按需拆分的没必要为不需要的组件买单。6.2 Debug 和 Release 的区别比你想象中大Debug 编译出的clang性能会差很多但如果你在改 LLVM 源码、调试 pass那 Debug 版本能提供更完整的符号和更清晰的断言。我现在的习惯是保留两个 build 目录一个 Release 日常编译用一个 Debug 做开发调试用。两个目录并存也就二十几GB但省心不少。6.3 放心大胆地改源码llvm-project 最大的魅力在于它是开源且模块化到极致的编译器。你不需要懂全部代码就能改一点东西并看到效果。你可以在某个 optimization pass 里加一行打印也能新增一个简单的自定义 pass通过opt加载进去运行。这个过程非常像做实验改一行跑一下看 IR 变化立刻得到反馈。成为 LLVM contributor 没有那么高不可攀很多新人就是从修注释和文档开始的。如果你也在研究这个项目我的建议是不要被仓库规模和术语吓倒先动手构建一个能用版本再拿手头代码看 IR从最小的函数开始理解优化器。这比我当年对着文档啃两个月再动手的效率高十倍。
