根本原因是ir的ssa形式被破坏：删除指令后其value仍被引用，导致后续遍历访问野指针；正确做法是严格按replacealluseswith→erasefromparent→清除裸指针引用三步执行。
LLVM Pass 删除指令后崩溃，根本原因不是“删得不对”，而是 IR 的 SSA 形式被破坏——删掉一个 Instruction 后，它产出的 Value 仍被其他指令引用，LLVM 在后续遍历时触发断言或访问已释放内存。
为什么 deleteInstruction() 会引发段错误或断言失败
LLVM IR 是静态单赋值（SSA）形式，每条指令产生的 Value 可能被多个地方使用（use 链）。直接调用 I->eraseFromParent() 或 BB->getInstList().erase(I) 只是把指令从基本块中移除，但不会自动处理它的所有 Use。一旦后续 Pass（比如 VerifierPass）或 IR 打印逻辑尝试遍历某个仍指向该已删指令的 Use，就会读到野指针。
常见现象包括：
Assertion failed: !isa<undefvalue>(V) && "Cannot use an undefined value!"</undefvalue>-
Segmentation fault (core dumped)发生在for (auto &I : BB)循环中 -
opt -verify报Invalid operand或Use not found in value's use list
正确删除指令的三步操作顺序
必须按严格顺序执行，缺一不可。漏掉任何一步都可能让 IR 进入非法状态：
- 先调用
I->replaceAllUsesWith(UndefValue::get(I->getType()))—— 把所有对它的依赖替换成undef（如果类型允许）；若不能用undef（如 void 类型），则需替换为合法占位值（如Constant::getNullValue） - 再调用
I->eraseFromParent()—— 从父基本块中移除 - 最后确保不保留任何对该
Instruction*的裸指针引用（尤其避免在循环中 erase 后继续用I或其迭代器）
示例片段：
for (auto &I : make_early_inc_range(BB)) {
if (shouldRemove(&I)) {
I.replaceAllUsesWith(UndefValue::get(I.getType()));
I.eraseFromParent();
}
}
哪些场景下不能简单 replaceAllUsesWith(undef)
不是所有指令都能安全替换为 undef。以下情况需要特殊处理：
-
PHINode：不能用undef替换，必须先用removeIncomingValue()清理入边，再调用eraseFromParent() - 作为
BranchInst条件的操作数：若删的是条件计算指令，需同步调整跳转逻辑，否则分支语义丢失 - 函数返回值（
ReturnInst的 operand）：不能替换成undef，应改用Constant::getNullValue()或根据函数签名构造合法返回值 - 被
CallInst作为参数传递：若该参数非 trivial（如 struct、array），undef可能导致后端生成非法机器码
验证是否删干净：opt -verify 是必跑步骤
即使 Pass 编译通过、opt -load 加载成功、也跑完了 runOnFunction，也不能认为 IR 合法。必须显式加验：
opt -load ./MyPass.so -mypass -verify -disable-output input.ll- 若报错，说明仍有 dangling use 或类型不匹配，问题一定出在删除逻辑里
- 不要依赖
opt -O2自带的 verify：它默认关闭，且可能被其他 Pass 干扰
最易忽略的一点：LLVM 不会在你调用 eraseFromParent() 时立刻崩溃，而是在下一个 Pass 第一次访问那个悬空 Use 时才崩——所以崩溃位置和删除位置往往相隔很远，别被栈回溯误导。
