similar to: ORC JIT Weekly #7 -- JITEventListener support and Swift Immediate Mode Migration

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, On 2020-03-09 21:20:44 +0100, Frank Tetzel via llvm-dev wrote: > I think, debugging and profiling support is very important for a JIT > engine. I could never get it to work with older LLVM versions. Is there > example code somewhere available? Since I added the perf listener I probably can help you with that. What exactly was the problem you were hitting? I don't have isolated

> Last time I tried it was some months ago with LLVM 9. I'll try it > shortly with LLVM trunk/master and report back. Finally, I found the time to try it out again. And it works fine in LLVM master. I haven't tried any other LLVM version. Profiling with perf on assembly level works fine. And so does gdb. One can set pending breakpoints on the to be generated function and execution

Hi, I am working on using LLVM to compile parts of longrunning PostgreSQL queries into native code for faster code execution. As postgres is, nearly, entirely written in C and has long-lived (5 years) supported branches (making the higher API stability important), I'm currently using the C API. I started out using MCJIT but it looks like that's slowly on the way out. My current concern

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, The initializer patch review at https://reviews.llvm.org/D74300 has been updated. The new version contains a MachOPlatform implementation that demonstrates how Platforms and ObjectLinkingLayer::Plugins can work together to implement platform specific initialization. In this case, the MachOPlatform installs a plugin that scans objects for __objc_classlist and __objc_selref sections and

Hi all, hi Lang It's a little late to report issues for release_50, but I just found that thing while porting my JitFromScratch examples to 5.0. This is a really nifty detail, but (if I'm not mistaken) the function signature of RTDyldObjectLinkingLayer::NotifyLoadedFtor is incorrect: $ grep -h -r -A 1 "using NotifyLoadedFtor"

Hi Andres, I also want to highlight the necessity of some form of C API, that others > already have. > <snip> > It's fine if the set of "somewhat stable" C APIs doesn't provide all the > possible features, though. Ok. This got me thinking about what a simple LLJIT API should look like. I have posted a sketch of a possible API on http://llvm.org/PR31103 . I

Hi all, Attention: Lang Hames I am developing the nGraph MLIR<https://github.com/NervanaSystems/ngraph/tree/master/src/contrib/mlir> implementation and hitting the following assert while running nGraph unit tests: assert(ObjectBufferMap.find(K) == ObjectBufferMap.end() && "Second attempt to perform debug registration."); Here is a

Hi Adam, Calls to the listeners should be protected by the RTDyldLayerMutex. Could you apply the attached patch and share the debugging output from one of the failing runs? Regards, Lang. On Wed, May 20, 2020 at 8:00 PM David Blaikie <dblaikie at gmail.com> wrote: > +Lang > > On Wed, May 20, 2020 at 4:44 PM Straw, Adam D via llvm-dev < > llvm-dev at lists.llvm.org>

I'm trying to use PerfJITEventListener with llvm::orc::LLJITBuilder: 1. perf record -o /tmp/perf.data -- <my_binary_with_event_listener> 2. perf inject -j -v -i /tmp/perf.data -o /tmp/perf.data.jit *jit marker found: ~.debug/jit/llvm-IR-jit-20200417-3c2242/jit-149849.dump* *injecting: ~/.debug/jit/llvm-IR-jit-20200417-3c2242/jit-149849.dump* *write ELF image

hello folks, I'm working to add runtime updating of code to the OCaml compiler which in its bytecode guise presents no barrier because there is only one linker and it is written in that language and full control is available. With native code on the other hand, there is reliance on the system linker and I got completely lost examining the GNU ld/dl library source code. The prospect of

HI Yichao, RTDyldObjectLinkingLayer has a NotifyObjectLoaded hook that you can use to call NotifyObjectEmitted on your GDBRegistrationListener. If code is going to be unloaded we would have to add an extra hook to call NotifyFreeingObject -- that seems totally reasonable to add. -- Lang. On Wed, Oct 11, 2017 at 10:44 AM, Yichao Yu <yyc1992 at gmail.com> wrote: > > What debugging

Referring to the log messages from my previous mail… I confused myself (and probably others) by reading the “Adding MemMgr 0x55555959f440“ message as “Registering MemMgr 0x55555959f440”. Thus the address mismatch made no sense. How could we be registering a `MemMgr` address/key that does not match once we arrive in `notifyObjectLoaded` method? Answer: Because the registrations is NOT coming

Hi All, There was no update last week -- I'm still trying to get back into a regular schedule. Open-source changes since the last update were: (1) Some bug fixes for JITLink MachO / arm64 support (PAGE21/PAGEOFF12 now handle addends correctly). (2) llvm-jitlink now supports loading archives as well as relocatable objects. (3) llvm-jitlink now supports basic object-file level mocking and

Hi All, The general initializer support patch has landed (see 85fb997659b plus follow up fixes). Some quick background: Until now ORC, like MCJIT, has handled static initializer discovery by searching for llvm.global_ctors and llvm.global_dtors arrays in the IR added to the JIT. This approach suffers from several drawbacks: 1) It provides no built-in support for other program representations:

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 Christian Your use case seems to have similar requirements as remote JITing in ORC. So far I haven't used that part myself and I am sure Lang can tell you much more about it. However, this comment on the RemoteObjectClientLayer class sounds promising for your questions (1) and (2): /// Sending relocatable objects to the server (rather than fully relocated /// bits) allows JIT'd code

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 All, A preliminary version of removable code support has been posted for review in https://reviews.llvm.org/D79312. This patch removes all uses of VModuleKeys (except for Legacy layers) and takes a whole-JITDylib-at-a-time approach to removal. Removing whole JITDylibs requires more work from clients (compared to per-module removal): Modules to be removed must be placed into throw-away