search for: mcjitreplacement

...substantial clients than the legacy JIT had. The impetus for > transitioning is also lower: The legacy JIT required a lot of > custom infrastructure to be kept around. MCJIT is much more > lightweight, and shares most of its foundation (RuntimeDyld) with Orc. > > If MCJITReplacement reaches full feature and performance parity > with MCJIT (which I do actually want to see), and the transition > can be done either transparently (by having ExecutionEngineBuilder > return an MCJITReplacement instead of an MCJIT), or in a manual > way that all clients ar...

...oning is higher now, since MCJIT has more substantial clients than the legacy JIT had. The impetus for transitioning is also lower: The legacy JIT required a lot of custom infrastructure to be kept around. MCJIT is much more lightweight, and shares most of its foundation (RuntimeDyld) with Orc. If MCJITReplacement reaches full feature and performance parity with MCJIT (which I do actually want to see), and the transition can be done either transparently (by having ExecutionEngineBuilder return an MCJITReplacement instead of an MCJIT), or in a manual way that all clients are happy to buy into, then I'd be...

...gt; location from where it was compiled.) > Can you clarify what you mean by "install" here? As it stands in the patch, Orc already supports cross-target and out-of-process JITing. The ObjectLinkingLayer exposes the mapSectionAddress call for mapping sections to new locations, and the MCJITReplacement demo passes all remote-jitting regression tests on Darwin. The intent is that Orc should eventually provide a superset of the functionality provided by MCJIT, but with the various features broken out into separate components. I'd be interested to hear about anything that's missing so that...

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 hoping to create a new ThreadSafeModule, add a GlobalVariable...

...pe that people who are working on LLVM-based JITs, if they find this approach useful, will contribute back components that they've built locally and that they think would be useful for a wider audience. As a demonstration of the practicality of this approach the attached patch contains a class, MCJITReplacement, that composes some of the components to re-create the behavior of MCJIT. This works well enough to pass all MCJIT regression and unit tests on Darwin, and all but four regression tests on Linux. The patch also contains the desired "new" feature: Function-at-a-time lazy jitting in roughly...

...re working on LLVM-based JITs, if they find this approach useful, will > contribute back components that they've built locally and that they think > would be useful for a wider audience. As a demonstration of the > practicality of this approach the attached patch contains a class, > MCJITReplacement, that composes some of the components to re-create the > behavior of MCJIT. This works well enough to pass all MCJIT regression and > unit tests on Darwin, and all but four regression tests on Linux. The patch > also contains the desired "new" feature: Function-at-a-time lazy jit...

Hi I’ve previously used the ExecutionEngine::addGlobalMapping to make existing functions available to my JITed code. I’m currently using ORC, as MCJIT does not appear to be maintained any longer (the kaleidoscope examples have not worked for some time with MCJIT). I’m using just the basic ORC CompileLayer directly. So, I’ve essentially copied the ExecutionEngine::addGlobalMapping related