similar to: ORC JIT Weekly #26 -- Orc library break-up, remote TargetProcessControl, and the beginnings of a runtime.

Hi All, Everything is landing all at once, just not in the mainline... yet. As discussed in http://lists.llvm.org/pipermail/llvm-dev/2020-September/144885.html: OrcV1 will be removed very soon. I have posted a branch with the removal, "orcv1-removal", in my llvm fork at https://github.com/lhames/llvm-project. In addition to removing OrcV1, the orcv1-removal branch also contains a

Hi All, This was a quiet week -- the only significant ORC change was to the new TargetProcessControl API [1], which acquired the ability to load libraries and search for symbols in the target process in [2]. A new TargetProcessControl based definition generator is included to take advantage of this, and the LLJITWithTargetProcessControl example has been updated to include it. Regards, Lang. [1]

Hi Stefan Thank you! In case, you missed in llvm-dev listing: you can find the proposal here : link. <https://docs.google.com/document/d/1202EcXlWMQ8yxu5qD0b5fE0a_kihlcaPNpZo_Jk0YeQ/edit?usp=sharing> Thanks for working on summarising the Bugzilla tickets to track the recent changes in ORC this is really helpful. On Sat, 18 May 2019 at 21:33, Stefan Gränitz <stefan.graenitz at

+ MLIR dev mailing list since that’s where the OrcJit I’m using is. Thanks for all the details, Lang! What you described is exactly what I’m looking for! Please, MLIR dev, let me know if this debug feature and the solution that Lang describes below is interesting for MLIR. I’ll dig more into the details then but it doesn’t seem too complicated. Thanks, Diego From: Lang Hames [mailto:lhames at

Hi Lang, On Tue, 13 Aug 2019 at 22:03, Lang Hames <lhames at gmail.com> wrote: > When you say your code is not getting optimized, do you mean that IR optimizations are not being applied, or that codegen optimizations are not being applied? > > What do you see if you dump the modules before/after running the pass manager on them, like this: > > dbgs() << "Before

Hi, I am still on LLVM v6 as v7 ORC api changes were not backward compatible. Has the ORC api stabilized now with v8, or is it still under flux? Thanks and Regards Dibyendu

Hello everyone A previous thread about OrcJIT brought up bug reports on Bugzilla. A quick search gives 20+ results: https://bugs.llvm.org/buglist.cgi?component=OrcJIT&list_id=162232&query_format=advanced&resolution=--- While some of them are obviously outdated (addModuleSet API cleanup [1]), others may actually be relevant again (Small code model? [2]). If you reported one of them,

Hi All, I've added a very basic set of C bindings for OrcV2 in 633ea07200e, with an example in llvm/example/OrcV2Examples/BasicOrcV2CBindings. Development of the C APIs is being tracked by http://llvm.org/PR31103 -- if you're interested in C APIs for OrcV2 please get involved. I would especially appreciate feedback and patches from C API users: I don't have a use case for the C APIs

Hi Lang, On Tue, 13 Aug 2019 at 20:47, Lang Hames <lhames at gmail.com> wrote: > > Sorry for the delayed reply. Looks like you have figured out how to solve your issue already. Out of interest, what did you need to do? Do you have anything that you would like to see added to http://llvm.org/docs/ORCv2.html ? > Sorry my post was misleading. I figured out below which was part of the

Hi, Lang As a starter using LLVM JIT to improve OLAP execution engine performance, I'm very glad to hear that. I can't find some useful document help me get start to use the new ORC JIT API quickly. Only can find some examples how to use it, but don't know the internal from low level, and very blurred to design a clearly JIT toolset. Hope more tutorials add in and help ORC JIT more

Hi Lang, On Tue, 13 Aug 2019 at 23:26, Lang Hames <lhames at gmail.com> wrote: >> I also get this message: >> JIT session error: Symbols not found: { raise_error } > > > Ahh -- I see the problem. The DynamicLibrarySearchGenerator is using the getAddressOfSymbol method, which (under the hood) is basically issuing an appropriate dlsym lookup, and that does not find

Hi All, This week I've been focused on removing some of the blockers for people transitioning from ORCv1 to ORCv2. Issue #1 (http://llvm.org/PR40074, http://llvm.org/PR44337): When LLVM codegens floating point constants for COFF we produce named constant pool entries of the form __real@<bitval>. These are stored in COFF COMDAT sections [1] which allow duplicate symbol definitions to

Hi All, In the interests of improving visibility into ORC JIT development I'm going to try writing weekly status updates for the community. I hope they will provide insight into the design and state of development of LLVM's JIT APIs, as well as serving as a convenient space for discussions among LLVM's large and growing community of JIT API users. The length and detail will vary

Hi folks, Rather by accident than on purpose I looked at the release notes and found the following: http://releases.llvm.org/8.0.0/docs/ReleaseNotes.html#changes-to-the-jit-apis TL;DR: Orc v1 is deprecated and will be removed in the next release. I have several questions in this regard: 1. Is there a migration guide I can use to update my code to the new version? 2. Is there any development

On Sat, 10 Aug 2019 at 21:05, Praveen Velliengiri <praveenvelliengiri at gmail.com> wrote: > > Optimize Module is just a function object. > Thank you - I fixed that now. Regards

Hi All, There was only one interesting ORC-specific commit this week: A new example showing how to initialize and de-initialize JITDylibs has been added in llvm/examples/OrcV2Examples/LLJITWithInitializers. The Extensible RTTI system (https://reviews.llvm.org/D39111) that I posted a while back has landed. While this is not ORC specific, I expect it to be used in upcoming patches to allow ORC

Hi Praveen, On Sat, 10 Aug 2019 at 21:05, Praveen Velliengiri <praveenvelliengiri at gmail.com> wrote: > > Could you please send me your unoptimized and expected optimized code? The default implementation only contains some transformations. It would be helpful to know what you are actually trying. > Optimize Module is just a function object. > You can view the code here:

Hi Connor, ...The LLVM documentation has a page at > llvm.org/docs/DebuggingJITedCode.html > showing an example of using gdb to debug MCJIT’ed code, but has no mention > of ORC JIT. What debugging support MCJIT has is provided by the RuntimeDyld utility, which ORC shares. I would expect anything in that document to apply to ORC as well, though I haven't tested it personally.

Hi Bjoern, CC'ing Lang hames For questions, 1. In short yes, you can replace the memory manager, default one provided is section memory manager. 2. If you mean by " address of already compiled code", yes you can do that. Like this JITDylib.define(absoluteSymbols, ( Your_own_symbol , JITTargetAddress(Address of function))), now ORC can resolve all the references to Your_own_symbol

Hi, I'm working on a runtime autotuner that utilizes ORCv2 JIT (I'm closely tracking tip-of-tree), so linking new object files and patching in the new function(s) will happen frequently. One of the concerns my runtime system has is the ability to do one of the following: (1) replacement of the contents of a JITDylib with a new object file [to provide semi-space GC-style reclaiming], (2)