直接调用rewriter.replaceOp(op, newValue)即可自动重连所有users，无需手动遍历；它会延迟删除旧Op，确保SSA和支配约束正确。
怎么用 PatternRewriter 替换一个 Op 并让所有 users 自动指向新值
直接调用 rewriter.replaceOp() 就行，它会自动重连所有使用该 Op 结果的下游操作。关键不是“手动更新 users”，而是让 MLIR 的 SSA 机制和重写器帮你做完——只要你传入正确的替换值（Value 或 ValueRange）。
常见错误是：自己遍历 op->getUsers() 然后逐个调用 rewriter.replaceUsesWithIf()，这不仅多余，还容易漏掉区域（region）内或嵌套 op 中的 use，甚至破坏 SSA 不变量。
-
rewriter.replaceOp(op, newValue)：最常用，适用于单结果 Op；newValue必须是同一类型、来自同 context 的Value -
rewriter.replaceOp(op, newValues)：用于多结果 Op，newValues是ValueRange，长度必须与 op 的结果数一致 - 如果新值还没创建（比如要新建一个
arith.constant），先用rewriter.create<...>()</...>构造，再传给replaceOp - 不能在
matchAndRewrite外调用replaceOp；它只在 pattern 执行上下文中有效
为什么 replaceOp 后旧 Op 没被删，但 IR 看起来“没变”
MLIR 不会在调用 replaceOp 时立即删除旧 Op，而是标记为“待删除”（dead），等整个 pattern 集合执行完、重写器提交（commit）时才真正移除。所以如果你在调试中打印 IR，可能仍看到旧 Op —— 这不是 bug，是延迟清理机制。
真正要注意的是：不要在同一个 matchAndRewrite 中多次替换同一个 Op，或对已 replaceOp 过的 Op 再次读取其结果（op.getResult(0) 会返回 dangling value）。
- 替换后立刻访问
op.getResult(0)会触发断言失败或未定义行为 - 若需基于原输入构造新值，务必在
replaceOp前完成所有op.getOperand()、op.getAttr()等读取 - 调试时可用
llvm::dbgs() 查看 Op 是否已被标记为 dead（输出含 <code>DEAD）
替换 Op 时怎么处理 region 和 block 参数
如果被替换的 Op 带有 region（比如 affine.for、scf.if），replaceOp 默认不触碰 region 内容。你得自己决定是否要同步迁移 region —— 通常不需要，除非你在做 dialect 转换（如 lowering 到 LLVM）。
更常踩坑的是 block 参数：当替换一个产生 block 参数的 Op（如 scf.while 的 iter_args），不能只替换 op 本身，还要确保新值能合法流入对应 block 的参数列表。这时应改用 rewriter.replaceOpWithNewOp<newop>(op, ...)</newop>，它会自动处理 region 入口参数绑定。
-
replaceOpWithNewOp是replaceOp+create的组合快捷方式，且对 region 更安全 - 若新 Op 的 region 需复用旧 region，用
rewriter.inlineRegionBefore()显式搬运，别依赖自动继承 - block 参数类型必须严格匹配，否则
replaceOpWithNewOp会失败并返回failure()
替换后用户没更新？先检查 Value 的 type 和 owner 是否一致
最隐蔽的问题：新 Value 和旧 Op 的结果类型相同，但来自不同 dialect 或不同 context（比如跨 module 创建），导致 replaceOp 静默失败或后续 pass 报 use not dominated by def 错误。
MLIR 要求替换值必须满足支配关系（dominance）：新值的定义必须支配所有 use 点。简单说，就是新值得在 CFG 中“出现在所有 users 上方”。对于顶层函数内操作，只要新值在同一 block 或上游 block 创建，一般没问题；但若在 nested region 里创建，就得确认插入点（rewriter.setInsertionPoint）是否合理。
- 用
newValue.getDefiningOp()检查它是否非空，且所属 block 与 users 的 block 满足支配关系 - 避免在
op->getBlock()->getTerminator()后插入新值，那会导致支配失效 - 调试时加一句
assert(newValue.getType() == op->getResult(0).getType())，类型不等会直接拒绝替换
真正难的不是“怎么换”，而是“换完之后整个 IR 图是否还满足 SSA 和支配约束”。每次 replaceOp 都在修改图结构，而 MLIR 不做运行时校验 —— 它信任你传进来的 Value 是合法的。
