<div dir="ltr"><div>Yep -- It's high past time for a status update. :)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">And would OrcJIT be stablize in version 7.0? Or latter version?</blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="color:rgb(85,85,85);white-space:nowrap">Would MCJIT be removed in source tree,</span></blockquote><div><br></div><div>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.</div><div><br></div><div>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:<br></div><div><br></div><div>(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.</div><div>(2) The behavior of removeModule is bizarre and surprising.</div><div>(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.</div><div>(4) There are many similar, essentially redundant lookup methods: getAddressToGlobalIfAvailable, getPointerToGlobalIfAvailable, getPointerToGlobal, getPointerToFunction, getPointerToFunctionOrStub, getGlobalValueAddress, getFunctionAddress.</div><div><br></div><div>I started writing the LLJIT class as a testing ground for a replacement interface: <a href="http://llvm.org/doxygen/classllvm_1_1orc_1_1LLJIT.html">http://llvm.org/doxygen/classllvm_1_1orc_1_1LLJIT.html</a>. If anyone is interested in experimenting, that is a good place to start.</div><div><br></div><div>Cheers,</div><div>Lang.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Jul 1, 2018 at 5:51 PM Jeremy Lakeman <<a href="mailto:Jeremy.Lakeman@gmail.com" target="_blank">Jeremy.Lakeman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>This hit the list recently;</div><div><br></div>
On 8 June 2018 at 03:42, Lang Hames via llvm-dev<span> </span><span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" style="color:rgb(17,85,204)" target="_blank">llvm-dev@lists.llvm.org</a>></span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Hi Russell,</span><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">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).</div><br class="m_-6772983236966112400m_4076765033226356324gmail-Apple-interchange-newline">
</div></blockquote><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 1 July 2018 at 19:31, 罗勇刚(Yonggang Luo) via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I didn't seen any roadmap and plan about OrcJit & MCJIT.</div><div>And would OrcJIT be stablize in version 7.0? Or latter version?</div><div>Would MCJIT be removed in source tree, when?</div><span class="m_-6772983236966112400m_4076765033226356324HOEnZb"><font color="#888888"><div><br></div>-- <br><div dir="ltr" class="m_-6772983236966112400m_4076765033226356324m_-5201721958826536032gmail_signature"> 此致<br>礼<br>罗勇刚<br>Yours<br> sincerely,<br>Yonggang Luo<br></div></font></span></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div>