图着色寄存器分配：从活跃性分析到溢出处理的完整指南

1. 寄存器分配为什么绕不开图着色

寄存器分配这件事，在编译器后端的地位有点像装修时的水电改造，平时没人想起来，一旦做不好整屋性能都会崩。我见过不止一次，辛辛苦苦把优化 pass 调得风生水起，内联、向量化、循环展开全开，跑分结果却纹丝不动，最后定位发现是寄存器分配把热循环里的几个变量全部挤到了内存，原本一条加法指令变成 load、add、store 三条。问题不在优化，而在门没守住。

图着色寄存器分配（Graph Coloring）就是把这个"守门"问题数学化的经典方案。它的核心思想非常朴素：把每个虚拟寄存器（编译器 IR 里的临时变量）当成图的一个节点，两个节点如果生命周期重叠、不能共用同一个物理寄存器，就在它们之间连一条边。物理寄存器就是颜色，分配寄存器就是给整张图染色，要求相邻节点颜色不同。如果物理寄存器有 k 个，就是经典的 k-着色问题。

这套模型在上世纪 80 年代初由 Chaitin 在 IBM 的 PL.8 编译器中引入，此后三十多年一直是 AOT 编译器（GCC、LLVM 的若干分配器、各种研究性编译器）的主流方案。它的价值和难点都在于：分配质量高，但实现细节极多，从活跃性分析、干涉图构建、简化排序到溢出处理，任何一个环节偷懒，最后都会在生成的代码质量上暴露出来。这篇文章我打算从一个实践者的角度，把整条链路拆开讲清楚，包括原理、流程、伪代码和工程里最容易踩的坑。

1.1 最影响后端性能的 pass，往往是寄存器分配

很多人以为指令调度、循环优化是后端性能的大头，实际在寄存器压力大的目标架构上，寄存器分配常常是收益最明显的 pass。原因很简单：内存访问比寄存器访问慢一个数量级以上，而现代 CPU 的寄存器文件又极其有限。x86-64 只有 16 个通用整数寄存器，ARM64 多一些，有 31 个，但相比编译器中可能出现的成百上千个虚拟寄存器，仍是杯水车薪。

寄存器分配的本质是一个受限资源下的映射问题：把无限多个虚拟寄存器映射到有限的物理寄存器，映射不下的变量就得"溢出"（spill）到内存栈槽里，每次使用前 load，每次定义后 store。一个变量的生命周期如果横跨了多次访问，溢出的代价会成倍放大。所以"尽量少溢出"和"溢出放在代价最低的地方"就是寄存器分配器的主要目标。

这里有个反直觉的事实：寄存器分配的建模粒度不是"变量"而是"活跃区间"。同一个源代码变量在不同阶段可以分配到不同寄存器，两个不同的虚拟寄存器也可以在生命周期不重叠时复用同一个物理寄存器。图着色模型天然支持这种复用：只要节点间没有边，它们就可以涂同一个颜色。

1.2 问题的数学本质：把冲突变成一个图

把寄存器分配抽象成图着色，关键是定义"冲突"（interference）。两个虚拟寄存器如果在某个程序点同时活跃，且其中一个的活跃区间覆盖了另一个的定义点，它们就不能共用一个物理寄存器。

为什么这一条如此重要？因为物理寄存器在任意时刻只能保存一个值。如果变量 a 和变量 b 都活着，你不可能让它们睡在同一个寄存器里，否则更新 a 就会弄丢 b。这种冲突关系天然构成一张无向图，节点是虚拟寄存器，边是"不能同色"。于是"用 k 个寄存器完成分配"就等价于"用 k 种颜色给这张图染色，并保证相邻节点异色"。

1.3 为什么图着色是 NP 完全的，我们还要用它

图着色问题是经典的 NP 完全问题，这意味着在一般情况下不存在多项式时间的精确算法。既然这样，为什么还要用图着色做寄存器分配？

答案是：我们不需要最优解，只需要一个足够好的近似解。编译器对寄存器分配的要求是"在可接受的编译时间内，尽可能少地产生溢出代码"。图着色模型提供了一套系统化的近似框架——用贪心简化（Simplify）、启发式溢出候选选择和乐观着色来逼近一个可行解。实践表明，这套框架在绝大多数真实程序上的分配质量显著优于更简单的局部分配或线性扫描（线性扫描会在第 5 章重点对比）。

另一个角度是：寄存器分配的图虽然大，但不是随便一张图。它由程序的控制流和数据流关系决定，在 SSA 形式下甚至具备特殊的结构性质（后面会提到弦图），实际可着色性比理论最坏情况好得多。正因如此，即使问题是 NP 完全的，图着色方案依然在工程中稳坐主力位置。

2. 从三地址码到干涉图：活跃性分析是地基

干涉图不是凭空画出来的，它的唯一输入是活跃性分析（liveness analysis）的结果。活跃性分析做错了，干涉图就画错，后面的简化、着色、溢出全白搭。我在实际调试寄存器分配器时，遇到的大多数"Spill 异常多"问题，追到根上都是活跃性分析的 bug，而不是着色算法的 bug。

活跃性分析要回答的问题是：每个程序点，哪些变量在未来还会被读取？一个变量如果在某个点之后还有机会被读取，就说它在该点"活着"；如果之后永远不会再读了，就说明它已经"死"了。干涉图里所有边，本质上都来自两个活着的时间段在某个点上的重叠。

2.1 活跃性分析：数据流方程和控制流边界

活跃性分析是一个经典的反向数据流问题，因为它要从程序的出口往回推。对每个基本块 B，需要计算两个集合：IN[B] 和 OUT[B]，分别表示进入和离开 B 时活跃的变量集合。数据流方程如下：

code复制IN[B]  = USE[B] ∪ (OUT[B] − DEF[B])
OUT[B] = ∪(所有