Compiler construction open64与llvm编译器之间的差异

有人能指出open64和llvm之间的区别吗

我知道open64使用了whirl IR，它有5个阶段，而且差异很大，因为每个阶段都会显著降低机器的代码，而llvm有一个IR，用于中级优化，后来被降低为目标独立指令（DAG）和依赖指令

1）旋风也是SSA，
2）它是否使用虚拟寄存器，
3）open64是否具有类似llvm的模块化设计，
4）开发pass并将其插入工具链是否容易

这两种编译器都擅长中级过程间优化和转换，但
5）open64是否支持JITting或框架中内置的任何类型的动态翻译

看起来CG的质量在这两种情况下或多或少是相似的。
6）前端如何？是否可以使用pragmas轻松扩展前端或绑定新的前端，而无需修改Whirl IR（这就是SUIF的问题）

据我所知，open64广泛应用于许多商业和学术项目（UPC、AMD、Nvidia、Tensilica），但它似乎有许多分支（在2003年后不断发展），每个分支都有自己的特点和局限性。此外，没有固定的开发人员社区和环境或支持，与llvm相比，文档几乎不存在，而且编译器的发展方向也不简单

在许可方面也存在差异，llvm更符合BSD许可风格，open64基于GPL。

Q:whirl也是SSA吗 答：没有，但Open64有SSA管理器 答：没有，但Path64今年要么采用SSA管理器方法，要么将所有优化转换为SSA感知

问：它使用虚拟寄存器吗 答：在Path64/Open64中，直到cg阶段才进行最终寄存器分配

问：它有像llvm那样的模块化设计吗 答：（取决于意见，我有偏见）每个阶段都有明确的划分，所以它在某种程度上是模块化的，但与llvm不同。请注意，在这一点上，我怀疑您是否可以关闭llvm中的某些东西而不会产生太多的影响。因此，从研究人员的角度来看，隔离测试单一类型的优化可能/可能并不容易

Q：开发pass并将其插入工具链容易吗？ 答：是/否-LLVM在文档方面取得了成功，但Path64正在进行这方面的工作。有些代码比其他代码更容易跳转。如果您对编译器完全陌生，那么使用LLVM进行前端工作或源代码到源代码。如果您有经验并希望开发更高级的优化路径64git://github.com/path64/compiler.git 这是我推荐的

问：open64支持JITting吗？ A:没有，但你为什么要它？Path64在静态编译方面最强，并且花费20万个周期来JIT某些字节码几乎没有意义

问：前端呢？ 答：clang将是llvm-2.10中的默认值，但在此之前，它们都使用gcc前端。有一个非公共的项目要做。这使他们两人又回到了平等的基础上

小修正-LLVM IR与CG IR更具可比性，而不是真正的中级旋转。 在这两种情况下，CG的质量或多或少是相似的。 我会说这是一个完全错误的假设，我不会评论哪一个更好，但会说它们有本质上的不同

此外，没有固定的开发人员社区和环境或支持

#pathscale-irc.freenode.net（我们还有邮件列表，您的问题将得到解答）

在内部，许多公司都有良好的文档，但通常不会根据需要共享或提供。（我是irc的codestr0m，很可能可以分享我们在这方面取得的进展）

编译器前进的一个方向

对我们来说，只有一个方向，我们正努力围绕这个方向建立一个社区

在授权方面也存在差异，llvm更符合BSD授权风格，而open64基于GPL

对不起，我不是律师，只要不妨碍我，我就不在乎许可证问题