similar to: More function signatures for LLVMRunFunction?

Hi Lang, Thanks for the reply. Responses below. As far as I know nobody is actively working on MCJIT any more. I've been > working on the next generation of LLVM JIT APIs (ORC - see > include/llvm/ExecutionEngine/Orc) for a while now, but they don't have > functionality for running arbitrary functions yet. > Thanks for the pointer to ORC -- it looks like the runFunction

Hi, I think ExecutionEngine as a common interface for both Interpreter and MCJIT is almost useless in the current form. There are separated methods in ExecutionEngine for similar or the same features provided by Interpreter and MCJIT, i.e. to get a pointer to function you should call getPointerToFunction() for Interpreter or getFunctionAddress() for MCJIT. Personally, I'm using MCJIT and

Hello, [Using LLVM r155315, according to `svn log | head`] I am experimenting with programatically building and jitting functions in a module, and I seem to be coming across a crash in some generated code. Using the llvm-c interface I build up the module which dumps like this: ; ModuleID = 'MyModule' target datalayout = "i686-apple-darwin11" target triple =

Dear All Is there is a way to recompile a function at runtime? It seems that I need to -like - invalidate the recompiled function to force the MCJIT to recompile it, cause when I just call runFunction, it neglects any modifications in the function code. Thanks in advance. Regards, Marwa Yusuf Teaching Assistant - Computer Engineering Department Faculty of Engineering - Benha University E-JUST

Hi, I'm attempting to use MCJIT with the C interface with llvm-3.9.0, and it doesn't seem to work. This code is derived from Paul Smith's example code: int main(int argc, char const* argv[]) { LLVMModuleRef mod = LLVMModuleCreateWithName("my_module"); LLVMTypeRef param_types[] = {LLVMInt32Type(), LLVMInt32Type()}; LLVMTypeRef ret_type =

Hi Marwa, MCJIT doesn't provide any support for recompilation. The best you can do is use multiple MCJIT instances and destroy whichever one contains the function "foo" that you want to recompile. MCJIT does not do any dependence tracking either, so you'll also need to destroy and recompile any direct callers of "foo" (and their direct callers, and so on). If you know

Hi David, I'm not certain, but to me the "LLVMSetTarget(module, "i686-apple-darwin11");" line looks suspicious. I'm not familiar with all the ins and outs of how target triples get handled, but it looks to me like that's requesting 32-bit code. I think that if you omit that line completely then the target will be inferred from the execution environment. My best

Another question: Lang, when do you think it'll be ok to move it to the C Bindings? On Fri, Mar 13, 2015 at 6:39 PM, Lang Hames <lhames at gmail.com> wrote: > Hi Pawel, > > I agree. ExecutionEngine, in its current form, is unhelpful. I'd be in > favor of cutting the common interface back to something like: > > class ExecutionEngine { > public: > virtual

Hi Igor, not sure if that will work, but have you tried lli -jit-kind=orc-lazy ? The default is still MCJIT: https://github.com/llvm/llvm-project/blob/master/llvm/tools/lli/lli.cpp#L88 On 13/01/2020 19:07, David Blaikie via llvm-dev wrote: > (+Lang for JIT/interpreter questions) > > On Sun, Jan 5, 2020 at 5:00 PM Igor Gomon via llvm-dev > <llvm-dev at lists.llvm.org

Hi Stefan, I just tried the -jit-kind=orc-lazy with lli executable and it solves the problem on Ubuntu 18.04 (still does not work on Windows 10). But this solution is good enough for me now. Thanks again for your help! -- Best Regards, Igor ________________________________ From: Igor Gomon <giv_ua at hotmail.com> Sent: Tuesday, January 14, 2020 7:38 PM To: Stefan Gränitz

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

Hi, For a new language I am developing (in the very early stages, nothing public posted yet) I would like to able to use a JIT for several purposes: 1) Create a functional REPL as is done is done with in the Kaleidoscope tutorial. 2) Be able to interpret my language in addition to compiling. 3) While compiling, be able to execute arbitrary code at compile time. The simple case will be to

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:

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

I'm using the llvm-c API and want to use the JIT. I've created the following module ; ModuleID = '_tmp' @a = global i64 5 define i64 @__tempfunc() { entry: %a_val = load i64* @a ret i64 %a_val } This output is generated by LLVMDumpModule just before I call LLVMRunFunction. Which yields a LLVMGenericValueRef. However converting the result to a 64bit integer via

Hi all, I have some old code using the JIT via the LLVM-3.0-C API. I want to upgrade to newer versions of LLVM. As a simple example I wrote a C program that creates the following function and calls it: ; ModuleID = 'round-avx.bc' target triple = "x86_64-pc-linux-gnu" define void @round(<8 x float>*) { _L1: %1 = load <8 x float>* %0 %2 = call <8 x

Hi Kevin, Koffie, We will start migrating to ORC for next release, but for now, this release > invoke delete after remove right? MCJIT's removeModule method does not delete the module. You'll need to do that manually. OrcMCJITReplacement is a bug-for-bug compatible implementation of MCJIT using ORC components, so it does not free the memory either. Does this mean MCJIT is

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

On 01/14/2015 02:33 PM, David Blaikie wrote: > > > On Wed, Jan 14, 2015 at 2:22 PM, Lang Hames <lhames at gmail.com > <mailto:lhames at gmail.com>> wrote: > > Hi Dave, > > 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. >

Hi Dave, 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. >> > > Why not? We did work to remove the legacy JIT in favor of MCJIT for the > usual reasons (less code/maintenance burden/etc) - it'd seem unfortunate to > then go back to maintaining two JITs again. > > You mention