llvm dev - Jul 2018 - I've seen OrcJit is under overhaul, and also the MCJIT, so what's the plan?

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?

-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180701/09c05694/attachment.html>

This hit the list recently;

On 8 June 2018 at 03:42, Lang Hames via llvm-dev <llvm-dev at
lists.llvm.org>
wrote:
> Hi Russell,
>
> Sorry for the delayed reply. ORC is currently undergoing some churn while
> I update the API to support concurrent JIT'd code and concurrent
> compilation. This work is almost complete, so updated documentation should
> be landing soon (within a few weeks).
>
>
On 1 July 2018 at 19:31, 罗勇刚(Yonggang Luo) via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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?
>
> --
>          此致
> 礼
> 罗勇刚
> Yours
>     sincerely,
> Yonggang Luo
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180702/83708b2e/attachment.html>

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.


On Sun, Jul 1, 2018 at 5:51 PM Jeremy Lakeman <Jeremy.Lakeman at
gmail.com>
wrote:
> This hit the list recently;
>
> On 8 June 2018 at 03:42, Lang Hames via llvm-dev <llvm-dev at
lists.llvm.org>
>  wrote:
>
>> Hi Russell,
>>
>> Sorry for the delayed reply. ORC is currently undergoing some churn
while
>> I update the API to support concurrent JIT'd code and concurrent
>> compilation. This work is almost complete, so updated documentation
should
>> be landing soon (within a few weeks).
>>
>>
>
> On 1 July 2018 at 19:31, 罗勇刚(Yonggang Luo) via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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?
>>
>> --
>>          此致
>> 礼
>> 罗勇刚
>> Yours
>>     sincerely,
>> Yonggang Luo
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180702/e8b4af24/attachment.html>