28

我一直对LLVM低到可以对任何系统建模感到兴奋,并认为 Apple 正在采用它。但话又说回来,Apple 并没有特别支持Haskell

而且,有些人认为 Haskell 使用C--会更好:

LLVM'ers 没有解决零开销垃圾收集的问题并不令人惊讶。在不知道数据模型的情况下解决这个问题是计算机科学中的一个悬而未决的问题。

-- LHC 不会使用 LLVM。

4

4 回答 4

29

在对操纵 C-- 的新代码生成后端进行了一些研究之后,我可以说 C-- 比 LLVM 更好的原因有很多,以及为什么它们根本不是一回事。

  1. C——在比 LLVM 更高的抽象层次上运行;例如,我们可以在 C 中生成代码——其中堆栈指针是完全隐式的,并且仅在编译过程的后期才显示出来。这使得应用某些类型的优化变得更加容易,因为更高级别的表示允许更多的代码运动和更少的不变量。

  2. 虽然我们正在积极寻求解决这个问题,但 LLVM 遇到了与 via-C 后端相同的问题:它需要我们创建proc 点。什么是触发点?本质上,因为 Haskell 不使用经典的 call/ret 调用约定,所以每当我们进行子过程调用的道德等价物时,我们需要将延续压入堆栈然后跳转到子过程。这个延续通常是一个本地标签,但 LLVM 要求它是一个实际的过程,所以我们需要将函数分解成更小的部分(每个部分称为 proc 点)。这对于在过程级别起作用的优化来说是个坏消息。

  3. C-- 和 LLVM 采用不同的方法来优化数据流。LLVM 使用带有 phi 节点的传统 SSA 样式:C-- 使用一个名为 Hoopl 的酷框架,它不需要您维护 SSA 不变量。我可以确认:Hoopl 中的编程优化很有趣,尽管某些类型的优化(想到一次性使用的变量的内联)在这种数据流设置中并不是最自然的。

于 2011-04-17T08:30:45.060 回答
22

嗯,UNSW 有一个项目将 GHC Core 翻译成 LLVM

请记住:10 年前还不清楚 LLVM 是否会构建 C 无法构建的所有基础架构。不幸的是,LLVM 具有可移植、优化代码的基础设施,但没有 C-ha(s)d 的良好高级语言支持的基础设施。

一个有趣的项目是从C中定位 LLVM ——...


更新,从 GHC 7 开始,GHC 使用 LLVM 进行代码生成。使用-fllvm旗帜。这提高了一些低级程序的数值性能。否则,性能类似于旧的 GCC 后端。

于 2009-05-03T00:54:57.093 回答
14

GHC 现在正式拥有一个 LLVM 后端,事实证明它可以与 GCC 和 native-codegen 竞争,并且在某些情况下实际上更快。并且 LLVM 项目已经接受了 David Terei 在 LLVM 上为 Haskell 创建的新调用约定,令人惊讶的是,这两个项目现在实际上正在协同工作。

于 2010-03-30T17:42:04.737 回答
1

实践中的一个问题是 LLVM 更像是一个移动目标。

GHC 在尝试支持多个版本的 LLVM 时遇到了一些麻烦。ghc-dev 邮件列表上对此进行了积极讨论。

顺便说一句,目前 ghc 中的 llvm 后端是在将 Haskell 翻译成 cmm 语言之后(我相信这主要是 C——用 STG 语言的某些寄存器扩展),并且由于上述待解决的困难,正在进行冗余优化,这会减慢编译速度。

此外,从历史和目前的 AFAIK 来看,LLVM 项目并不优先考虑提供可移植平台,一些开发人员已经明确表示它是编译器 IR,而不是可移植汇编语言的一种形式

您为一个预期目标编写的 LLVM IR 对于不同的预期目标可能根本没有用。为了比较,C-- 网站实际上将其称为便携式程序集。“你会更喜欢一种可移植的汇编语言,它可能是……”是他们网站上的一句话。该网站还提到了一个运行时接口,以简化垃圾收集和异常处理的可移植实现

因此,您可以将 C 视为所有前端的可移植公共基础,与 CIL 和 Java 字节码和 LLVM IR 有更多共同点,作为所有后端的表达性公共基础,有助于统一低多个目标共有的级优化。LLVM IR 还提供了额外的好处,即 LLVM 项目将实现许多低级优化。话虽如此,在某些方面 LLVM IR 实际上可以被认为比 C 更高级别——例如,LLVM IR 具有不同的类型,而在 C 中——一切都只是位向量。

于 2014-12-02T05:48:00.147 回答