similar to: How to recompile functions with ORC JIT?

+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

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

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 =

Hi, We are making the move from legacy JIT (llvm-3.5.x) to ORC JIT and I am looking to recompile (and re-link) functions at runtime for an ARM platform (Odroid XU3) . I looked at OrcLazyJIT.cpp as a starting point. However, after going through the code, it appears that the createCompileCallbackMgr (llvm-3.8.0) / createLocalCompileCallbackManager (llvm-git) do not support an ARM triple yet.

+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

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

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,

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 All, I'm going to be making some API breaking changes to the ORC APIs, and to the RuntimeDyld class (which underlies MCJIT). The changes may affect MCJIT clients but are unlikely to. Where they do the fixes are likely to be trivial. ORC clients will be affected, but the fixes should also be straightforward. I have three upcoming changes in mind: 1) RuntimeDyld (the linker underlying

Hi Lang, On Tue, 13 Aug 2019 at 22:15, Lang Hames <lhames at gmail.com> wrote: > >> 1) Can 0 ever be a valid VModuleKey? How can one reliably detect an invalid VModuleKey? > > > I believe 0 was a valid VModuleKey in ORCv1. The assertion is checking the the VModuleKey is present in the LogicalDylibs map. That means that you have to have used that key in an addModule call,

Hi Lang, thanks for announcing. Would be great if you could send another short notice as soon as the actual patch exists. Best, Stefan Am 24.05.16 um 23:06 schrieb Lang Hames via llvm-dev: > Hi All, > > I'm going to be making some API breaking changes to the ORC APIs, and > to the RuntimeDyld class (which underlies MCJIT). The changes may > affect MCJIT clients but are unlikely

Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> writes: > When writing a JIT compiler using LLVM, as I understand it, you can use two > alternative APIs, MCJIT and Orc. The latter offers lazy compilation. Would > it be accurate to say that if you want eager compilation - always compile > an entire module upfront - you should use MCJIT? +lang. My understanding is that

When writing a JIT compiler using LLVM, as I understand it, you can use two alternative APIs, MCJIT and Orc. The latter offers lazy compilation. Would it be accurate to say that if you want eager compilation - always compile an entire module upfront - you should use MCJIT? -------------- next part -------------- An HTML attachment was scrubbed... URL:

At the moment, neither the example code in the slides PDF, nor that in the new kaleidoscope tutorial, successfully compiles against the current version of ORC (in LLVM 8.0.0). Presumably because this is because ORC has changed since they were written. Is there any example code that works with the current version of ORC? -------------- next part -------------- An HTML attachment was scrubbed...

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, I’m wondering if it’s possible to debug code JIT’ed with the newer ORC JIT. The LLVM documentation has a page at llvm.org/docs/DebuggingJITedCode.html <http://llvm.org/docs/DebuggingJITedCode.html> showing an example of using gdb to debug MCJIT’ed code, but has no mention of ORC JIT. From searching around online I’ve gotten the impression that ORC JIT does *not* support providing

Right, but is there any known use case where Orc's flexibility allows something to be done that couldn't be with MCJIT, apart from lazy compilation? On Wed, Mar 30, 2016 at 12:19 AM, Justin Bogner <mail at justinbogner.com> wrote: > Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> writes: > > When writing a JIT compiler using LLVM, as I understand it, you

Hi, I am trying out ORC v2 and facing some problems. I am using LLVM 8.0.1. I updated my ORC v1 implementation from 6.0 to 8.0 based on Kaleidoscope example (i.e. using Legacy classes) and that works fine. Now I am trying out ORC v2 apis, based on https://github.com/llvm-mirror/llvm/blob/master/examples/Kaleidoscope/BuildingAJIT/Chapter2/KaleidoscopeJIT.h. I have got it to compile and build.

Thanks Praveen. Is it suitable for LLVM 7.0.1 ? Apart from flexibility, do we see any compile time improvements as well with ORC? On Sun, Jun 30, 2019 at 12:31 PM Praveen Velliengiri < praveenvelliengiri at gmail.com> wrote: > MCJIT hopefully will be removed in subsequent releases. I think the last > release version is more suitable. > > On Sun, 30 Jun 2019 at 11:45, Ashok