search for: compileondemandlayer

I needed to be able to update stub pointers for hot functions that get recompiled in a lazy JIT that uses CompileOnDemandLayer. In order to do this I added a method that allows pointers to be updated but does not expose any of the other internals of the COD layer. Does anyone have a cleaner way to do this? Has something to facilitate this already been added? Would it be possible to merge this in? diff --git a/CompileO...

Hi Sean, This is great, but it couples LogicalDylib too tightly to CompileOnDemandLayer. Does this alternative implementation of getLogicalModuleResourcesForSymbol work for you (unfortunately I don't have a local test case for this yet): LogicalModuleResources* getLogicalModuleResourcesForSymbol(const std::string &Name, bool Export...

...<lhames at gmail.com>, Master Regent of the Three <No, Two sir> JITs On Thu, Jul 28, 2016 at 12:31 PM Sean Ogden via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I needed to be able to update stub pointers for hot functions that get > recompiled in a lazy JIT that uses CompileOnDemandLayer. In order to do > this I added a method that allows pointers to be updated but does not > expose any of the other internals of the COD layer. > > Does anyone have a cleaner way to do this? Has something to facilitate > this already been added? Would it be possible to merge this in...

It does work. I just tested it on my JIT. Thanks! As for the part that couples them too tightly, would you recommend I just keep my own specialized version of CompileOnDemandLayer.h that includes this functionality, or do you have any ideas for a cleaner way to do this? I've noticed a couple of people asking for support for updating stub pointers for functions that are optimized at runtime, and I'd be willing to work on adding that support. On Fri, Jul 29, 2016 at 6...

Hi Sean, As for the part that couples them too tightly, would you recommend I just > keep my own specialized version of CompileOnDemandLayer.h that includes > this functionality, or do you have any ideas for a cleaner way to do this? My apologies - I wasn't very clear in my description of the issue. The only sense in which your original patch was tightly coupled was that it had getLogicalModuleResourcesForSymbol accessing Logic...

Hi, I am getting following assertion failure when attempting to remove a module. /llvm/ExecutionEngine/Orc/CompileOnDemandLayer.h:311: llvm::Error llvm::orc::LegacyCompileOnDemandLayer<BaseLayerT, CompileCallbackMgrT, IndirectStubsMgrT>::removeModule(llvm::orc::VModuleKey) [with BaseLayerT = llvm::orc::LegacyIRTransformLayer<llvm::orc::LegacyIRCompileLayer<llvm::orc::LegacyRTDyldObjectLinkingLayer, llvm::orc::Si...

On 13/09/2018 18:22, David Blaikie via llvm-dev wrote: > On Thu, Sep 13, 2018 at 12:13 AM Dávid Bolvanský via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > /home/davidbolvansky/trunk/llvm/unittests/ExecutionEngine/Orc/CompileOnDemandLayerTest.cpp:79:40: >  required from here > /home/davidbolvansky/trunk/llvm/include/llvm/ExecutionEngine/Orc/CompileOnDemandLayer.h:314:29: > warning: redundant move in return statement [-Wredundant-move] > 314 |         return std::move(Err); Note that the move (into the...

...9;t for recoverable errors or logging, they're only for verifying that code is being used according to contract. In this case the contract is that removeModule is only called with valid keys. If the assertion is triggering then either the key you're using is invalid, or my implementation of CompileOnDemandLayer (or the assert itself) is invalid. We just need to fix the offending code. > Sure - in that case there ought be some value of VModuleKey that is invalid. Example NULL for pointers. Otherwise users have to track separately whether it is initialized or not. Having said that just as free(NULL) doe...

Hello Lang, Thanks for your answer. I am now looking for an example of the usage of CompileOnDemandLayer. Is there an example available for that (could not find one in llvm/examples)? Thanks, Revital From: Lang Hames <lhames at gmail.com> To: Revital1 Eres/Haifa/IBM at IBMIL Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> Date: 10/07/2015 12:10 AM Subject:...

...formLayer::addModule returns an Expected<ModuleT>, whereas GlobalMappingLayer returns just a ModuleHandleT. However, in LLVM 4, IRTransformLayer::addModuleSet returned a ModuleSetT and GlobalMappingLayer::addModuleSet also returned a ModuleSetHandleT, so the types matched up. In LLVM 5, the CompileOnDemandLayer was changed to return an Expected<ModuleHandleT>, but not GlobalMappingLayer. Does that explanation seem correct, or am I missing something? Thx, -brian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachm...

...8:22, David Blaikie via llvm-dev wrote: >> > On Thu, Sep 13, 2018 at 12:13 AM Dávid Bolvanský via llvm-dev >> > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> > >> /home/davidbolvansky/trunk/llvm/unittests/ExecutionEngine/Orc/CompileOnDemandLayerTest.cpp:79:40: >> >> > required from here >> > >> /home/davidbolvansky/trunk/llvm/include/llvm/ExecutionEngine/Orc/CompileOnDemandLayer.h:314:29: >> > warning: redundant move in return statement [-Wredundant-move] >> > 314 | ret...

...he lazy bitcode JIT in the lli tool. You can find the code in llvm/tools/lli/OrcLazyJIT.* . Cheers, Lang. On Mon, Jul 20, 2015 at 2:32 AM, Revital1 Eres <ERES at il.ibm.com> wrote: > Hello Lang, > > Thanks for your answer. > > I am now looking for an example of the usage of CompileOnDemandLayer. Is > there an example available for that (could not find one in llvm/examples)? > > Thanks, > Revital > > > > From: Lang Hames <lhames at gmail.com> > To: Revital1 Eres/Haifa/IBM at IBMIL > Cc: LLVM Developers Mailing List <llvmdev at cs....

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

...e/Orc/IRCompileLayer.cpp:35 #17 0x000000010638ff64 in llvm::orc::IRTransformLayer::emit(llvm::orc::MaterializationResponsibility, llvm::orc::ThreadSafeModule) at /Users/igorgomon/dev/third-party/llvm-project/llvm/lib/ExecutionEngine/Orc/IRTransformLayer.cpp:25 #18 0x00000001062b2b5c in llvm::orc::CompileOnDemandLayer::emitPartition(llvm::orc::MaterializationResponsibility, llvm::orc::ThreadSafeModule, std::__1::map<llvm::orc::SymbolStringPtr, llvm::GlobalValue*, std::__1::less<llvm::orc::SymbolStringPtr>, std::__1::allocator<std::__1::pair<llvm::orc::SymbolStringPtr const, llvm::GlobalValue*>...

...wrote: >>>> > On Thu, Sep 13, 2018 at 12:13 AM Dávid Bolvanský via llvm-dev >>>> > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>>> > >>>> /home/davidbolvansky/trunk/llvm/unittests/ExecutionEngine/Orc/CompileOnDemandLayerTest.cpp:79:40: >>>> >>>> > required from here >>>> > >>>> /home/davidbolvansky/trunk/llvm/include/llvm/ExecutionEngine/Orc/CompileOnDemandLayer.h:314:29: >>>> > warning: redundant move in return statement [-Wredundant-m...

...pt 1 is outside array bounds of ‘int [1]’ [-Warray-bounds] 502 | ++EltPtr; /home/davidbolvansky/trunk/llvm/unittests/ADT/SmallVectorTest.cpp:994:30: note: while referencing ‘<anonymous>’ 994 | V2.insert(V2.begin() + 1, 5); /home/davidbolvansky/trunk/llvm/unittests/ExecutionEngine/Orc/CompileOnDemandLayerTest.cpp:79:40: required from here /home/davidbolvansky/trunk/llvm/include/llvm/ExecutionEngine/Orc/CompileOnDemandLayer.h:314:29: warning: redundant move in return statement [-Wredundant-move] 314 | return std::move(Err); In file included from /home/davidbolvansky/trunk/llvm/utils/unittes...

...rns an > Expected<ModuleT>, whereas GlobalMappingLayer returns just a > ModuleHandleT. However, in LLVM 4, IRTransformLayer::addModuleSet returned > a ModuleSetT and GlobalMappingLayer::addModuleSet also returned a > ModuleSetHandleT, so the types matched up. In LLVM 5, the > CompileOnDemandLayer was changed to return an Expected<ModuleHandleT>, but > not GlobalMappingLayer. > > > > Does that explanation seem correct, or am I missing something? > > > > Thx, > > > > -brian > > > > > > > > > > > > _______________...

...rializationResponsibility, >>>>> llvm::orc::ThreadSafeModule) at >>>>> /Users/igorgomon/dev/third-party/llvm-project/llvm/lib/ExecutionEngine/Orc/IRTransformLayer.cpp:25 >>>>> >>>>> #18 0x00000001062b2b5c in >>>>> llvm::orc::CompileOnDemandLayer::emitPartition(llvm::orc::MaterializationResponsibility, >>>>> llvm::orc::ThreadSafeModule, std::__1::map<llvm::orc::SymbolStringPtr, >>>>> llvm::GlobalValue*, std::__1::less<llvm::orc::SymbolStringPtr>, >>>>> std::__1::allocator<std::__1::pa...

...he new jit engine? We were hoping to create a new ThreadSafeModule, add a GlobalVariable, and then add the module to the JIT engine through addLazyIRModule(), but this doesn't seem to work. 2nd question; Is the lookup function supposed to work with global variables by name? Looking through the CompileOnDemandLayer it seems to change the names of globals to "__orc_lcl.<name><id>". Does this affect the lookup methods? I noticed that all of the globals we are looking for are tagged with Internal linkage and end up getting emitted through extractSubModule(). Any help is appreciated. ------...

...::emit(llvm::orc::MaterializationResponsibility, > llvm::orc::ThreadSafeModule) at > /Users/igorgomon/dev/third-party/llvm-project/llvm/lib/ExecutionEngine/Orc/IRTransformLayer.cpp:25 > >>>>>>> > >>>>>>> #18 0x00000001062b2b5c in > llvm::orc::CompileOnDemandLayer::emitPartition(llvm::orc::MaterializationResponsibility, > llvm::orc::ThreadSafeModule, std::__1::map<llvm::orc::SymbolStringPtr, > llvm::GlobalValue*, std::__1::less<llvm::orc::SymbolStringPtr>, > std::__1::allocator<std::__1::pair<llvm::orc::SymbolStringPtr const, > llv...