conversiontarget 的核心是判定 operation 合法性：addlegaldialect() 仅声明方言合法，不保证其所有 operation 合法；需用 addlegalop 显式放行关键 operation（如 func.return），或用 adddynamicallylegalop 基于上下文动态判断；mlir 19+ 后 standardopsdialect 已拆分，旧用法会导致失败。
设置 ConversionTarget 的合法 dialect 和 operation
MLIR 方言转换的核心是 ConversionTarget，它决定哪些 operation 被视为“合法”——即无需被重写或替换，可直接保留在目标 IR 中。不合法的操作才会触发你注册的 OperationConversionPattern 去降格或重写。
最常见错误是只加了 dialect 却漏掉具体 operation，导致某些看似属于该 dialect 的 operation 仍被判定为非法（比如 std.return 在 StandardOpsDialect 中，但若 dialect 版本较新或启用了模块化拆分，它可能已移入 cf 或 func dialect）。
-
target.addLegalDialect<:affinedialect mlir::standardopsdialect>()</:affinedialect>只声明 dialect 合法，不保证其所有 operation 都自动合法 - 若需明确放行某个 operation（如
func.return），应调用target.addLegalOp<:func::returnop>()</:func::returnop> - 若某 operation 仅在特定条件下合法（如仅当 operand 类型是
memref时才允许affine.load），要用target.addDynamicallyLegalOp并传入判断 lambda - 注意
StandardOpsDialect已在 MLIR 19+ 中被拆分为arith、cf、func、memref等更细粒度 dialect；继续用旧名会导致编译失败或静默跳过
为什么 addLegalOp 比 addLegalDialect 更安全
当你写 target.addLegalDialect<:func::funcdialect>()</:func::funcdialect>，MLIR 会检查该 dialect 的 isAllowedOp 实现，而默认实现往往只放行 core op（如 func.func），却把 func.return、func.call 排除在外——因为它们现在属于 func dialect 的子集，但逻辑上被归类为“control flow 辅助操作”。
所以实际工程中更推荐显式列举：
target.addLegalOp<:func::funcop mlir::func::returnop mlir::func::callop>()</:func::funcop>target.addLegalOp<:arith::addiop mlir::arith::constantop>()</:arith::addiop>- 对自定义方言，必须确保
MyOp::hasTrait<:optrait::isterminator>()</:optrait::isterminator>等 trait 不冲突，否则addLegalOp可能因验证失败而静默失效
动态合法性判断：addDynamicallyLegalOp 的典型用法
有些 operation 合法性依赖上下文，比如 toy.print 在调试阶段允许存在，但在生成 LLVM IR 前必须全部消除；又或者 affine.for 仅当 loop bounds 可静态推导时才允许保留，否则必须展开或转成 scf。
这时要用 addDynamicallyLegalOp：
-
target.addDynamicallyLegalOp<toyprintop>([&](ToyPrintOp op) { return !op->getParentOfType<:llvm::llvmdialect>(); });</:llvm::llvmdialect></toyprintop>—— 表示只要不在 LLVM dialect 区域内就合法 -
target.addDynamicallyLegalOp<:affine::forop>([](mlir::affine::ForOp op) { return op.getLowerBound().getDefiningOp<:arith::constantop>() && op.getUpperBound().getDefiningOp<:arith::constantop>(); });</:arith::constantop></:arith::constantop></:affine::forop>—— 仅当上下界都是常量时才合法 - 注意 lambda 参数是 operation 的 const ref，不能在里面调用
rewriter或修改 IR；它只做判断，不参与重写
容易忽略的兼容性陷阱
MLIR 的 ConversionTarget 行为在不同版本间有细微差异。2025 年后主线默认启用 strict mode：未显式声明合法的 operation，即使属于已添加的 dialect，也会被标记为 illegal，并触发 “no pattern matched” 错误。
- 升级 MLIR 后若出现大量
conversion failed: no matching pattern，优先检查是否遗漏addLegalOp调用 -
target.markUnknownOpDynamicallyLegal([](Operation*){return true;})是临时兜底手段，但会掩盖真实问题，不建议长期使用 - 调试时可用
target.setDebugAction([](const mlir::Operation& op, mlir::ConversionTarget::Action action) { llvm::dbgs() 查看每个 operation 的判定结果
真正麻烦的从来不是写对一行 addLegalOp，而是搞清当前 pipeline 中哪些 operation 实际会被 encounter、它们归属哪个 dialect、以及那个 dialect 是否已被拆分或弃用。
