similar to: [LLVMdev] How do I get my pass into the JIT?

Hi Andreas, you can run any set of passes you like on your module before handing it to the JIT. Ciao, Duncan. > I managed to write my own pass =) and now I want it to be executed by the LLVM-JIT but I don't see the right way to do it. > The EngineBuilder only allows to set an opt level and as far as I can see the ExecutionEngine does not provide access to the jitstate which holds its

Evan, So, if I understand you correctly, the design you have in mind is to: create a PassManager, pass it to the JIT on construction, and modify runJITOnFunction to run the second PassManager on the Function being jit'd before running the codegen PassManager. Thanks. Tom ----- Original Message ----- From: "Evan Cheng" <evan.cheng at apple.com> To: "LLVM Developers Mailing

I'm migrating from 3.3 to 3.8 and am having a few problems. `CreateStructGEP` requires a type parameter now. I'm not sure what type it's expecting, so I converted `CreateStructGEP( valuePtr, index )` to `CreateStructGEP( valuePtr->getType(), valuePtr, index )`... would that be correct? `arg_iterator` no longer converst to Value*, I have a lot of this now: &*(args++) This

hi all, I'm trying to write an LLVM-based interpreter for a small DSL that we have. The language is very simple (essentially a calculator), but I'd like it to execute efficiently. I've been following the tutorial, and have the following code for instantiating an ExecutionEngine: #include <LLVM\ExecutionEngine\JIT.h> #include

Hi, You cannot call removeModule on a JIT with no modules: jitstate will be 0 and therefore we have a null-pointer exception. The function returns a boolean for success/failure, however, so you would expect to be able to call it and get false back. Should we be checking for jitstate != 0 before accessing the variable? - if (jitstate->getModule() == M) { + if (jitstate &&

----- "Evan Cheng" <evan.cheng at apple.com> wrote: > On Sep 16, 2008, at 8:44 AM, Thomas B. Jablin wrote: > > > Evan, > > So, if I understand you correctly, the design you have in mind is > > to: create a PassManager, pass it to the JIT on construction, and > > modify runJITOnFunction to run the second PassManager on the > > Function

On 14 Jan 2013, at 15:48, Reid Kleckner <rnk at google.com> wrote: > > Or maybe would it be possible to have a custom allocator for memory space for the native code that we could provide? With this last option we would be responsible for the clean up ourselves and just provide memory space to LLVM where it can store the results. > > Yes, you should be able to inherit from

Hello, So the current JIT will be superseded by the MCJIT completely and no further development should be expected for the current JIT? In any case, I am definitely interested in submitting a patch if you could help me by sending me in the right direction, since I really want this working. I managed to reproduce this behavior in LLVM 3.0 by modifying llc to read my .bc file and try to JIT the

Hi all, I can't find a way to add a MachineFunctionPass to the common codegen passes (LLVMTargetMachine::addPassesToEmitMachineCode) while JITting (the pass manager is associated with the jitstate of the JIT and I can't access it because it's private). Have I missed something? Or adding a MachineFunctionPass to codegen requires to change the

On 08/02/13 15:42, David Tweed wrote: > | For ARM, you will need to use the MCJIT ExecutionEngine as the legacy > | one is broken for ARM. (call EngineBuilder::setUseMCJIT()). > > Also remember to include the correct MCJIT headers not the JIT one's: > calling setUseMCJIT() with the old JIT headers are the only ones being > included just constructs an old JIT, it doesn't

Hi, In ExecutionEngine.cpp, when the JIT or the Interpreter have not been linked in then EngineBuilder::create fails without setting ErrorStr. I've attached a patch to fix this. Warm Regards KS Sreeram -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ee-not-linked-in-msg.diff URL:

Hey all, Attached you will find an experimental patch which allows me to play with a derived JIT class. With this patch I've alleviated my concerns with forcing cross module behavior for all users of JIT. However this introduces some new semantics, and kind of circumvents the EngineBuilder API. More important though, I have not addressed any concern about using stub functions in eager

My code to create an ExecutionEngine is segfaulting: std::string errStr; llvm::ExecutionEngine * ee = llvm::EngineBuilder( unique_ptr<llvm::Module>(module) ) .setErrorStr( &errStr ) //line 1618 .setEngineKind( llvm::EngineKind::JIT ) Where module is a `llvm::Module*`. This is code I'm migrating from 3.3 to 3.8. Since the deletion error is happening during

On 5/14/2012 9:51 AM, Jim Grosbach wrote: > >>> >>> If you're hitting that code, you're running the old JIT (which does indeed not support inline assembly), not the MCJIT. >>> >> >> Do I need to enable anything at configure, my configure looks like this: >>> ../llvm/configure --enable-libffi --enable-targets=host-only

On Jul 2, 2009, at 5:20 PM, Reid Kleckner wrote: > On Thu, Jul 2, 2009 at 3:09 PM, Evan Cheng<evan.cheng at apple.com> > wrote: >> The patch looks good to me. But we cannot allow AllocateGVsWithCode >> to >> be initialized to be false yet. Can you add a mechanism to define the >> behavior when the JIT is created / initialized? > > That makes four

Hi, I am using LLVM 3.1, and wants to print the machine code of JIT IR I try the following method EngineBuilder builder(&ctx.getModule()); builder.setEngineKind(EngineKind::JIT); * TargetMachine * tm = builder.selectTarget(); tm->Options.PrintMachineCode = true;* engine = builder.create(); and somewhere in my code, I use runJITonFunction(); Another question is that I am

On May 14, 2012, at 10:21 AM, Ashok Nalkund <ashoknn at qualcomm.com> wrote: > On 5/14/2012 9:51 AM, Jim Grosbach wrote: >> >>>> >>>> If you're hitting that code, you're running the old JIT (which does indeed not support inline assembly), not the MCJIT. >>>> >>> >>> Do I need to enable anything at configure, my

Eek! I'm going to lose track of the threads if you start a new one every time you update the patch. Consider using http://codereview.appspot.com/? On Fri, Feb 26, 2010 at 5:44 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hey all, > Attached you will find an experimental patch which allows me to play with a > derived JIT class. With this patch > I've alleviated

On 5/14/2012 10:28 AM, Jim Grosbach wrote: > > On May 14, 2012, at 10:21 AM, Ashok Nalkund<ashoknn at qualcomm.com> wrote: > >> On 5/14/2012 9:51 AM, Jim Grosbach wrote: >>> >>>>> >>>>> If you're hitting that code, you're running the old JIT (which does indeed not support inline assembly), not the MCJIT. >>>>>

FWIW, I don't like the idea of adding a new JIT class to support linking. I think you can do it without this. On Fri, Feb 26, 2010 at 5:44 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hey all, > Attached you will find an experimental patch which allows me to play with a > derived JIT class. With this patch > I've alleviated my concerns with forcing cross