总结与未来趋势

十八篇的系列到此结束。这一篇不写新的 API 或方言——回到开始时的宏观视角，总结 MLIR 改变了什么、没改变什么，然后看编译器工程的下一步方向。

一、MLIR 改变了什么

回顾本系列的核心主张：

1. 编译器基础设施从”产品”变成了”平台”

LLVM 时代，编译器基础设施是一件产品——LLVM 提供了 IR、Pass 管线、代码生成后端，用户要么接受它的边界（LLVM IR 的抽象层级），要么自己另起炉灶（Halide、TVM、XLA）。

MLIR 改变了这个关系：它不提供”一个 IR”，它提供”构建 IR 的框架”。用户设计自己的方言、自己的降阶路径——但共享底层的基础设施（Pass 管理、模式重写、TableGen、验证器、打印机/解析器、Location 追踪）。这是从”卖成品”到”卖工具箱”的范式转移。

2. 渐进降阶让编译器变成”可观察的分层过程”

传统编译器的降阶是一次性黑箱——源码进去，目标代码出来。中间的 Pass 是串在一起的，但不同抽象层之间没有可见的边界。

MLIR 的渐进降阶把编译分解为显式的分层步骤——每步从一种方言降到另一种，每步的输出都可以用 mlir-opt 观察、验证、调试。这对编译器开发者的影响是深远的：调试一个 tiling 问题可以精确到是 linalg 层的 tile 大小错了，还是 affine 层的依赖分析错了。

3. 多方言混合让”异构”成为常态

在单一 IR 的编译器中，混合不同抽象层级的语义意味着复杂的元数据和注释。MLIR 让不同方言的 Op 可以共存于同一个 Module——“高层 tensor 还在，但旁边的循环已经降到 scf 了”——这是自然的，不是特例。

二、MLIR 没有改变什么

同样重要的限制：

1. 编译器工程的核心问题仍然是”语义设计”

ODS 与共享基础设施显著减少了 Pass 管理、打印/解析等样板代码，但语义设计仍是编译器工程师的核心任务：

• 方言的 Op 粒度应该多粗？（linalg.matmul vs linalg.generic 之间的选择）
• 降阶应该在哪个方言层做哪些优化？（tiling 在 linalg 还是 affine？）
• 方言之间的接口应该多抽象？（直接依赖 vs. Interface 注册？）

这些问题没有算法自动回答，编译器工程师的经验和判断仍然不可替代。

2. 调试复杂度没有消失，只是转移了

多方言、多 Pass 的编译管线让”为什么我的 Pass 不工作”变得更难回答——问题可能发生在任意一个方言层，表现形式可能在完全不同的另一层。工具箱（--mlir-print-ir-after-all、--crash-reproducer、diff）只能帮助你定位，不能替你诊断。

3. MLIR 不能替代 LLVM

MLIR 的 llvm 方言最终要翻译为 LLVM IR，经过 LLVM 的优化管线和代码生成器才能变成机器码。MLIR 的价值在 LLVM 之上的抽象层——但底层的指令选择、寄存器分配、指令调度仍然是 LLVM 的领地。

三、MLIR 2.0 规划

以下条目来自 MLIR 社区在 2024–2025 年的公开讨论（B 级：论坛帖子、开发者会议议题），非已发布的产品路线图。具体时间表以 LLVM 官方声明为准。

方言版本化与稳定承诺：当前 MLIR 的方言 API 频繁变化，对下游项目产生了维护负担。MLIR 2.0 计划引入方言的版本化机制——StableHLO 的稳定化经验正在被推广到其他方言。

Transform 方言的成熟：Transform 方言（MLIR 社区的”schedule language”）允许用户在 IR 中描述”对这个 linalg.generic 做 tiling，大小 32×32”——不需要写 C++ Pass。这个机制在 MLIR 2.0 中被定位为优化策略的主要表达方式，替代大量手写 Pass。

模块化构建与分发：当前的 MLIR 是 LLVM 的一部分，构建和分发与 LLVM 耦合紧密。MLIR 2.0 计划支持独立构建的方言库——一个下游项目可能只需要 linalg + scf + arith，而不需要 LLVM 的完整目标后端。

PDA（Pattern Description Algebra）：一种声明式的模式描述语言，可以表达比当前 RewritePattern 更复杂的变换——比如”将连续的 element-wise + reduction 融合为单个 generic”。PDA 正在从研究阶段进入 MLIR 的影响范围。

四、AI 生成编译器：LLM + 编译器合成

大型语言模型（LLM）在代码生成上的突破引发了一个自然问题：能否用 AI 来自动生成编译器 Pass？

有几条路线正在被探索：

路线 1：LLM 辅助 Pass 编写——LLM 从自然语言需求生成 MLIR C++ Pass 代码。

工程判断（依据：现有 LLM 代码生成评测与社区实践）：对简单 RewritePattern 有一定辅助价值，但对 tiling + fusion + bufferization 等多 Pass 协调缺乏可靠的全局理解。

路线 2：AI 搜索优化空间——给定一个 linalg.generic 和硬件特征，AI 搜索最优的 tile 大小、fusion 策略、vectorization 方向。

较有证据支撑：TVM AutoTVM / AutoScheduler [Chen et al., OSDI 2018] 与 CompilerGym [Cummins et al., CGO 2022] 已证明搜索式编译优化的可行性；MLIR Transform 方言为同类方法提供了更结构化的搜索空间。

路线 3：完全 AI 生成的编译器——AI 从零设计方言、Pass 和降阶路径。

工程判断：编译器正确性要求极高，当前 LLM 可靠性不足以支撑生产级端到端生成；更现实的定位是研究辅助工具，而非替代编译器工程师。

Pitfall：最大的风险不是”AI 写出错误代码”，而是”AI 写出的代码看起来对但实际上有微妙的语义错误”。编译器的 bug 比应用的 bug 更难发现——因为它们表现为”目标程序产生错误结果”，而不是编译器本身 crash。在编译器中使用 AI 生成组件需要更强的验证机制。

五、编译器工程的开放问题

MLIR 解决了”一个 IR 不够用”的问题，但留下了更深层的问题：

方言碎片化风险：MLIR 的成功意味着更多人会设计方言。如果每个公司都设计自己的”内部方言”，而不共享方言语义和降阶路径，这个碎片化的局面可能比没有 MLIR 时更糟糕。

DSCO（Domain-Specific Compiler Optimization，领域专用编译优化）：MLIR 让设计方言变容易了，但”为特定方言设计优化”仍然是手工工艺。Transform 方言和自动调度（AutoScheduler）正在尝试减少这部分的体力劳动。

可验证的编译器正确性：编译优化的正确性验证（Translation Validation）——证明优化前后的 IR 在语义上等价——是一个理论成熟但实践稀缺的技术。MLIR 的方言转换框架为做形式化验证提供了更清晰的接口（每步转换的输入/输出方言、类型映射规则都是明确定义的），但目前还没有成熟的工具。

异构内存管理：MLIR 的 memref 可以表示多地址空间，bufferization 可以处理 tensor→memref 的降阶——但”哪些 tensor 应放在哪种内存中（GPU global vs. shared vs. register）“的决策现在仍是手动的（通过 Transform 方言或固定配置）。自动内存层次优化是一个待解决问题。

六、本系列的承诺兑现

这个系列承诺的交付总结：

七、推荐后续学习路径

取决于你的身份和目标：

编译器工程师：深入第 04-10 章（C++ API + Pass + Pattern + Dialect Conversion），然后用第 15 章的模式构建自己的方言和降阶管线。

AI 框架开发者：重点看第 11-14 章（Tensor/Linalg + Affine/SCF + GPU + 框架桥接），理解从计算图到底层代码的完整降阶路径。

学生 / 学习者：第 01-03 章建立直觉，第 04-07 章理解核心数据结构，第 15 章动手实践。

学术研究者：第 01-02 章理解 MLIR 的设计空间，第 18 章了解当前开放问题，然后聚焦你的研究领域相关的方言。

八、致谢

本系列的核心参考：MLIR 论文（Lattner et al., 2020）、MLIR 官方文档、LLVM 项目源码、IREE 项目文档，以及 MLIR 社区在论坛和 GitHub Issues 中的数千次讨论。

任何技术错误都是我的问题，任何有价值的分析都来自 MLIR 和 LLVM 社区二十年的编译器工程积累。

本系列全部文章在 GitHub 上公开源文件，欢迎通过 Issue 或 PR 反馈勘误、补充和讨论。

参考资料

论文（A 级）

• Lattner, C. et al. MLIR: A Compiler Infrastructure for the End of Moore’s Law. arXiv:2002.11054, 2020.
• Cummins, C. et al. CompilerGym: Robust, Performant Compiler Optimization Environments for AI Research. CGO 2022.（AI + 编译器优化的基准平台）

社区资源（B 级）

• MLIR 社区论坛 — https://discourse.llvm.org/c/mlir/
• LLVM Developers’ Meeting 历年关于 MLIR 的演讲
• IREE 设计文档 — https://iree.dev/developers/design-docs/