phi指令在控制流汇合点根据前驱基本块静态选择对应值，必须置于基本块开头、参数顺序与前驱顺序严格一致，且所有候选值类型相同、在对应前驱末尾已定义。
phi指令的输入值由前驱基本块决定
phi指令不“计算”值，也不“判断”条件——它只做一件事：在控制流汇合点，根据**上一个执行的基本块（predecessor）**，从多个候选值中挑出对应的那个。这个选择完全静态、确定，在IR生成时就已写死，运行时不查条件、不分支跳转。
常见错误现象是试图把phi当普通赋值用，比如在同一个基本块里多次写phi，或想让它响应运行时条件变化。这违反SSA规则，LLVM verifier会直接报错：PHI node entries do not match predecessors!
- 每个
phi操作数必须与当前基本块的一个前驱基本块一一对应 - 前驱块数量必须等于
phi参数对的数量（如[ %val1, %bb1 ], [ %val2, %bb2 ]要求当前块恰好有两个前驱：%bb1和%bb2） - 所有候选值必须是同一类型，且必须在对应前驱块的末尾（即跳转前）已定义
为什么不能在if.then里直接用%result，而必须用phi
因为LLVM IR强制SSA形式：每个变量只能被定义一次。在if-else结构中，%result在%if.then和%if.else里各被定义了一次，它们是两个独立的值。merge块需要一个统一的名字来代表“无论走哪条路最终得到的result”，phi就是为此而生的桥梁。
使用场景典型如：函数返回值、循环变量更新、条件赋值后的后续计算。忽略这点强行绕过phi（比如用全局变量或alloca+store/load），会导致优化失效、verifier失败，或后端生成低效代码。
- 错误写法：
%final = add i32 %result, 1—— 此时%result作用域只在各自分支内，merge块不可见 - 正确写法：
%final = phi i32 [ %result, %if.then ], [ %result, %if.else ] - 注意：两个
%result实际是不同指令的返回值，名字相同只是巧合；IRBuilder会自动重命名避免冲突
phi的参数顺序不重要，但必须与前驱顺序一致
LLVM不要求phi参数按字母或块地址排序，但它严格校验：第N个参数对中的基本块名，必须是当前块的第N个前驱（按LLVM内部遍历顺序）。这个顺序由CFG构造时决定，不是源码书写顺序。
容易踩的坑是手写IR时硬编码块名顺序，却没确认实际前驱列表。调试方法是用opt -view-cfg或llc -print-machineinstrs看CFG图，或用BasicBlock::getTerminator()->getSuccessor(i)在Pass里打印前驱。
- 若前驱是
%a、%b、%c（按此顺序），则phi必须写成[ %x, %a ], [ %y, %b ], [ %z, %c ] - 写成
[ %y, %b ], [ %x, %a ], [ %z, %c ]会导致verifier失败，即使块名都对 - IRBuilder自动处理顺序匹配，手动构造
PHINode时需调用addIncoming()并确保传入的块顺序与getPredecessors()一致
phi节点必须放在基本块开头，且不能有其他非phi指令前置
这是IR语法硬性规定：phi指令只能出现在基本块的第一条位置，且所有phi必须连续排列。如果在phi之后插入add或load，LLVM解析器会拒绝加载该bitcode。
性能影响很小——phi本身不生成机器码，只是数据依赖标记；但放错位置会直接中断整个编译流程，尤其在自定义前端或手写Pass时容易疏忽。
- 合法：
merge:%x = phi i32 [ %a, %then ], [ %b, %else ]%y = add i32 %x, 1 - 非法：
merge:%tmp = load i32, i32* %ptr%x = phi i32 [ %a, %then ], [ %b, %else ] - IRBuilder默认遵守此规则；手动新建
BasicBlock后，务必先插入phi，再插入其他指令
实际写Pass或前端时，最常被忽略的是前驱块顺序与phi参数的隐式绑定关系——它不像C语言的三元运算符那样直观，而是一个基于CFG拓扑的静态映射。一旦CFG变更（比如加了新的跳转路径），所有相关phi都得同步检查参数列表，否则verifier会在优化早期就终止流程。
