search for: executionenginebuild

...ORCV2 there is no change before and after. I also get this message: JIT session error: Symbols not found: { raise_error } Yes raise_error and all other extern functions are explicitly added as global symbols. > > CodeGen optimization seems a more likely culprit: JITTargetMachineBuilder and ExecutionEngineBuilder have different defaults for their CodeGen opt-level. JITTargetMachineBuilder defaults to CodeGenOpt::None, and ExecutionEngineBuilder default to CodeGenOpt::Default. > > What happens if you make the following modification to your setup? > > auto JTMB = llvm::orc::JITTargetMachineBuild...

Hi Lang, On Tue, 13 Aug 2019 at 20:47, Lang Hames <lhames at gmail.com> wrote: > > Sorry for the delayed reply. Looks like you have figured out how to solve your issue already. Out of interest, what did you need to do? Do you have anything that you would like to see added to http://llvm.org/docs/ORCv2.html ? > Sorry my post was misleading. I figured out below which was part of the

...bols function. > > I would be inclined to do the latter: it's more explicit, and easier to limit searches to exactly the symbols you want. > Okay I will look into this. Thank you for all the help. > > CodeGen optimization seems a more likely culprit: JITTargetMachineBuilder and ExecutionEngineBuilder have different defaults for their CodeGen opt-level. JITTargetMachineBuilder defaults to CodeGenOpt::None, and ExecutionEngineBuilder default to CodeGenOpt::Default. > > > > What happens if you make the following modification to your setup? > > > > auto JTMB = llvm::orc::J...

...m 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 ok with deprecating and eventually removing MCJIT. That's a discussion for the future though. So clients should rest easy: We just went through a difficult transition f...

...T 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 ok with > deprecating and eventually removing MCJIT. That's a discussion for > the future though. > > So clients should rest ea...

Hi Philip, In terms of the overall idea, I like what your proposing. However, I want > to be very clear: you are not planning on removing any functionality from > the existing (fairly low level) MCJIT interface right? > To confirm - I have no plans to remove MCJIT. I don't want to change any behavior for existing clients. The new stuff is opt-in. > We've built our own