-verify 是独立 Pass，需显式插入以校验 IR 合法性；报错常在“使用者”而非“定义者”；应调用 verifyFunction 或 verifyModule 主动验证，避免隐式破坏。
Pass 执行后 IR 不合法，多数是因为修改破坏了 SSA 或 def-use 链，不是 Pass 本身写错，而是改 IR 时没同步更新依赖
用 opt -verify 在每个 Pass 后插入校验
LLVM 默认不会在 Pass 运行后自动验证 IR 合法性，必须显式插入 -verify。这不是调试开关，而是独立 Pass，可插在任意位置：
- 单个 Pass 后验证：
opt -load ./MyPass.so -mypass -verify -disable-output input.ll - 多个 Pass 流水线中逐段验证：
opt -passes='mypass,verify,mem2reg,verify,dce' input.ll -o output.ll - 注意
-verify会检查整个 Module，若中间某个 Function 被改坏，它会直接报错并退出，定位到具体%bb12或@foo函数
为什么 -verify 报错位置常和你修改的指令对不上
IR 合法性检查是全局的，一个 getelementptr 类型不匹配可能不立刻崩溃，但会导致后续某条 store 的 operand 指向非法 Value，-verify 最终报错点往往是“使用者”，而非“定义者”。常见现象：
- 报错
Use of undefined value '%x'：你删了一个 Instruction，但没调用I->replaceAllUsesWith(UndefValue::get(I->getType())) - 报错
Invalid operand type for instruction：用Builder.CreateAdd(A, B)时 A 和 B 类型不一致（比如i32vsi64），而 Builder 不做隐式转换 - 报错
Instruction does not dominate all uses：把指令移到另一个 BasicBlock 里，但没确保其定义在所有使用点之前（SSA 要求）
在自定义 Pass 里主动调用验证函数
如果想在 runOnFunction 中间某步立刻确认 IR 状态，不要依赖外部 opt，直接调用 LLVM 内置校验：
llvm::verifyFunction(F, &errs()); // 只校验当前 Function // 或 llvm::verifyModule(*F.getParent(), &errs()); // 校验整个 Module
这比反复跑 opt 快得多，适合开发迭代。但注意：verifyFunction 不检查跨 Function 引用（如 GlobalVariable 初始化值），这类问题仍需 verifyModule。
容易被忽略的隐式破坏点
有些 IR 修改看似安全，实则悄悄破坏合法性：
- 调用
I->eraseFromParent()后，没清理其所有use—— 即使你认为没人用了，IR 分析 Pass（如 DCE）可能还持有引用 - 用
ReplaceInstWithValue替换指令，但新 Value 的类型和原指令返回类型不兼容（例如原为i1，替换成i32） - 手动构造 PHI 节点时，漏掉某个 predecessor 的入边，导致
verifyFunction报PHI node entries do not match predecessors
最稳妥的做法：每次修改 IR 后，先调一次 verifyFunction，再继续下一步；宁可多验几次，也别让错误累积到 -verify 报出一堆嵌套错误才去回溯。
