LLVM 编译器在现代计算机语言中是必不可少，但早在 2000 年，LLVM（低级虚拟机）才刚刚起步，作为一种思考如何克服 Java 虚拟机缺点的新方法。当时，克里斯·拉特纳 (Chris Lattner) 是伊利诺伊大学 Vikram Adve 的研究生。

“Java 正在接管世界。这真的很令人兴奋。没有人知道 Java 的界限。我们中的一些人对可能不适合它的那种工作负载有一些担忧。但是编译的故事还很早。即时编译器刚刚出现，”Lattner 回忆道。

上个月参加 SC21 的炉边谈话时，Lattner 漫步在记忆中，谈到了LLVM如何 从他 2000 年在伊利诺伊大学厄巴纳-香槟分校的硕士论文项目发展成为一个广泛的社区。他还讨论了 LLVM 的未来、他在Swift和MLIR 方面的工作，以及在开源社区工作的回报和挑战。美国能源部高级科学计算研究办公室的 Hal Finkel 是采访者。

“Vikram 和我有一个想法，如果我们采用这种即时编译器技术，但进行更多的提前编译，我们可以在整个程序优化分析方面获得更好的权衡，[并且]构建分析工具，并获得更好的性能。LLVM（低级虚拟机）这个名称很多都来自于采用 Java 虚拟机并在其下构建一些东西的想法，这是一个您可以对其进行整个程序优化的平台，”Lattner 说。

“在构建了一大堆基础设施并学习了所有这些编译器的东西之后，我只是吃饱了，只是喜欢边做边学，我们实际上最终说，好吧，我们构建一个代码生成器怎么样？我们如何与GCC（GNU Compiler Collection）集成。在很早的时候，它开始是作为 Java 的东西，最终成为面向 C 和静态编译的工具语言作为最初的焦点。但它成为了一个非常有用的平台，可用于大量不同领域的研究和应用。”

当然，Lattner 对编程世界并不陌生。他在 LLVM、Clang 和 Swift 方面的大部分工作都是在他在 Apple 期间完成的。Lattner 还在特斯拉领导其自动驾驶团队短暂工作过。他目前是开发 RISC-V 处理器的SiFive平台工程高级副总裁。

这里展示的是 Lattner 对他在 LLVM 社区的工作及其未来的一些评论（略有编辑），点击标题见原文。

在 Apple 的时光： “你不明白……没有什么能取代 GCC”

当 Lattner 于 2005 年从伊利诺伊大学毕业时，LLVM 仍然是一个高级研究项目。Apple 一直在 GCC 上投入大量资金，我不知道当时是 GCC 技术还是 Apple 的 GCC 团队，但管理层对缺乏进展感到非常沮丧。我与这位认为编译器很有趣的 VP 进行了交谈，他决定给我一个机会。他雇用了我并说，好的，你可以在这个 LLVM 上工作；话语后面隐藏着最坏的情况是，你是个聪明人，我们可以让你在 GCC 上工作。

上任几周后，Lattner 记得曾被一位经验丰富的 Apple 工程师质疑：GCC 已经存在 20 年了，有数百人在研究它，没有什么能取代 GCC，你在浪费时间。Lattner 说：好吧，我不知道，我玩得很开心。

事实证明，图形领域非常需要即时编译器，而 LLVM 是一个很好的解决方案。

OpenGL 团队一直在苦苦挣扎，因为 Apple [正在] 推出 64 位 Mac，并从 PowerPC 转移到 Intel，以及一堆这样的东西。他们使用的是手工制作的即时编译器，而我们能够使用 LLVM 来解决他们的一系列问题，例如启用新硬件 [这] 不是 GCC 设计用来做的事情。

所以 [LLVM 的部分] 随10.4 Tiger 版本（2007）一起提供，提高了图形性能。这显示了一些价值并证明了一些投资是合理的。

GPU 团队试图为通用 GPU 计算制作一种着色语言，[然后] 变成了我们现在所知的OpenCL，并成为Clang的第一个用户。

合作的风险和回报——“是时候离开了。”

看看 LLVM 社区，你有英特尔、AMD、苹果、谷歌和索尼以及所有这些正在合作的人。我们让 [它发挥作用] 的方式之一是受到卓越技术和共同价值观的推动，以及对成功的共同理解。

作为一个社区，我们总是通过工程师对工程师来解决问题。例如，对我来说，当我在 Apple 或任何附属机构时，在与社区合作时我会戴上我的 LLVM 帽子，但我会戴上我的 Apple 帽子来解决未发货硬件的内部问题， 对。我们决定我们许多人所戴的公司帽子不会成为 LLVM 社区的一部分。这不是要提出一个话题，比如我现在需要安装这个补丁才能发布。通过吸引志同道合的合作者，共同理解有助于为 LLVM 社区的发展提供信息。

事情并不总是那么顺利。

多年来，我们不得不将人们逐出社区，这种情况并不常见。当人们决定他们不符合价值体系 [或] 他们不愿意与人合作或者他们不符合社区的发展方向时。这非常困难，因为他们中的一些人是多产的贡献者，而且确实很痛苦，但保持社区凝聚力 [和] 价值体系非常重要

LLVM Warts & Redo – 从头开始​​是个好主意吗？

“我是 LLVM 最大的批评者，因为我知道所有的问题，”Lattner 半开玩笑地说，并指出 LLVM 现在已经 20 多年了。“LLVM 绝对是一件好事，但无论如何它都不是一件完美的事情。我真的很高兴多年来我们能够在 LLVM 上不断升级、迭代和改进。但是现在到了关键点，某些更改是架构上的，并且很难进行。

其中一个例子是 LLVM 编译器本身不是内部多线程的。LLVM 在循环转换、HPC 风格的转换、自动并行化、OpenMP 支持方面从未非常出色。LLVM 有效并且非常有用，但它可能会好得多。这些 [弱点] 都可以追溯到 LLVM 中的设计决策，其中 LLVM 的世界观实际上是一种带有向量的 C 世界观。原始设计前提阻碍了某些类型的进化。

当您以并非真正设计使用的方式使用 LLVM 时，它会很慢。例如， 例如，Rust社区以推动LLVM性能的极限而闻名，因为他们的编译模型实例化了成吨成吨的东西，然后对其进行专门化，专门化，专门化。这给编译器带来了巨大的压力和负担，这是C语言或更简单的低级语言所没有的。这在Rust社区中导致了惊人的事情，但它要求编译器做所有这些工作，而这些工作是隐含在这个编程模型中的。

让 LLVM 变得更好——在谷歌时，Lattner 解决了

MILR 是 LLVM 中的一个子项目，旨在帮助其提供更现代的功能。Lattner 从 Apple 转到 Google，在那里他从事 MLIR 的工作。

TensorFlow它确实是一套编译器技术。它有 TensorFlow 图。它有这个带有 HLO 图的 XLA 编译器框架。它可以为 CPU 和 GPU 生成代码。它还有许多其他技术组件，例如 TensorFlow Lite，这是一个完全独立的机器学习框架，带有来回转换器。

TensorFlow 拥有如此庞大的基础设施，一个包含“七到八个不同 IR”的生态系统。没有人像编译器 IR 那样构建它们。人们将 TensorFlow 图视为协议缓冲区，而不是 IR 表示。结果，周围的质量不是很好，结果是没有什么能被真正集成的。不同系统之间存在所有这些不同的技术孤岛。人们无法相互交谈，因为他们不明白他们都在空间的不同部分解决相同的问题。

MLIR 源于这样一种想法：如何整合这些完全不同的世界，在这些世界中：你正在开发一个巨大的多节点机器学习加速器，比如 GPU，而我正在开发一个 Arm TensorFlow轻量级移动部署场景。它们之间没有共同点。

构建编译器有一个困难的部分：与领域无关。如果你看一下像LLVM这样的编译器，LLVM的很大一部分，是所有这些基础设施，用于测试，用于调试信息，用于行走图，用于构建控制流图，用于定义调用图，或对通行证管理器进行分析–所有这些东西都是通用的，无论你是构建一个CPU JIT编译器还是构建一个TensorFlow图式表示。编译器基础设施上的表示法对你的目标领域是不变的。

MLIR 是一个独立于领域的编译器基础设施，允许您在顶部构建特定于领域的垂直领域。它提供了定义你的 IR、你的表示的能力，比如你的加、减、乘、除、存储。你有哪些核心抽象？例如，在软件中，您拥有功能。在硬件方面，您有 Verilog 模块。MILR 可以做到这两点。

Lattner 表示，他不仅很高兴看到 MLIR 被整个行业采用，特别是在机器学习类应用中，而且在量子计算等新领域也被采用。“在 SiFive，我们将它用于硬件设计和芯片设计类型的问题——任何地方都可以从编译器能够表示设计中受益，”他说。

点击标题见原文。