Others [2] have also found LLVM to be unsuitable as a JIT.
0. https://github.com/Neopallium/llvm-lua
1. http://stackoverflow.com/questions/4077396/llvm-jit-speed-up...
> I think the results speak for themselves and demonstrate unequivocally that LLVM is perfectly suitable for JIT compilation.
That answer is about typed languages. The issue is with dealing with dynamic types. There is a lot more code generated for the JIT to compile.
I didn't really need the JIT feature. But I did add support for it because Lua code can dynamically generate/load more Lua code.
I just found that the runtime overhead (memory and stack space) of LLVM was too high for my needs.
Thanks for the heads up.
The main issues I had with LLVM was the partly do to the memory usage. It can product very good machine code, but the time needed to JIT a block of code was sometimes longer then just running the it in the interpreter.
One of the features I like about Lua the most is the low resource overhead. LLVM was just too big for what I was looking for.
Usage LLVM to JIT/AOT compile Lua code was really just an experiment, something I wanted to try out.
I re-wrote [0] the llvm-lua project with a simple C code-gen backend for compiling Lua code to native code. Which is a bit more useful, since it is easier to cross-compile pure C code, then LLVM bitcode. A lot of the people that tried using llvm-lua wanted to cross-compile Lua code and embed it into an iOS application.