search for: addirmodule

...ces to the // containing JITDylib's tracker. void detach(); }; I'm hoping that usage will look like: LLJIT J = LLJITBuilder().create(); // No tracker specified. Resources tracked by the containing // JITDylib's tracker, and freed when the JITDylib is // deinitialized. ExitOnErr(J.addIRModule(sdt::move(UntrackedModule))); // Explicitly specify tracker. Module symbols can be // - materialized by calling T->emit(); // - removed by calling T->remove(); // - transfered to the JITDylib by calling T->release(); auto T = std::make_unique<ResourceTracker>(); ExitOnErr(J.addIR...

...(llvm::orc::IRLayer&, llvm::o> | | | ->03.53% (97,542B) 0x83B1C7D: llvm::orc::IRLayer::add(llvm::IntrusiveRefCntPtr<llvm::orc::ResourceTracker>, llvm::orc::ThreadSafeModule) (Layer.cpp:28) | | | ->03.53% (97,542B) 0x83BCBF5: llvm::orc::LLJIT::addIRModule(llvm::orc::JITDylib&, llvm::orc::ThreadSafeModule, llvm::IntrusiveRefCntPtr<llvm::orc::ResourceTracker>) (LLJIT.cpp:990) | | | ->03.52% (97,354B) 0x840C95B: LLVMOrcLLJITAddLLVMIRModule (OrcV2CBindings.cpp:263) | | | | ->03.52% (97,354B) 0x...

We are trying to switch to the new orc v2 lljit engine at my work with hopes of parallel jitting. We are switching from the ExecutionEngine w/ OrcMCJitReplacement. We are having a hard time with global variables. We have found a way to create/emit new globals during jitting by using the old ExecutionEngine::getOrEmitGlobalVariable. Is there an easier way to do this with the new jit engine? We were

...; | | | ->03.53% (97,542B) 0x83B1C7D: >> llvm::orc::IRLayer::add(llvm::IntrusiveRefCntPtr<llvm::orc::ResourceTracker>, >> llvm::orc::ThreadSafeModule) (Layer.cpp:28) >> | | | ->03.53% (97,542B) 0x83BCBF5: >> llvm::orc::LLJIT::addIRModule(llvm::orc::JITDylib&, >> llvm::orc::ThreadSafeModule, >> llvm::IntrusiveRefCntPtr<llvm::orc::ResourceTracker>) (LLJIT.cpp:990) >> | | | ->03.52% (97,354B) 0x840C95B: >> LLVMOrcLLJITAddLLVMIRModule (OrcV2CBindings.cpp:263) >> | |...

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 Bjoern, Thanks for your patience. The good news is that there is a neater way to do this: ExecutionSession's lookup methods take a orc::SymbolState parameter which describes the state that symbols must reach before a query can return (See https://github.com/llvm/llvm-project/blob/d1a7bfca74365c6523e647fcedd84f8fa1972dd3/llvm/include/llvm/ExecutionEngine/Orc/Core.h#L1273).In your case you