为什么llvm被认为不适合实施JIT？
许多dynamic语言实现（或想要实现）JIT编译器，以加快执行时间。 不可避免的是，花生画廊的人问他们为什么不使用LLVM。 答案往往是“LLVM不适合build立JIT”。 （例如，Armin Rigo 在这里的评论。 ）
为什么LLVM不适合build立JIT？
注意：我知道LLVM有自己的JIT。 如果LLVM过去不合适，但现在适合，请说出是什么改变了。 我没有谈论在LLVM JIT上运行LLVM Bytecode，我正在讨论使用LLVM库来实现dynamic语言的JIT。
有关Unladen Swallow死后博客文章中关于LLVM的一些说明： http ： //qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html 。
不幸的是，当前状态下的LLVM实际上被devise为静态编译器优化器和后端。 LLVM代码生成和优化是好的，但是很昂贵。 这些优化都是为静态C语言生成的IR而devise的。 大多数优化Python的重要优化需要高层知道程序如何在以前的迭代中执行，LLVM并没有帮助我们做到这一点。
为什么LLVM不适合build立JIT？
我写了一个高级虚拟机HLVM ，它是一个丰富的静态types系统，包括值types，尾调用消除，通用打印，C FFI和POSIX线程，支持静态和JIT编译。 特别是，HLVM为高级VM提供了难以置信的性能 。 我甚至使用JIT编译器实现了一个类似于ML的交互式前端，其变体types和模式匹配，就像这个计算机代数演示中所看到的那样 。 我所有的HLVM相关的工作总计只有几个星期的工作（我不是一个计算机科学家，只是一个涉足）。
我认为这个结果能够说明问题，并明确地certificateLLVM 完全适合于JIT编译。
有一个关于如何使用LLVM作为JIT的介绍，其中提到了许多关于为什么它的坏处，似乎归结为人们将静态编译器构build为JIT而不是构build实际JIT的问题。
更新：截至2014年7月，LLVM添加了一个名为“补丁点”的function，用于支持Safari的FTL JavaScript JIT中的多态在线caching。 这完全涵盖了对int Armin Rigo对原始问题的评论抱怨的用例。
启动起来需要很长时间才是最大的抱怨 – 但是，如果你做了Java的工作并以解释器模式启动，并且使用LLVM来编译程序中最常用的部分，那么这不是一个大问题。
另外，虽然有这样的争论散布在整个互联网上，但是Mono已经成功地将LLVM作为JIT编译器使用了一段时间（尽pipe值得注意的是，它默认自己的速度更快但后台效率更低，并且还修改了部分LLVM）。
对于dynamic语言，LLVM可能不是正确的工具，仅仅是因为它被devise用于优化诸如强制/静态types的C和C ++之类的系统编程语言并且支持非常低级别的特征。 一般来说，在C上执行的优化并不能真正使dynamic语言快速，因为您只是创build一个运行缓慢系统的有效方法。 现代dynamic语言JIT可以执行诸如只在运行时才知道的内联函数，或者根据大多数时间内哪种types的variables进行优化，而不是为其deviseLLVM。
有关LLVM IR的更多详细信息，请参阅： LLVM IR是编译器IR 。
