<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi All,<div><br></div><div>I'm back again after a couple of weeks hiatus, and I have some good news for anyone interested in cross-process JITing with OrcV2: The remote TargetProcessControl and Orc library breakup patch has landed in 1d0676b54c4 [1]. Thanks very much to Dave Blaikie and Stefan Graenitz for all their feedback on the review!</div><div><br></div><div>As described in my last email, this commit breaks the OrcJIT library into three pieces:</div><div>- OrcJIT retains the bulk of the code.</div><div>- OrcTargetProcess contains code only needed by JIT execution processes, and depends only on Support.</div><div>- OrcShared contains code required by both of these libraries -- mostly RPC and error types.</div><div><br></div><div>For OrcV2 users who are running JIT'd code in-process the only essential change is that you will need to link against OrcTargetProcess library as well as OrcJIT. For users who want to JIT across processes/targets this library break-up means that your target process only needs to link against OrcTargetProcess, not LLVM's core or object libraries. </div><div><br></div><div>This patch also introduces a pair of classes, OrcRPCTargetProcessControl and OrcRPCTPCServer, that enable Orc-RPC based out-of-process execution. These classes serve two purposes: As an example of how to build cross-process TargetProcessControl implementations (for anyone who wants to build their own based on other XPC/IPC systems), and as a way to write regression tests for out-of-process execution without introducing new dependencies into LLVM.</div><div><br></div><div>Anyone looking to try out the new APIs should check out llvm-jitlink, which has been updated to optionally use these new classes (see [2] for example usage). Once the API for OrcRPCTargetProcessControl settles down I plan to re-introduce Chapter 5 of the Building A JIT tutorial series to provide an introductory example for these APIs.</div><div><br></div><div>The next step for Orc, required for both cross-process support and new features, is a runtime library. The runtime should be loadable via the JIT like any other static library, provide support for JIT re-entry (eventually replacing the existing Orc-ABI reentry code), thread locals, eh-frame and language runtime registration, execution of initializers, and more. I've started a prototype of a runtime as a library within compiler-rt in the orc-runtime-prototype branch of my llvm fork [3]. There's not much there yet, but I will keep you updated on my progress, and any questions, comments, or PRs are very welcome.</div><div><br></div><div>Finally: I've added a skeleton roadmap to the OrcV2 design document [4], and plan to keep improving the documentation. I'd love to hear any specific requests you have for documentation improvements, as this will help me focus my efforts in this area. </div><div><br></div><div>-- Lang.</div><div><br></div><div>[1] <a href="https://reviews.llvm.org/D90132">https://reviews.llvm.org/D90132</a></div><div>[2] <a href="http://lists.llvm.org/pipermail/llvm-dev/2020-September/145070.html">http://lists.llvm.org/pipermail/llvm-dev/2020-September/145070.html</a></div><div>[3] <a href="https://github.com/lhames/llvm-project/tree/orc-runtime-prototype">https://github.com/lhames/llvm-project/tree/orc-runtime-prototype</a></div><div>[4] <a href="https://llvm.org/docs/ORCv2.html#roadmap">https://llvm.org/docs/ORCv2.html#roadmap</a></div><div><br></div></div></div></div></div></div></div></div></div></div>