Upgrade to ORCv2

[lum1n0us]

WAMR was used to implement an eager compilation with MCJIT and a lazy compilation with ORCJIT. It leads to a unfriendly maintain case. ORCv2 gives us a good opportunity to improve that.

Here are modifications:

• Use LLJIT to implement an eager compilation. It will perform on symbol LLVMOrcLLJITLookup. LLJIT compiles all functions in the target LLVMModuleRef.
• Use LLLazyJIT to implement a lazy compilation. There is a CompileOnDemandLayer allowing LLLazyJIT compiling a function only when actually calling it.
• Lazy call through provides a function stubs for every function. LLVMOrcLLLazyJITLookup will return the stub. It means once aot_loader fills the func_ptrs with results of LLVMORCXXXJITLookup, there is no necessary to assume meeting a NULL function pointer when dealing with call and call_indirect.
• Since lib/ExecutionEngine/Orc/OrcV2CBindings.cpp only including LLJIT staff, need to create binds for LLLazyJIT.

[lum1n0us]

• Remove MCJIT related form the main branch
• Investigate CompileOnDemandLayer and JITLink

[wenyongh]

In current implementation (#1450 and #1456), we mainly did the some modifications:

• Removed the MCJIT, replaced it with ORC JIT eager mode
• Removed the legacy pass manager (only the new pass manager was kept)
• Changed the lazy mode's LLVM module/function binding: change each function in an individual LLVM module to all functions in a single LLVM module
• Removed the backend threads to pre-compile wasm functions as much as possible
• Upgraded ORC JIT to ORCv2 JIT to enable lazy compilation

Most of the modifications work good, an issue is that removing backend pre-compilation threads may impact the compilation time a lot when the system resources are sufficient, for example, in Ubuntu x86-64, normally we can create some threads to pre-compile the wasm functions into JIT functions so as to decrease the total compilation time. As the LLLazyJIT "function bodies in that module will not be compiled until they are first called", we cannot get wasm function compiled when looking up the JIT function address (it is a stub).

A solution is to use the setPartitionFunction: add wrapper functions (with empty body) for each JIT function, and let the backend thread call the wrapper function to compile it, and when compiling, the callback PartitionFunction is called, we can implement our PartitionFunction to add the actual JIT function (by parsing the function name) the to-be-compiled function list.

Experiments show that by the way can decrease the compilation time a lot, but not as much as the original mode (ORC lazy JIT, each function with a LLVM module, legacy pass manager). There may be some reasons:

• Using LLVM new pass manager requires more compilation time
• Looking up all function addresses previously in a single thread, we may get them with multiple threads
• Using direct mode to call a function, calling other functions with LLVM function may increase the dependencies for compilation, we may replace it with indirect mode: lookup the function pointer from module->func_ptrs array

We can also disable the LLVM module verification for JIT mode.