控制流修改后PHINode未更新会导致verifyFunction报错“PHI node entries do not match predecessors!”，需按removePredecessor→addIncoming→removeIncomingValue顺序手动修复，否则引发crash或错误代码。
修改控制流后phi节点不更新的典型现象
你插入/删除分支、拆分基本块或重定向跳转后，PHINode 的入边数（incoming value count）和实际前驱块数量不一致，导致 verifyFunction() 报错：PHI node entries do not match predecessors!。更隐蔽的问题是：Phi 操作数指向已失效的 Value，或某个前驱块没被加入 phi 的入边列表，后续优化（如 GVN、DCE）可能直接 crash 或生成错误代码。
手动更新phi节点的三步操作顺序
LLVM 不会自动重写 phi 节点——它只在创建基本块或添加前驱时做基础检查，所有控制流变更后的 phi 维护必须显式完成。关键不是“加一条语句”，而是按固定顺序执行：
- 先调用
BasicBlock::removePredecessor()（如果删了前驱），它会自动从所有 phi 中移除对应入边； - 再调用
PHINode::addIncoming()为每个新增前驱显式添加入边，参数必须是Value*和BasicBlock*成对出现； - 最后调用
PHINode::removeIncomingValue()清理冗余入边（比如旧 phi 条目未被自动清除），注意该函数只删第一个匹配项，需循环调用或用迭代器精确控制。
常见误操作与对应修复
很多 Pass 在 split block 或 insert branch 后只改了 terminator，却忘了 phi，根源在于混淆了“控制流图变更”和“SSA 形式维护”两个层面：
- 用
SplitBlock()后，新块的 phi 入边不会自动继承原块的全部前驱，必须遍历原块 phi 并对每个getIncomingValueForBlock()结果调用addIncoming()到新块； - 用
BranchInst::setSuccessor()改跳转目标，但没同步更新目标块中所有 phi 的入边，会导致目标块 phi 缺少该前驱的值； - 在 loop header 插入新前驱（比如从 loop exit 回跳），但没给 header 中每个 phi 补上对应值，此时
LoopInfo可能仍认为它是自然循环，但 phi 已处于非法状态。
验证是否真的修好了
不要只靠编译不报错就认为 ok。最简验证方式是：在 Pass 结束前插入 assert(verifyFunction(*F, &errs()));。更稳妥的做法是在 runOnFunction() 返回前，用 llvm::viewCFG(F)（需启用 -DLLVM_ENABLE_DUMP=ON）看 CFG 图，确认每个 phi 的入边数 = 前驱块数，且每条入边的 block 指针和 value 类型都合法。最容易被忽略的是 phi 入边中 value 的 lifetime：如果 value 来自刚被删掉的指令，addIncoming() 会静默接受，但后续 instcombine 可能触发 use-before-def。
