做过编译器后端开发的人对 phi 节点的感情通常比较复杂。它是 SSA 形式里最必要的“丑角”静态单赋值要求每个变量只赋值一次可一旦遇到 if-else 汇合、循环回边同一个“逻辑变量”明明有多个来源就必须在汇合块里用一种特殊指令把它们选出来这就是 phi。问题在于phi 的出现让所有下游 pass 都变麻烦了寄存器分配前要专门做 Phi Elimination优化 pass 要单独处理 phi 的语义MachineVerifier 要多写一套校验规则人眼读机器 IR 的时候还得在汇合块里反复比对“这到底是哪个前驱传过来的值”。而编译器圈里早就有另一条路线block arguments块参数。MLIR、Swift SIL、Cranelift 这些现代 IR 都不使用 phi它们让跳转指令在跳转的同时把值作为参数传给目标基本块目标块在入口处声明形式参数。现在LLVM 的 CodeGen 层也出现了同样方向的 RFC 思路Change MIR to use block arguments instead of phis。它想改变的正是后端机器 IR 里这种“在汇合点补登记”的值传递方式。这篇文章会从三个层面展开先把 phi 和 block arguments 两种设计彻底讲清楚再结合 LLVM CodeGen 中 MIR 的现状分析这个 RFC 方向为什么会出现、落地后有收益又有哪些雷最后给出一条可以实际操作的实验路径——用 LLVM 工具链去观察 MIR 中的 phi用 MLIR 体验 block arguments并给出 Windows 和 Linux 环境下的操作命令与常见问题。读完这篇文章你会对编译器 IR 的这项底层设计形成自己的判断而不只是记住“phi 去掉了”这个结论。1. 为什么要关注这个 RFC先给一个判断这份 RFC 不是一次单纯的语法替换。它代表的是 LLVM 后端向“现代 IR 设计”靠拢的尝试影响的不是某个 API而是机器 IR 的数据流建模方式。有人会问我是写业务代码的为什么要关心编译器后端这个问题要分几类读者来回答。如果你正在开发自定义编译器后端或者在研究 LLVM 的 GlobalISel、MachineIR、寄存器分配你迟早会遇到 phi。以 GlobalISel 的机器 IR 为例它用一条名为G_PHI的指令表示控制流汇合点的值传递。指令选择前值停留在虚拟寄存器状态问题还不大可一旦进入寄存器分配G_PHI就必须被转换成显式的 copy 或寄存器绑定。这段转换逻辑一直是后端 pass 里又难读又难调的部分。如果你用 Rust但没看过 LLVM 后端这个概念同样值得了解。rustc 最终依赖 LLVM 后端做代码生成Rust 生态中的另一个后端 Cranelift 从一开始就选择了 block arguments。现代前沿编译器几乎都在往同一个方向收敛而 LLVM 是全球编译器的事实标准它在 CodeGen 层的变化一旦落地会影响所有依赖 LLVM 后端的语言编译器。所以这篇文章真正值得读的对象是对 LLVM 后端机制感兴趣的人、正在写编译器 pass 的工程师、以及做编译器课程设计或研究的学生。读完你能理解这类 RFC 的技术动机也能在自己的编译器设计里做出更合理的选择。2. 基础概念SSA、Phi 节点与 Block Arguments在没有理解基础概念前直接聊 RFC 容易变成术语堆砌。这里先用最小例子把两条路线讲清楚。2.1 从 SSA 说起SSAStatic Single Assignment静态单赋值的核心约束每个变量只被赋值一次。这个约束让数据流分析变得非常简单——变量的定义点就是它的声明点不需要再追踪“谁在哪次迭代里改了它”。但问题随之而来。下面这个max函数result可能来自%a也可能来自%bint max(int a, int b) { int result; if (a b) result a; else result b; return result; }在 SSA 形式里result不能在分支的每个出口各赋一次因为那样result就有了两次赋值也不能在 if 之前只赋一次因为那时值还没定。矛盾的根源是控制流汇合之后同一个“逻辑变量”存在多个可能的定义而 SSA 要求所有变量只被赋一次。为了解决这个矛盾编译器有两种思路一种是在汇合点增加一个 phi 节点由该节点基于“来自哪个前驱块”选择值另一种是弱化“块内变量必须单赋值”的表述让每个基本块拥有形参由前驱块在跳转时传参。这两种思路分别对应了 phi 与 block arguments。2.2 phi 节点在汇合点补登记LLVM IR 的典型写法如下; 文件路径phi_sample.ll define i32 max(i32 %a, i32 %b) { entry: %cmp icmp sgt i32 %a, %b br i1 %cmp, label %then, label %else then: br label %merge else: br label %merge merge: %result phi i32 [ %a, %then ], [ %b, %else ] ret i32 %result }语义上它就是“如果从 then 块来取%a如果从 else 块来取%b”。每个
LLVM 后端 MIR 转向 Block Arguments：Phi 节点的现代替代方案
做过编译器后端开发的人对 phi 节点的感情通常比较复杂。它是 SSA 形式里最必要的“丑角”静态单赋值要求每个变量只赋值一次可一旦遇到 if-else 汇合、循环回边同一个“逻辑变量”明明有多个来源就必须在汇合块里用一种特殊指令把它们选出来这就是 phi。问题在于phi 的出现让所有下游 pass 都变麻烦了寄存器分配前要专门做 Phi Elimination优化 pass 要单独处理 phi 的语义MachineVerifier 要多写一套校验规则人眼读机器 IR 的时候还得在汇合块里反复比对“这到底是哪个前驱传过来的值”。而编译器圈里早就有另一条路线block arguments块参数。MLIR、Swift SIL、Cranelift 这些现代 IR 都不使用 phi它们让跳转指令在跳转的同时把值作为参数传给目标基本块目标块在入口处声明形式参数。现在LLVM 的 CodeGen 层也出现了同样方向的 RFC 思路Change MIR to use block arguments instead of phis。它想改变的正是后端机器 IR 里这种“在汇合点补登记”的值传递方式。这篇文章会从三个层面展开先把 phi 和 block arguments 两种设计彻底讲清楚再结合 LLVM CodeGen 中 MIR 的现状分析这个 RFC 方向为什么会出现、落地后有收益又有哪些雷最后给出一条可以实际操作的实验路径——用 LLVM 工具链去观察 MIR 中的 phi用 MLIR 体验 block arguments并给出 Windows 和 Linux 环境下的操作命令与常见问题。读完这篇文章你会对编译器 IR 的这项底层设计形成自己的判断而不只是记住“phi 去掉了”这个结论。1. 为什么要关注这个 RFC先给一个判断这份 RFC 不是一次单纯的语法替换。它代表的是 LLVM 后端向“现代 IR 设计”靠拢的尝试影响的不是某个 API而是机器 IR 的数据流建模方式。有人会问我是写业务代码的为什么要关心编译器后端这个问题要分几类读者来回答。如果你正在开发自定义编译器后端或者在研究 LLVM 的 GlobalISel、MachineIR、寄存器分配你迟早会遇到 phi。以 GlobalISel 的机器 IR 为例它用一条名为G_PHI的指令表示控制流汇合点的值传递。指令选择前值停留在虚拟寄存器状态问题还不大可一旦进入寄存器分配G_PHI就必须被转换成显式的 copy 或寄存器绑定。这段转换逻辑一直是后端 pass 里又难读又难调的部分。如果你用 Rust但没看过 LLVM 后端这个概念同样值得了解。rustc 最终依赖 LLVM 后端做代码生成Rust 生态中的另一个后端 Cranelift 从一开始就选择了 block arguments。现代前沿编译器几乎都在往同一个方向收敛而 LLVM 是全球编译器的事实标准它在 CodeGen 层的变化一旦落地会影响所有依赖 LLVM 后端的语言编译器。所以这篇文章真正值得读的对象是对 LLVM 后端机制感兴趣的人、正在写编译器 pass 的工程师、以及做编译器课程设计或研究的学生。读完你能理解这类 RFC 的技术动机也能在自己的编译器设计里做出更合理的选择。2. 基础概念SSA、Phi 节点与 Block Arguments在没有理解基础概念前直接聊 RFC 容易变成术语堆砌。这里先用最小例子把两条路线讲清楚。2.1 从 SSA 说起SSAStatic Single Assignment静态单赋值的核心约束每个变量只被赋值一次。这个约束让数据流分析变得非常简单——变量的定义点就是它的声明点不需要再追踪“谁在哪次迭代里改了它”。但问题随之而来。下面这个max函数result可能来自%a也可能来自%bint max(int a, int b) { int result; if (a b) result a; else result b; return result; }在 SSA 形式里result不能在分支的每个出口各赋一次因为那样result就有了两次赋值也不能在 if 之前只赋一次因为那时值还没定。矛盾的根源是控制流汇合之后同一个“逻辑变量”存在多个可能的定义而 SSA 要求所有变量只被赋一次。为了解决这个矛盾编译器有两种思路一种是在汇合点增加一个 phi 节点由该节点基于“来自哪个前驱块”选择值另一种是弱化“块内变量必须单赋值”的表述让每个基本块拥有形参由前驱块在跳转时传参。这两种思路分别对应了 phi 与 block arguments。2.2 phi 节点在汇合点补登记LLVM IR 的典型写法如下; 文件路径phi_sample.ll define i32 max(i32 %a, i32 %b) { entry: %cmp icmp sgt i32 %a, %b br i1 %cmp, label %then, label %else then: br label %merge else: br label %merge merge: %result phi i32 [ %a, %then ], [ %b, %else ] ret i32 %result }语义上它就是“如果从 then 块来取%a如果从 else 块来取%b”。每个
