search for: runjitonfunction

Dear all, I have a question on the runJITOnFunction() function in JIT.cpp. The second argument MCI must be used to create a MCIListener in the runJITOnFunction() function. However, the JIT::recompileAndRelinkFunction() just calls the runJITOnFunction() like this: " runJITOnFunction(F);", leaving the second argument, the MCI, empty. As...

Hello, JIT::recompileAndRelinkFunction's runJITOnFunction does not use the MCI arg, causing null pointer deferences at every call. Attached patch makes runJITOnFunction more reliable. Thanks, Gianluca -- It was a type of people I did not know, I found them very strange and they did not inspire confidence at all. Later I learned that I had been introdu...

On Dec 19, 2009, at 3:36 PM, Gianluca Guida wrote: > Hello, > > JIT::recompileAndRelinkFunction's runJITOnFunction does not use the > MCI arg, causing null pointer deferences at every call. > > Attached patch makes runJITOnFunction more reliable. When would MCI be null? -Chris

On Tue, Dec 22, 2009 at 6:14 AM, Chris Lattner <clattner at apple.com> wrote: > On Dec 19, 2009, at 3:36 PM, Gianluca Guida wrote: >> Attached patch makes runJITOnFunction more reliable. > > When would MCI be null? Everytime you call recompileAndRelinkFunction. It calls runJITOnFunction without specifying the MCI argument, which get defaulted to NULL. Gianluca -- It was a type of people I did not know, I found them very strange and they did not inspire con...

Hi, I am starting to poke at the LLVM JIT, which seems to be in need of some TLC. If you are a "sophisticated" JIT user and are using either internal APIs (either by integrating with LLVM, or by other C++ tricks), or are using obscure or poorly documented public APIs (e.g., why is runJITOnFunction exposed?) please make me aware of it! I reserve the right to break anything which doesn't have a unit test in the tree. :) I will try very hard to not break anything which *does* have an existing public interface. Cheers, - Daniel

Hi Bill, I'm coincidently planning right now on doing exactly the same things as you. I haven't yet had a chance to implement the code, but I can point you to how I currently believe you can get access to what you need. If you take a look at the code for the implementation of lvm::JIT::runJITOnFunction(Function *, MachineCodeInfo *), you'll see that if a MachineCodeInfo parameter is supplied, it is populated via a call to setAddress and setSize via the registration of a JITEventListener on the Jitting of the given function. I'm almost certain this is the address and size that is needed by...

...ll, > > I'm coincidently planning right now on doing exactly the same things as you. I haven't yet had a chance to implement the code, but I can point you to how I currently believe you can get access to what you need. If you take a look at the code for the implementation of lvm::JIT::runJITOnFunction(Function *, MachineCodeInfo *), you'll see that if a MachineCodeInfo parameter is supplied, it is populated via a call to setAddress and setSize via the registration of a JITEventListener on the Jitting of the given function. I'm almost certain this is the address and size that is needed by...

Thanks Reid - I'm on Windows. I guess I just assumed I was missing something obvious in how to hook up the JIT and disassembler! Given the nice looking disassembly code I found, I thought people would be doing it all the time :-) b. On Tue, Jul 6, 2010 at 8:41 PM, Reid Kleckner <reid.kleckner at gmail.com> wrote: > If you're on a recent flavor of Linux, you may be able to just

...this fix will look fine to me. On Tue, Dec 22, 2009 at 12:23 AM, Gianluca Guida <glguida at gmail.com> wrote: > On Tue, Dec 22, 2009 at 6:14 AM, Chris Lattner <clattner at apple.com> wrote: >> On Dec 19, 2009, at 3:36 PM, Gianluca Guida wrote: >>> Attached patch makes runJITOnFunction more reliable. >> >> When would MCI be null? > > Everytime you call recompileAndRelinkFunction. It calls > runJITOnFunction without specifying the MCI argument, which get > defaulted to NULL. > > Gianluca > > > -- > It was a type of people I did not know, I...

...to poke at the LLVM JIT, which seems to be in need of some TLC. > > If you are a "sophisticated" JIT user and are using either internal > APIs (either by integrating with LLVM, or by other C++ tricks), or are > using obscure or poorly documented public APIs (e.g., why is > runJITOnFunction exposed?) please make me aware of it! > > I reserve the right to break anything which doesn't have a unit test > in the tree. :) > > I will try very hard to not break anything which *does* have an > existing public interface. > > Cheers, > - Daniel > ___________...

...namespace)::Emitter::runOnMachineFunction () #8 0x081deee8 in llvm::MachineFunctionPass::runOnFunction () #9 0x08561cd7 in llvm::FPPassManager::runOnFunction () #10 0x08562185 in llvm::FunctionPassManagerImpl::run () #11 0x08562337 in llvm::FunctionPassManager::run () #12 0x0831f9ec in llvm::JIT::runJITOnFunction () #13 0x08321847 in llvm::JIT::getPointerToFunction () #14 0x0804f680 in MainLoop () at toy.cpp:508 #15 0x0804ff12 in main () at toy.cpp:590

...ived from storeInst. the structure struct.ThreadContext in LLVM IR corresponds to C struct struct ThreadContext { int id; int r[32]; void init(); void setsp(int); void setpc(int); }; The function prototype typedef uint32_t (*func)(struct ThreadContext* ); func = jit->runJITOnFunction(...); then execute the function by func(&ctx); // ctx is defined to be " struct ThreadContext ctx;" My execution result press any key reach reach stderr press any key reach reach stderr press any key reach reach stderr press any key reach reach stderr press any key reach re...

...to poke at the LLVM JIT, which seems to be in need of some TLC. > > If you are a "sophisticated" JIT user and are using either internal > APIs (either by integrating with LLVM, or by other C++ tricks), or are > using obscure or poorly documented public APIs (e.g., why is > runJITOnFunction exposed?) please make me aware of it! Rather than "sophisticated", does "completely insane" JIT user count :-) ? For a while now on and off I've been trying to get a stochastic instruction scheduling working (for just one function body). The idea is to generate a reasonabl...

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 List" <llvmdev at cs.uiuc.edu> Sent: Tuesday, Sep...

...ady bothered people on IRC with this question and it was recommended to ask it here. First of all, some context. In Rubinius (http://rubini.us/, http://github.com/rubinius/rubinius) we use LLVM for our JIT. We create LLVM IR using the C++ API and turn that into machine code using ExecutionEngine::runJITOnFunction. The resulting native code is then installed as the executor for a method. Right now we use a single LLVMContext (the global context), since we reuse a lot of structures such as the types mapping onto the types in the virtual machine. This does have a downside though, mainly that when constant exp...

...ing that looked like a bug report for this issue in Bugzilla. I can't quite figure out this bug. The backtrace looks like: #0 0x900429ac in kill () #1 0x9009eb1c in abort () #2 0x00120ec8 in __eprintf () at /Users/ejones/llvm/llvm/include/llvm/ADT/ilist:440 #3 0x00011ae8 in llvm::JIT::runJITOnFunction(llvm::Function*) (this=0x51015c0, F=0x5101010) at JIT.cpp:217 #4 0x00011da4 in llvm::JIT::getPointerToFunction(llvm::Function*) (this=0x51015c0, F=0x5101010) at JIT.cpp:261 #5 0x000123e4 in (anonymous namespace)::JITResolver::getFunctionStub(llvm::Function*) (this=0x70be78, F=0x5101010) a...

...nMachineFunction () > #8 0x081deee8 in llvm::MachineFunctionPass::runOnFunction () > #9 0x08561cd7 in llvm::FPPassManager::runOnFunction () > #10 0x08562185 in llvm::FunctionPassManagerImpl::run () > #11 0x08562337 in llvm::FunctionPassManager::run () > #12 0x0831f9ec in llvm::JIT::runJITOnFunction () > #13 0x08321847 in llvm::JIT::getPointerToFunction () > #14 0x0804f680 in MainLoop () at toy.cpp:508 > #15 0x0804ff12 in main () at toy.cpp:590 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc...

...e 171.swim SPECfp benchmark. If I run llvm-gcc on the C files, I can generate a functioning executable. However, if I use llvm-gcc with -emit-llvm, then run lli on the resulting bitcode, I get the following error: lli: /x/jeffhao/llvm/llvm-2.4/lib/ExecutionEngine/JIT/JIT.cpp:467: void llvm::JIT::runJITOnFunction(llvm::Function*): Assertion `!isAlreadyCodeGenerating && "Error: Recursive compilation detected!"' failed. Anyone know how to fix this? Jeff

...e 171.swim SPECfp benchmark. If I run llvm-gcc on the C files, I can generate a functioning executable. However, if I use llvm-gcc with -emit-llvm, then run lli on the resulting bitcode, I get the following error: lli: /x/jeffhao/llvm/llvm-2.4/lib/ExecutionEngine/JIT/JIT.cpp:467: void llvm::JIT::runJITOnFunction(llvm::Function*): Assertion `! isAlreadyCodeGenerating && "Error: Recursive compilation detected!"' failed. Anyone know how to fix this? Jeff

...JIT, which seems to be in need of some TLC. >> >> If you are a "sophisticated" JIT user and are using either internal >> APIs (either by integrating with LLVM, or by other C++ tricks), or are >> using obscure or poorly documented public APIs (e.g., why is >> runJITOnFunction exposed?) please make me aware of it! >> >> I reserve the right to break anything which doesn't have a unit test >> in the tree. :) >> >> I will try very hard to not break anything which *does* have an >> existing public interface. >> >> Cheers, &...