LLVM与C--;从根本上说，LLVM对Haskell来说不比C--好吗？

Question

我很高兴LLVM足够低以模拟任何系统， 并认为苹果公司采用它是有希望的;但是Apple再没有特别支持Haskell;

并且，有些人认为Haskell会更好地使用C--：

  

LLVM'ers还没有解决零开销垃圾收集的问题   并不太令人惊讶。   解决这个问题，同时保持对数据模型的不可知性   这是计算机科学中一个悬而未决的问题。

- LHC won't be using LLVM.

Answer 1

对于操作C--的新代码生成后端工作了一点，我可以说有很多原因可以解释为什么C--比LLVM更好，还有为什么它们实际上并不完全相同的事情。

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

2. 虽然我们正在积极寻求解决这个问题，但LLVM遇到了与via-C后端相同的问题：它需要我们创建 proc点。什么是proc点？本质上，因为Haskell不使用经典的调用/ ret调用约定，所以每当我们将道德等效于子过程调用时，我们需要将一个continuation推入堆栈然后跳转到子过程。这个延续通常是一个本地标签，但LLVM要求它是一个实际的过程，所以我们需要将函数分解成更小的部分（每个部分称为一个过程点）。这对于优化而言是个坏消息，这些优化适用于过程级别。

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

Answer 2

嗯，新南威尔士大学有一个项目将GHC Core翻译成LLVM

请记住：10年前还不清楚LLVM是否会构建C--无法实现的所有基础架构。遗憾的是，LLVM具有可移植的优化代码的基础结构，但不具备高级语言支持的基础结构，C - ha（s）d。

一个有趣的项目是从 C-- ...

定位LLVM

---

更新，截至GHC 7，GHC uses LLVM for code generation。使用-fllvm标志。这改善了一些低级程序的数值性能。否则，性能类似于旧的GCC后端。

Answer 3

GHC现在正式拥有一个LLVM后端，事实证明它是competitive with the GCC and native-codegen and actually faster in some cases。 LLVM项目has accepted the new calling convention David Terei在LLVM上为Haskell创建，令人惊讶的是，这两个项目现在正在合作。

Answer 4

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

GHC在尝试支持多个版本的LLVM时遇到了一些麻烦。 ghc-dev邮件列表中有一个有效的discussion。

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

此外，从历史上看，目前AFAIK，LLVM项目并没有优先考虑提供便携式平台，而且一些开发人员明确指出它is a compiler IR and not a form of portable assembly language。

您为一个目标目标编写的LLVM IR可能根本不适用于不同的预期目标。为了比较，C--网站实际上将其称为便携式装配。 ＆＃34;你会更乐意使用一种便携式汇编语言，它可能是......＆＃34;是来自their website的引用。该网站还提到了一个运行时界面，以简化垃圾收集和异常处理的可移植实现。

因此，您可以将C--视为所有前端的可移植共同点，与CIL和Java字节代码以及LLVM IR有一点共同之处，作为所有后端的表达共同点有助于统一多个目标共有的低级优化。 LLVM IR还提供额外的奖励，LLVM项目将实现许多低级优化。话虽这么说，在某种程度上LLVM IR实际上可以被认为比C--更高，例如LLVM IR有不同的类型，就像在C--一切都只是位向量。