Why is llvm considered unsuitable for implementing JIT?

Question

Many dynamic languages ​​implement (or want to implement) a JIT compiler to speed up their execution time. Inevitably, someone from the Peanut Gallery asks why they are not using LLVM. The answer is often: "LLVM is not suitable for creating JIT." (For example, Armin Rigo’s comment is here. )

Why is LLVM unsuitable for creating JIT?

Note. I know that LLVM has its own JIT. If the LLVM was unusable, but is now suitable, say what has changed. I'm not talking about running LLVM Bytecode in LLVM JIT, I'm talking about using LLVM libraries to implement JIT for a dynamic language.

Answer 1

There are some notes about LLVM on the Post-mortem Unladen Swallow blog: http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html .

Unfortunately, LLVM in its current state is indeed designed as a static compiler optimizer and back end. LLVM code generation and optimization is good, but expensive. Optimizations are designed to work with IR generated by static C-like languages. Most of the important optimizations for Python optimization require high-level knowledge of how the program was executed in previous iterations, and LLVM did not help us with this.

Answer 2

Why is LLVM unsuitable for creating JIT?

I wrote HLVM , a high-level virtual machine with a rich static type system, including value types, tail call removal, general printing, C FFI and POSIX with support for both static and JIT compilation. In particular, HLVM offers incredible performance for a high-level virtual machine. I even implemented an ML-like interactive interface with type options and pattern matching using the JIT compiler, as shown in this demonstration of computer algebra . All my work related to HLVM is only a few weeks (and I'm not a computer scientist, but just a dabbler).

I think the results speak for themselves and clearly demonstrate that LLVM is great for compiling JIT.

Answer 3

There is a presentation about using LLVM as a JIT, which mentions the address of many problems related to why its bad, most of it seems to be that people create a static compiler as JIT instead of creating a real JIT.

Answer 4

Update: As of 7/2014, LLVM has added the "Patch Points" feature, which is used to support Polymorphic Inline Caches in Safari FTL JavaScript JIT. This is precisely the case of use complaining about the author’s comment on Armin Rigo in the original question.

Answer 5

Launching takes a lot of time, but it isn’t much if you do what Java does and run in interpreter mode, and use LLVM to compile the most commonly used parts of the program.

In addition, when there are arguments such as scattered across the Internet, Mono has long used LLVM as a JIT compiler (although it is worth noting that by default it uses its own faster, but less efficient backend, and also changes parts of LLVM).

For dynamic languages, LLVM may not be the best tool, because it is designed to optimize system programming languages, such as C and C ++, that are strongly / statically typed and support very low-level functions. In general, the optimization performed in C does not actually make dynamic languages ​​fast because you are simply creating an efficient way to work with a slow system. Modern dynamic JIT languages ​​perform functions such as built-in functions known only at runtime, or optimization depending on which type of variable has most of the time for which LLVM is not intended.

Answer 6

Learn more about LLVM IR here: LLVM IR is an IR compiler .