search for: jitdylib

...2b8470 in llvm::orc::PartitioningIRMaterializationUnit::materialize(llvm::orc::MaterializationResponsibility) at /Users/igorgomon/dev/third-party/llvm-project/llvm/lib/ExecutionEngine/Orc/CompileOnDemandLayer.cpp:86 #20 0x00000001062e2844 in llvm::orc::MaterializationUnit::doMaterialize(llvm::orc::JITDylib&) at /Users/igorgomon/dev/third-party/llvm-project/llvm/include/llvm/ExecutionEngine/Orc/Core.h:563 #21 0x00000001062db744 in llvm::orc::ExecutionSession::materializeOnCurrentThread(llvm::orc::JITDylib&, std::__1::unique_ptr<llvm::orc::MaterializationUnit, std::__1::default_delete<ll...

...lity) >>>>> at >>>>> /Users/igorgomon/dev/third-party/llvm-project/llvm/lib/ExecutionEngine/Orc/CompileOnDemandLayer.cpp:86 >>>>> >>>>> #20 0x00000001062e2844 in >>>>> llvm::orc::MaterializationUnit::doMaterialize(llvm::orc::JITDylib&) at >>>>> /Users/igorgomon/dev/third-party/llvm-project/llvm/include/llvm/ExecutionEngine/Orc/Core.h:563 >>>>> >>>>> #21 0x00000001062db744 in >>>>> llvm::orc::ExecutionSession::materializeOnCurrentThread(llvm::orc::JITDylib&, &gt...

...(llvm::orc::MaterializationResponsibility R, llvm::orc::ThreadSafeModule TSM) Line 25 C++ libravi.dll!llvm::orc::BasicIRLayerMaterializationUnit::materialize(llvm::orc::MaterializationResponsibility R) Line 132 C++ libravi.dll!llvm::orc::MaterializationUnit::doMaterialize(llvm::orc::JITDylib & JD) Line 570 C++ libravi.dll!llvm::orc::ExecutionSession::materializeOnCurrentThread(llvm::orc::JITDylib & JD, std::unique_ptr<llvm::orc::MaterializationUnit,std::default_delete<llvm::orc::MaterializationUnit>> MU) Line 1218 C++ [External Code] libravi.dll...

...ne 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 Core.h: *ResourceTracker* -- Your handle to remove code from a JITDylib. Also allows tracking to be merged onto another tracker (reducing the administrative overhead required for tracking). *ResourceKey* -- An opaque key associated with each tracker. *ResourceManager* -- A listener interface to be notified when resources associated with a given key should be removed....

...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) the outright removal of a JITDylib. Right now, I have one ExecutionSession instance for my linker and am creating a new JITDylib for each object file that I'd like to link in. There doesn't appear to be a corresponding...

...We can't really do the same for resource trackers, if I understand this > correctly. Sketching out what I'd need to do to test postgres, so I > don't waste time going in the wrong direction: 1) Add API for management (create, destroy) a non-default resource tracker > (i.e. JITDylib::createResourceTracker) > 3) Add JITDylib::clear() wrapper > 2) LLVMOrcLLJITAdd{LLVMIRModule,ObjectFile} would need a new argument > (defaulting to NULL for the default resource tracker?) to specify the > resource tracker > 4) LLJIT would need to grow the underlying support met...

...erializationResponsibility) > at > /Users/igorgomon/dev/third-party/llvm-project/llvm/lib/ExecutionEngine/Orc/CompileOnDemandLayer.cpp:86 > >>>>>>> > >>>>>>> #20 0x00000001062e2844 in > llvm::orc::MaterializationUnit::doMaterialize(llvm::orc::JITDylib&) at > /Users/igorgomon/dev/third-party/llvm-project/llvm/include/llvm/ExecutionEngine/Orc/Core.h:563 > >>>>>>> > >>>>>>> #21 0x00000001062db744 in > llvm::orc::ExecutionSession::materializeOnCurrentThread(llvm::orc::JITDylib&, > std:...

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 clients to check the dynamic type of Mat...

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 JITDylibs and re-exports used to make symbol definitions visible at the intended locations. On the other hand restricting re...

...nt 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 Core.h: >> >> *ResourceTracker* -- Your handle to remove code from a JITDylib. Also >> allows tracking to be merged onto another tracker (reducing the >> administrative overhead required for tracking). >> *ResourceKey* -- An opaque key associated with each tracker. >> *ResourceManager* -- A listener interface to be notified when resources >> ass...

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

Hey Lang, I would be really happy to only have one LLJIT instance and using multiple JITDylibs. However… it seems like that I don’t know enough to use them. So I wonder… 1. When I add Module A to JITDylib A and Module B to JITDylib B – where will those look for undefined symbols? Will Module A for example: will it only search itself and the MainDylib? Or would it also search in JITDylib...

Nice! Let me try to answer some questions, Before that I have to mention this is ORC version 2 APIs and this is where the project is moving forward. JITDylib is the symbol table, basically for a JIT Symbol it have an associated materializers, (you can think of it like an entity that generate the address for that symbol), Example: compiler are materializers. So to add symbols to your own JIT you can define them in JITDylib. For example, Suppose you want...

Hi Bjoren, For question 1: As you mentioned, it is used to mangle to the symbol name and interning them, So ORC can find them at runtime in one of the JITDylibs. It would be helpful to know what you tried? (please attach code lines). For question 2: I guess you might be missing to link libraries that your program depend on, you can do that via setting up your dynamiclibrary search generator or getCurrentProcess symbols. Plus, Why do you want to hide them...

...message coming from "DynamicLibrarySearchGenerator"? * Redirect Can I somehow redirect this message to a string or something, or silence it? I want to keep my console output clean. 1. Generator function Why does the generator function looks like this: "SymbolNameSet(JITDylib &Parent, const SymbolNameSet &Names)"? I understood, that the "Parent" will be the value from "ES.getMainJITDylib()" while "Names" will have the names that should be resolved. I saw an implementation for the Generator function that kinda looked like that:...

...cutionEngine/Orc/ExecutionUtils.h:19:0, from /path/to/llvm/lib/ExecutionEngine/Orc/OrcMCJITReplacement.h:23, from /path/to/llvm/lib/ExecutionEngine/Orc/OrcMCJITReplacement.cpp:9: /path/to/llvm/include/llvm/ExecutionEngine/Orc/Core.h:690:25: warning: 'llvm::orc::JITDylib::SymbolTableEntry::State' is too small to hold all values of 'enum class llvm::orc::JITDylib::SymbolState' SymbolState State : 6; There is no GCC option for disabling this warning: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414 The issue is that now LLVM is not buildable with...

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 to the provided the Address. 3. Yes, all the class/function with legacy prefix will be removed in subsequent releases. 4. Could please provide some more c...

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

...JIT but I already miss all of the features I need to port my old JIT to the Orc JIT. So I did some research and have some questions now: 1.) Memory Manager I saw that I can actually replace the Memory Manager via the constructor of the "RTDyldObjectLinkingLayer" - is that correct? 2.) JITDyLib I think, but I'm not sure, that I can use a JITDyLib to inject my own addresses for different functions, but I'm not sure how to do that - or if I'm correct with it. 3.) Legacy Layer I later looked into the third Kaleidoscope Tutorial, seeing the "LegacyRTDyldObjectLinkingLayer&qu...

...ing that the symbol __ emutls_v.xyz was not found (substitute the mangled variable name for "xyz"). Does that mean anything to anybody out there? (I don't know if it's relevant, but we are using LLVM 8, and we are using Clang to compile C++ modules that are all put into a single JITDylib.) Geoff -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191220/77d585ef/attachment.html>