similar to: ORC JIT Weekly #5

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 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, Just a couple of updates this week: First: there is a preview patch up at https://reviews.llvm.org/D75838 to enable use of JITEventListeners in RTDyldObjectLinkingLayer. I've only done very preliminary testing on it, but was able to debug simple JIT'd programs on Linux using the GDB registration listener. If you've been wanting to move to ORC but held up by lack of debugger /

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

Hello, I am trying to run this basic C++ hello-world code in my iOS app that has LLVM libraries linked in (the app runs on the actual device - iPad Pro, iOS 13.4.1). #include <iostream> int main (int argh, char *argv[]) { std::cout << "Hello World!" << std::endl; return 0; } So below is the break down of the steps that I do: First I compile this code to an

Hi Geoff, We use LLJIT. Do addObjectFile() and StaticLibraryDefinitionGenerator work > for ELF objects? They do. :) I've not tested StaticLibraryDefinitionGenerator extensively on Linux. but we have a regression test checking basic usage. If you run into any trouble at all please file a bug and assign it to me. -- Lang. On Mon, Sep 28, 2020 at 2:05 PM Geoff Levner <glevner at

Hi Geoff, Importing symbols into the JIT from an object file or static library...? Sure! Are you interested in doing this with the C API, LLJIT, or raw OrcV2 components? The high-level answer here (which we can dig into further in the BoF) is: For object files: - For raw OrcV2 components you'll want to create an RTDyldObjectLinkingLayer or ObjectLinkingLayer and use the 'add'

Hi Lang, Please see below is the trace. -- Thanks, Igor *2020-06-06 12:05:21.016705-0400 CppDevProCompiler[6613:3000073] Running...* *jitLink_MachO: magic = 0xfeedfacf, identifier = "llvm-link.submodule-jitted-objectbuffer"* *jitLink_MachO: cputype = 0x0100000c, cpusubtype = 0x00000000* *Creating normalized sections...* * __text: 0x0000000000000000 -- 0x0000000000000064, align:

Hi Dave, Yep. This is JITLink specific, so we could only have observed it on MachO x86-64 or arm64 until recently. It takes a little bit of poking to get IR to produce a zero-lengh section on MachO, but not much. Jared Wyles recently contributed an initial JITLink ELF implementation, so the fix seems timely -- we might have been about to see more of it. -- Lang. On Fri, Jun 19, 2020 at 4:02 PM

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 All, I've listed the current topics of interest below, along with some notes on each. We only have 30 minutes so we'll barely scratch the surface of these during the BoF itself. My main aims are for you to meet each other, identify potential areas of collaboration, identify things that I can do to unblock you, and get the ball rolling on some conversations that we can continue on the

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 Andres, A topic that I'd find interesting is what it'd take to make it easier to > use profile guided optimization in the context of JIT. A few years back > I crudely hacked this together, but it was fairly ugly. It'd be nice to > make that easier. Possibly too complicated for that type of session? We couldn't go into detail, but we could kick off a discussion and

Trying to put together a simple test JIT compiler, using ORC which as I understand it will be the supported API going forward, I noticed that in the first chapter of the updated Kaleidoscope tutorial, there is sample code that starts like this: ExecutionSession ES; RTDyldObjectLinkingLayer ObjectLayer; IRCompileLayer CompileLayer; DataLayout DL; MangleAndInterner Mangle; ThreadSafeContext Ctx;

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 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, 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, 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! As described in my last email, this commit breaks the OrcJIT library

Hi Geoff, I have only encountered one problem. If a static library has not been > compiled with -fPIC and uses symbols from a shared library, LLJIT does not > complain, but the code may crash without warning when it is executed. Was the static library compiled with large code model too? I think this is probably a RuntimeDyld bug: It's not great at error reporting. A few people in the

I have a few questions about the new ORC JIT. I saw Lang Hames (hi!) excellent talk at the llvm-dev meeting a few weeks ago. The ORC JIT is undergoing some API changes and I'd like/need to take advantage of them. (1) How do I take ownership of the ObjectFile once the ORC JIT has created it? I'd like to take ownership of object files generated by the ORC JIT so that I can save them to