MLIR：面向摩尔定律终结的编译器基础设施

导读

这篇论文介绍 MLIR，一个由 Google 团队开发的编译器基础设施，旨在应对摩尔定律终结后硬件日益多样化、编译器需要针对不同领域（如机器学习）定制中间表示（IR）的挑战。MLIR 的核心做法是提供可复用、可扩展的 IR 框架，让开发者能在此基础上构建领域专用的编译器组件。

HN 关注点：HN 读者多为编译器从业者，讨论焦点是 MLIR 是否真的解决了自建 IR 的痛点，还是过度工程化的方案。

关键词　MLIR编译器SSALLVM

后来怎么样

MLIR 已成为 LLVM 基金会旗下的开源项目，被 TensorFlow、PyTorch 编译栈（IREE、torch-mlir）、Flang 等广泛采用，成为异构硬件和 ML 编译器领域事实上的基础设施标准。

HN 评论精选

这几条评论里：质疑 3　补充 1

质疑MLIR 的可扩展性反而带来 C++ 绑定负担，对 DSL 开发者未必划算

我是 Futhark 语言（https://futhark-lang.org）的开发者，我认为我的语言属于 MLIR 的目标受众。但我仍不确定 MLIR 能解决我面临的困难——恰恰是设计出能表达我所需 pass 的特定 IR。外部约束似乎只会让这项工作更难，我也不相信 MLIR 提供的可复用组件能抵消这一点。不过我可能还是会尝试在编译器中端生成 MLIR，看看是否是个好主意。最让我担心的是，使用 MLIR 似乎要求用 C++ 写编译器。LLVM 可以被非 C++ 语言很好地访问，因为它只是字节码的消费者，但 MLIR 的核心在于 IR 可扩展，这大概需要自定义 C++ 来引入所需的结构。相比之下，编译器很少需要自定义 LLVM pass。

Athas查看英文原文

I'm the developer of a language that I think is in the target audience of MLIR: https://futhark-lang.org I'm still not completely certain MLIR addresses the difficulties I face, which is exactly to design the specific IR that can express the passes I need. Having outside constraints seems like it would just make this work harder, and I'm not sold that the reusable components offered by MLIR offset this. At some point I probably will try generating MLIR from the compiler midend, though, just to see whether it might be a good idea. The thing that concerns me the most might be that using MLIR seems to require writing your compiler in C++. LLVM can be accessed by non-C++ languages just fine, because it's just a consumer of bytecode, but the whole point of MLIR is for the IR to be extensible, and that will presumably require custom C++ to introduce the desired bespoke structures. In comparison, it's rare that a compiler needs custom LLVM passes.

质疑自建 IR 只需 1-2 人 3 个月，MLIR 回答了一个不该问的问题

我从根本上不同意“构建 IR 很难”这个前提。如果你知道怎么做并避免过度设计，这非常容易——平均 1-2 个人花大约 3 个月。这个新的 IR 脚手架看起来刚好足够通用，能处理 Chris 熟悉的东西（C 编译器）和他刚了解的东西（ML）。但：有些编译器的构造需要与 MLIR 根本不同的范式转变，比如 JSC 那些疯狂而美妙的 IR，它们与 MLIR 不兼容；对 ML 来说，自建 IR 可能就够了——3 个月、1-2 个有经验的工程师，你就能得到一个为你的团队量身定制、贴合编码风格、能精准解决特定问题的 IR。反过来说，我很高兴看到位置跟踪是一等公民。这个 IR 的整体结构和其他 Chris 设计的 IR 一样相当合理，也不难 hack，只是它回答了一个本不该问的问题。

pizlonator查看英文原文

I just fundamentally disagree with the premise that it’s hard to build an IR. It’s amazingly easy if you know how to do it and if you avoid overengineering. It takes about 3 months for 1-2 folks on average. This new IR scaffold appears to be just general enough to handle things that Chris understands well (C compilers) and things Chris just learned about (ML). That’s cool but: - there are other compilers that have constructs that require a fundamental paradigm shift compared to MLIR. That’s a good thing. Diversity is cool and shit. One example: the insane and wondeful IRs in JSC, which do things that aren’t compatible with MLIR. - probably for ML it would be fine to just build your own IR. 3 months and 1-2 engineers, assuming they’ve done it before, and you’ll have yourself something purpose built for your larger team to understand, to fit into your coding style, and to surgically attack your particular problem. On the flip side, I’m happy to see that location tracking is first class. The overall structure of this IR, like other IRs that Chris designed, is quite sensible and it seems like it’s not terrible to hack on. It’s just that it’s too much of an answer to a question nobody should be asking.

补充MLIR 的块参数形式类似 SSI，表达力严格强于传统 SSA

> MLIR 不使用 φ 节点，而是采用函数式的 SSA 形式，由终止符将值传入后继块定义的块参数。有人知道这是否等同于（或非常类似）SSI（static single information）形式吗？能在真实编译器中看到这样的东西会很酷，因为它严格强于 SSA。例如 if (x == 0) { f(x); } else { g(x); }，SSA 无法表达“x == 0 仅在第一个分支、x != 0 仅在第二个分支”，而 SSI/函数式形式的自动重命名可以表达这一点，然后记录（现在是流不敏感的）事实 x1 == 0 和 x2 != 0。

tom_mellior查看英文原文

> Instead of using φ nodes, MLIR uses a functional form of SSA where terminators pass values into block arguments defined by the successor block. Does anyone know if this equivalent (or very similar) to SSI (static single information) form? It would be cool to see something like this in a real-world compiler, since it is strictly more powerful than SSA. For example: if (x == 0) { f(x); } else { g(x); } Here SSA doesn't help you express "x == 0, but only in the first branch, and x != 0, but only in the second branch", while with the automatic renaming you get with SSI/"functional form" you can express this as something like (ugly syntax I made up on the spot): if (x == 0) { f(x1); }[x1 = x] else { g(x2); }[x2 = x] and then just record the (now flow-insensitive) facts that x1 == 0 and x2 != 0.

质疑MLIR 可能对 Google 自身场景过拟合，通用性宣称缺乏说服力

我很难相信除了 Google 开发团队自己使用它之外，MLIR 能像摘要宣称的那样好。这些宣称相当夸张，而提供的案例研究也不令人印象深刻（尽管我愿意相信它对 TensorFlow 有用）。特别是，我敢打赌 MLIR 对其目标是过拟合的——这对其他事情都不是问题，除了它声称要成为所有 DSL 和编译器基础设施的更抽象的通用框架。编译器通常有很多中间语言，所以说 Rust 等语言在 LLVM 之上还有一层并不令人惊讶，也没有说服力。

voxl查看英文原文

I have a very hard time believing this will be as good as the abstract claims for anything but what the team at Google who developed this is using it for. The claims are quite extravagant and the case studies supplied were underwhelming (though I am willing to give them the benefit of the doubt that its been useful for tensor flow). In particular, I would bet that MLIR is overfit for it's goal, which is not a problem for anything other than the claim that it's suppose to a more abstract setting for all matters of DSL and compiler infrastructure. Compilers often have many intermediate languages, so saying that Rust and friends have one on top of LLVM is not surprising nor convincing.

历次讨论

2020Hacker News 讨论帖211 分 · 68 评

HN 二十年，最值得读的论文。

朋友分享的书单

专题阅读路线

本周最多人读

我的书单

必读 30 篇

论文库

这些论文是怎么挑出来的

全量扫一遍

只留论文本身

写导读、译评论

MLIR：面向摩尔定律终结的编译器基础设施

导读

后来怎么样

HN 评论精选

相关资源

历次讨论

同领域还值得读

Google 的软件工程（2017）

Peter Naur：编程作为理论构建 (1985)

SciPy 1.0：Python 科学计算的基础算法

Lisp 的历史（1979）

使用 NumPy 进行数组编程

打赏支持

关注向阳乔木