Switch from LLVM JIT to LLVM MCJIT

[dumblob]

The JIT was completely removed in LLVM 3.6 and thus if we want to keep just-in-time compilation, we should count with switching to MCJIT (e.g. on my Arch Linux system, I needed to make a nasty patch and even then it doesn't seem to work flawlessly). It's not a high priority, but I wanted to make a public note about it. Julia switched to MCJIT already about 2 years ago: JuliaLang/julia#3922 (comment) .

To get an impression about JIT and MCJIT differences, read e.g. some older posts from one of the LLVM active developers , e.g. http://blog.llvm.org/2013/07/using-mcjit-with-kaleidoscope-tutorial.html .

[daokoder]

I didn't know they had already deprecated JIT in LLVM, thanks for bring it up. This seems to be the right time to move DaoJIT out of the standard modules.

I will also look into the possibility of using sljit for Dao JIT compiler. sljit is implemented in C, released under BSD, and is quite lightweight, so if the Dao JIT compiler is based on sljit, there will be no problem to include it as a standard module.

[dumblob]

First, yes, I'd definitely move DaoJIT out of the standard modules.

Next, I think it depends on what we expect from the just-in-time engine. LLVM MCJIT is a full-blown engine, which is getting better day by day and nowadays is used in lots of projects and is very fast (and also e.g. cold load got so much improved over the last few years, that it's not any more an issue even for tiny programs). The main advantage of LLVM MCJIT is probably the automation - there is nearly no need to write anything by hand (the optimization done by LLVM is very good - it's hard to beat it by manual optimization in most general cases).

On the other hand, sljit is extremely small, lacking some features (e.g. use of more registers than a small fixed number), but architectured from the very beginning especially for just-in-time compilation. It requires full hand-written instruction code - so there is no automation and there won't be.

Of course, I'd advocate for LLVM MCJIT, because I see JITted Dao running on big servers and running big and huge applications. Such JIT is though not suitable for ultra small embedded devices which under certain circumstances might be a target for JITted Dao. It's worth noting though, that smartphones, watches etc. are already powerfull enough to run the whole LLVM MCJIT with all the megabytes of resulting in-memory code.

[daokoder]

The main advantage of LLVM MCJIT is probably the automation - there is nearly no need to write anything by hand (the optimization done by LLVM is very good - it's hard to beat it by manual optimization in most general cases).

That is one good reason we should use it.

Of course, I'd advocate for LLVM MCJIT, because I see JITted Dao running on big servers and running big and huge applications. Such JIT is though not suitable for ultra small embedded devices which under certain circumstances might be a target for JITted Dao. It's worth noting though, that smartphones, watches etc. are already powerfull enough to run the whole LLVM MCJIT with all the megabytes of resulting in-memory code.

My mentioning of sljit might have given you the impression that I would give up on LLVM MCJIT. But this is not the case. I actually welcome two JIT compilers: one big and powerful, the other small and lightweight. Both will have their own advantages and will be suitable for different applications.

[dumblob]

Speaking about sljit (as means for manual assembly coding and thus as another build-time dependency), we might also adapt a more comprehensive approach - use a full-featured production-ready ASM generator generating multiplatform and multiarchitecture completely-library-independent code. E.g. https://github.com/Maratyszcza/PeachPy from http://www.cc.gatech.edu/grads/m/mdukhan3/ .

[daokoder]

PeachPy looks very interesting, I will keep an eye on it.

[daokoder]

BTW, I have split DaoJIT from this repo, so you are welcome to make the switch from LLVM JIT to LLVM MCJIT. I didn't use fossil for this repo, so we can try git only development on that project:)

[dumblob]

Oh, I missed this possibility to contribute to DaoJIT. I'm currently working on an up to date Docker image (with nightly automated builds) and I'm quite busy, so if anyone feels an urgent need for the JIT compiler, feel free to start with at least updating the current DaoJIT to compile (an old, currently untested patch I found on my HDD follows).

  # LLVM 3.6 changed JIT to MCJIT and added std::unique_ptr<> => wrap pointers
  patch modules/DaoJIT/daoJIT.cpp <<\EOF
@@ -38,7 +38,7 @@
 #include "llvm/IR/Verifier.h"
 #include "llvm/Analysis/Passes.h"
 #include "llvm/Transforms/Scalar.h"
-#include "llvm/ExecutionEngine/JIT.h"
+#include "llvm/ExecutionEngine/MCJIT.h"
 #include "llvm/ExecutionEngine/Interpreter.h"
 #include "llvm/ExecutionEngine/GenericValue.h"
 #include "llvm/Support/raw_ostream.h"
@@ -1137,7 +1137,7 @@
 	daojit_tan_double = Function::Create( mathft, linkage, "tan", llvm_module );
 	daojit_tanh_double = Function::Create( mathft, linkage, "tanh", llvm_module );
 
-	llvm_exe_engine = EngineBuilder( llvm_module ).setEngineKind(EngineKind::JIT).create();
+	llvm_exe_engine = EngineBuilder( std::unique_ptr<llvm::Module>( llvm_module ) ).setEngineKind(EngineKind::JIT).create();
 #if 0
 	llvm_exe_engine->addGlobalMapping( daojit_rand_double, (void*) daojit_rand );
 	llvm_exe_engine->addGlobalMapping( daojit_pow_double, (void*) pow );
EOF

Without any patching the current output is the one posted in daokoder/DaoJIT#1 .