similar to: ORC JIT Weekly #1

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

Hello, I recently hit an issue when JIT'ing my generated IR using llvm::orc::LLJIT. My IR contains the following definition of a global variable: > $_ZZ23TestStaticVarInFunctionbE1x = comdat any > @_ZZ23TestStaticVarInFunctionbE1x = linkonce_odr dso_local global i32 123, > comdat, align 4 > And in my host process, there exists the same symbol. I would expect LLJIT to resolve the

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

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

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

Heyho, Recently I tried out the ORCv2 JIT, especially the LLJIT. I gotta say, that I really like the new interface and the way you use it! However there is one thing I'm missing. I wrote a small bit code file, which should force having a global constructor. int wuff(); __declspec(noinline) int miau() { printf("Huhuhu"); return wuff(); } const int x = miau(); When I

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