similar to: ORC JIT Weekly #21 -- OrcV1 removal, Removable code, and Remote TargetProcessControl

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 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, 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 updated the orcv1 removal branch ( https://github.com/lhames/llvm-project/tree/orcv1-removal) with an initial patch for removable code. If anyone wants to follow along with the development or share thoughts on the design you're very welcome to. I'll be adding tests and comments this week, but for anyone who wants to take an early look the main elements are defined in

Hi Andres, Cool!I assume this works on "non-native" jitlink platforms as well? Or > just mach? This framework is totally materializer agnostic -- It works for ObjectLinkingLayer (JITLink), RTDyldObjectLinkingLayer (RuntimeDyld), and even materializers that aren't emitted via a linker (e.g. stubs and callbacks). Looks like there's not yet a C API yet - not a problem, just

Hi All, The time has finally come to remove OrcV1. I expect to remove it some time after the 14th of September. This will remove all the legacy layers, legacy utilities, the old Orc C bindings, and OrcMCJITReplacement. ExecutionEngine and MCJIT will *not* be affected by this. I had hoped to have removable code enabled before deleting OrcV1, but it turns out that implementing removable code in

Hi Andres, Postgres uses removable code support and Orcv1. I does make me quite > worried to see a phase where there'll be no viable way of using both in > llvm. Why isn't the right answer here to at lest develop the > replacement as a set of patches / as a branch that then can be merged as > a whole / shortly after each other, rather than just starting to develop > a

Hi, On 2020-09-30 21:31:33 -0700, Lang Hames wrote: > I've taken a first shot at hooking RTDyldObjectLinkingLayer up to the > ResourceTracker API in 7436b2ab2428. Could you let me know whether that > fixes the leak you were seeing? It did improve the situation significantly, thanks! There's still a smaller leak, unfortunately. The function comments for modules say that: /** *

Hi All, The Kaleidoscope tutorials have now been updated on the orcv1-removal branch. I will try to summarise the state of the work and provide some examples in the ORC JIT Weekly mailout tomorrow. The short version is that I think this is ready to land on the mainline. If anyone wants to check out the OrcV1 removal branch and provide feedback now is the time. Otherwise I will aim to land the

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

Hmm, I'm confused. The DSO is compiled with gcc. Do I need to compile it with clang instead? I don't believe the JITted code uses the thread support library directly, although I suppose it may be hidden with templates and/or inline functions... On Mon, Sep 28, 2020 at 10:43 PM Lang Hames <lhames at gmail.com> wrote: > > Hi Geoff, > > If you want to access the variable

Hi, On 2020-09-30 19:00:45 -0700, Lang Hames wrote: > Ok -- I'll make getting the new lookup API working a priority then. Cool. > > I see a memory leak with OrcV2 that I didn't see with V1. I'm not yet > > sure where exactly they're coming from. Possible that I'm just missing a > > step somewhere. Or something around the removable code support

Hi, On 2020-09-30 17:52:46 -0700, Lang Hames wrote: > I've just realised that we're going to need a change to the definition > generator API in the long term: Right now it is called under the session > lock, but we want to shift to calling it outside the lock and passing a > lookup-continuation. This would allow definition discovery to take an > arbitrarily long time

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 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

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 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 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 JITters, I have some JIT-compiled C++ code that uses symbols from a DSO which uses C++14's thread support library. When I compile it I get the following error message: Symbols not found: [ __emutls_v._ZSt15__once_callable, __emutls_v._ZSt11__once_call ] Those seem to correspond to std::__once_callable and std::__once_call, which are indeed present in the C++ standard library. And I

Hi, On 2020-09-25 16:38:41 -0700, Andres Freund via llvm-dev wrote: > On 2020-09-24 16:34:30 -0700, Lang Hames wrote: > > If anyone wants to check out the OrcV1 removal branch and provide feedback > > now is the time. Otherwise I will aim to land the work in the mainline > > early next week. > > I'm trying to get it to work with postgres. Unfortunately this week