haskell - LLVM 与 C-- ；对于 Haskell，LLVM 从根本上怎么可能不比 C 更好——？

Question

我对 LLVM 感到很兴奋足够低以模拟任何系统，
并认为苹果正在采用它是有希望的；但话又说回来，Apple 并不专门支持 Haskell ;

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

That LLVM'ers haven't solved the problem of zero-overhead garbage collection isn't too surprising. Solving this while staying agnostic of the data model is an open question in computer science.

-- LHC won't be using LLVM.

Answer 1

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

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

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

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