I didn’t seen any roadmap and plan about OrcJit & MCJIT.
And would OrcJIT be stablize in version 7.0? Or latter version?
Would MCJIT be removed in source tree, when?
This hit the list recently;
Yep – It’s high past time for a status update. 
ORC is undergoing a major redesign to support concurrent compilation within the JIT, and enable improvements to the C API. The design for the multithreading support is experimental, so it has been difficult to lay out a road map or timeline. The work has just passed a key milestone though: New versions of each of the in-tree ORC layers have been written, including the CompileOnDemandLayer. Together these layers have been able to successfully lazily JIT code (including multithreaded code) on multiple threads. They have also been used to write the new LLJIT class (see include/ExecutionEngine/Orc/LLJIT.h) which has replaced the OrcLazyJIT in lli, and now passes the existing OrcLazy regression tests.
I am probably still a few weeks out from being able to re-write the Kaleidoscope tutorials: these use the ‘removeModule’ API, and I am still trying to work out how to deal with that in the new multithreaded API. Documentation is coming though.
And would OrcJIT be stablize in version 7.0? Or latter version?
It will not be stable by 7.0: that is branching in less than one month. I would like to see the ORC API become more stable, but how long that takes will depend on how well people think the new APIs work. If people find they work well then we can focus on stabilization and polish. If people run in to issues with them I will need to spend more time to figure out the right design.
Would MCJIT be removed in source tree,
There is no specific timeline for removing MCJIT. Instead, it will depend on ORC becoming a satisfactory replacement for existing MCJIT clients. I see removal of MCJIT as a two step process: First, once OrcMCJITReplacement is bug-for-bug compatible with MCJIT, we can make it the default ExecutionEngine implementation. Once we have verified that that does not break any existing clients we can delete MCJIT. The ultimate goal however is to delete (or fix) ExecutionEngine and delete OrcMCJITReplacement. For that to happen we need people to actually switch APIs. I think some people will switch to ORC because they want some of the advanced features, but I also think we need a simple black box interface (along the lines of ExecutionEngine) for clients who do not need advanced features.
On that note, if anyone would like to volunteer their thoughts on what a replacement ExecutionEngine interface should look like I would be very interested to hear them. A few of my personal gripes are:
(1) ExecutionEngine’s interface is the union of the functionality provided by the IR interpreter and MCJIT. You have to know what underlying implementation you are using to know which methods can be safely called.
(2) The behavior of removeModule is bizarre and surprising.
(3) Some of the APIs are written in terms of operations on LLVM IR objects (e.g. getPointerToGlobal(GlobalValue*)), but this requires you to keep IR around just for the sake of making queries.
(4) There are many similar, essentially redundant lookup methods: getAddressToGlobalIfAvailable, getPointerToGlobalIfAvailable, getPointerToGlobal, getPointerToFunction, getPointerToFunctionOrStub, getGlobalValueAddress, getFunctionAddress.
I started writing the LLJIT class as a testing ground for a replacement interface: http://llvm.org/doxygen/classllvm_1_1orc_1_1LLJIT.html. If anyone is interested in experimenting, that is a good place to start.
Cheers,
Lang.