我无法充分赞扬LLVM。与我看过的其他编译器项目相比,它非常容易使用。虽然我不是编译器专家,但当我对LLVM或clang的某些限制感到沮丧时,通常很容易深入研究并进行更改。
我(Nate Begeman、我自己和其他几个人)没有真正的编译器设计经验,但我们用几周的业余时间编写了PPC后端,因为它看起来足够简单,即使非专家也可以接近。我们对PPC汇编语言相当熟悉,但我们仍然惊讶于我们能在几周的空闲时间内让LLVM-gcc输出PPC代码。这绝对是我编译的最令人满意的Hello World之一。
我已经玩弄LLVM很长时间了。我写了两篇OCaml Journal文章,介绍如何使用OCaml编程语言来使用LLVM。这非常有趣,因为OCaml语言非常适合编写编译器,并且具有许多强大而成熟的用于解析等操作的工具和库。
总体而言,我的经验非常积极。LLVM做到了它所说的,并且非常易于使用。生成代码的性能非常优秀。我写的其中一个程序是一个简单的Brainf\*ck编译器,它生成的可执行文件比我测试过的任何编译器都要快(包括GCC)。
我只有两个抱怨LLVM的地方。首先,每当出现问题时,它都会使用abort()而不是引发异常。这是其作者有意设计的决策,他们正在努力删除LLVM中所有的异常使用,但这使得在尝试调试使用LLVM的编译器时,无法从OCaml中获取回溯:您的程序只会以文本说明从LLVM中死亡,但无法知道错误发生在源代码的哪个位置。其次,LLVM的编译库非常庞大(20Mb)。我认为这是由于C++所导致的膨胀,但它使得编译过程非常缓慢。
编辑:我的LLVM工作最终在创建高性能、高级别垃圾收集虚拟机中达到高潮。可免费下载此处并查看相应的基准测试(哇!)。@Alex:我将尽快在某个地方上传那个BF编译器。
我已经初步尝试了LLVM,并通过this tutorial进行了一些工作,这让我对它的潜力非常兴奋;我可以相对轻松地将其用于构建应用程序中的JIT,这让我感到非常兴奋。
我还没有深入研究它的限制、稳定性、性能等方面,因此无法提供任何有用的意见。我知道它在所有方面都很好,但这纯粹是道听途说。