search for: indirectstubsmanager

+Lang Hames <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

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

H Theodoros, David, What I am trying to figure out is how the function pointer can be updated > to point to the newly compiled version. As Dave implied, it depends on how you've set up your ORC stack. These days, the API directly responsible for this is the IndirectStubsManager (see llvm/include/llvm/ExecutionEngine/Orc/IndirectionUtils.h). If you have access to the appropriate IndirectStubsManager you just need to call the updatePointer method with the name of the function you want to update and the new address. If you're using the CompileOnDemand layer to compile l...

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,

+Lang Ultravague answer: There are a few different Orc layers for different levels of indirection needed for different levels of substitutability. One way is to indirect every call through global function pointers - so when you want to replace the function you write the new function pointer to the global variable. I forget which layers do which kinds of indirection. - Dave On Thu, May 26, 2016

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

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

...llvm::orc::LegacyIRCompileLayer<llvm::orc::LegacyRTDyldObjectLinkingLayer, llvm::orc::SimpleCompiler>, std::function<std::unique_ptr<llvm::Module>(std::unique_ptr<llvm::Module>)> >; CompileCallbackMgrT = llvm::orc::JITCompileCallbackManager; IndirectStubsMgrT = llvm::orc::IndirectStubsManager; llvm::orc::VModuleKey = long unsigned int]: Assertion `I != LogicalDylibs.end() && "VModuleKey K not valid here"' failed. 1) Can 0 ever be a valid VModuleKey? How can one reliably detect an invalid VModuleKey? 2) Secondly it seems to me that following the assertion there sh...

Hello, I am trying to figure out how to recompile functions multiple times during run-time with ORC JIT and I'd appreciate any help/advice. My use case is t he following: every time a function of interest (annotated) is called, profiling data are gathered. Given enough data the function is recompiled using different optimizations. This happens repeatedly until the "best"

...lvm::orc::LegacyRTDyldObjectLinkingLayer, >> llvm::orc::SimpleCompiler>, >> std::function<std::unique_ptr<llvm::Module>(std::unique_ptr<llvm::Module>)> >> >; CompileCallbackMgrT = llvm::orc::JITCompileCallbackManager; >> IndirectStubsMgrT = llvm::orc::IndirectStubsManager; >> llvm::orc::VModuleKey = long unsigned int]: Assertion `I != >> LogicalDylibs.end() && "VModuleKey K not valid here"' failed. >> >> 1) Can 0 ever be a valid VModuleKey? How can one reliably detect an >> invalid VModuleKey? >> 2) Secondly...