MLIR Dialect 是组织操作、类型和属性的领域抽象层而非语法变体，如 StableHLO 表达神经网络语义、Affine 描述循环结构、LLVM 对应底层指令；选型依据是当前编译阶段所需抽象层级，需匹配语义支撑与细节暴露程度，避免跨层误用导致 lowering 失败或低效代码。

什么是 MLIR Dialect？

Dialect 是 MLIR 中组织操作（Operation）、类型（Type）和属性（Attribute）的命名空间单元，不是语法变体，而是**领域抽象层**。比如 StableHLO 表达神经网络算子语义，Affine 描述嵌套循环结构，LLVM 对应底层指令生成——它们之间不兼容，但可通过 lowering 逐级转换。

选 Dialect 的核心依据：你当前在处理哪一层抽象？

别从“功能强不强”出发，而要问：我手上的 IR 正处在编译流程的哪个阶段？对应方言是否提供足够语义支撑，又不过度暴露底层细节？

• 输入是高层模型（如 PyTorch/TF 导出的图） → 优先用 StableHLO 或 TOSA：它们保留 conv、matmul 等数学语义，方便做融合、形状推导；直接跳到 Linalg 会丢失算子边界，让 fusion pass 失效
• 要做循环分块、tiling、内存布局优化 → 切到 Affine 或 Linalg：前者擅长多面体建模（如 affine.for 嵌套），后者把计算表达为结构化 payload（如 linalg.matmul），便于 pattern-matching 重写
• 目标是生成 GPU kernel 或向量化代码 → 必须经 Vector（向量抽象）→ GPU（同步/共享内存）→ LLVM（寄存器分配）：跳过 Vector 直接从 Linalg 降到底层，会丢失向量化机会，且 GPU dialect 要求显式插入 gpu.barrier，不能靠 guess

常见误选场景与后果

选错 Dialect 不报错，但后续 lowering 会卡住或产出低效代码：

• 用 LLVM dialect 写循环逻辑 → 得到一堆 br、icmp，无法做循环变换；affine.for 在这里不存在，连 loop-carried dependency 都难分析
• 在 StableHLO 层强行插入硬件相关属性（如 gpu.kernel）→ parser 拒绝：该 dialect 根本不定义这个 operation，TableGen 生成的 C++ 类里没有对应注册
• 跨 Dialect 直接匹配 operation（如在 Linalg pass 里 match stablehlo.convolution）→ 匹配失败：operation 名字带 namespace，stablehlo.convolution 和 linalg.conv 是两个完全无关的 operation

实际项目中怎么快速判断？

看你的 pass 所依赖的 operation 是否已存在、是否带所需语义，而不是看文档标题有多“高级”：

• 运行 mlir-opt --dump-passes 查看当前 IR 使用的 dialect name（每行 operation 前缀就是）
• 用 mlir-opt --print-op-generic 输出 generic form，确认 operation 是否属于目标 dialect（如 "linalg.matmul" 开头才是 Linalg）
• 检查 lowering chain 是否完整：比如 StableHLO → Linalg → Affine → LLVM 是常见路径，但若中间缺 Affine，Linalg 就没法转成带 loop nest 的 IR

最常被忽略的一点：Dialect 选择不是一次性决定，而是一组 lowering pass 的协作结果；单个 pass 可以只关心一种 dialect，但整个 pipeline 必须覆盖从 high-level 到 low-level 的语义鸿沟。