search for: jitcompilerfn

...ate my patch that has been sitting in Bugzilla for a while as soon as I come up with a good fix. My understanding of how code is JITed: 1. The program calls a stub. 2. The stub does some magic to call into the JIT and pass the stub address as a parameter. 3. Eventually, it ends up in JITResolver::JITCompilerFn which looks up the function. 4. This ends up calling into the JIT eventually. >From what I understand, the JIT *never* calls into the JITResolver. However, the JITResolver calls into the JIT. Hence, it is okay to have two lock objects, one for the JIT and one for the JITResolver. However, these...

...eEmitFunctionStub(...). Is the JIT:getPointerToFunction(...) code path sensitive to such call overhead? 2) JITResolver::forceEmitFunctionStub(Function *F) was added. It is a simplified version of JITResolver::getLazyFunctionStub(...), which does not add to pending. It uses the same JITResolver::JITCompilerFn(...) for runtime emission that the lazy compilation system uses. Outside of the goal, I'm not sure what code is unnecessary here. Notice that the hasAvailableExternallyLinkage case is dealt with here even though forceEmitFunctionStub(...) would not be entered for this case. I'm forced...

...with a good > fix. Ok. Thanks, for forgot about that patch :( > My understanding of how code is JITed: > > 1. The program calls a stub. > 2. The stub does some magic to call into the JIT and pass the stub > address as a parameter. > 3. Eventually, it ends up in JITResolver::JITCompilerFn which looks up > the function. > 4. This ends up calling into the JIT eventually. yes. > From what I understand, the JIT *never* calls into the JITResolver. > However, the JITResolver calls into the JIT. Hence, it is okay to have > two lock objects, one for the JIT and one for the...

...r/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/bits/basic_string.tcc:241 #6 0xb730198b in llvm::Value::getNameStr (this=0x9344910) at Value.cpp:162 #7 0xb6d8c641 in llvm::Value::getName (this=0x9344910) at /cvs/llvm/include/llvm/Value.h:110 #8 0xb6f241c7 in (anonymous namespace)::JITResolver::JITCompilerFn (Stub=0xb5667620) at JITEmitter.cpp:267 #9 0xb6de70e4 in X86CompilationCallback2 (StackPtr=0xbf856f60, RetAddr=-1251576288) at X86JITInfo.cpp:350 #10 0xb6de6d31 in X86CompilationCallback_SSE () from phpllvm.so #11 0xb5667624 in ?? () #12 0x0a295548 in ?? () #13 0x00000001 in ?? () #14 0x0a2920d0...

...the JIT:getPointerToFunction(...) code path sensitive to such call > overhead? > > 2) JITResolver::forceEmitFunctionStub(Function *F) was added. It is a > simplified version of JITResolver::getLazyFunctionStub(...), > which does not add to pending. It uses the > same JITResolver::JITCompilerFn(...) for runtime emission that > the lazy compilation system uses. > > Outside of the goal, I'm not sure what code is unnecessary here. Notice > that the hasAvailableExternallyLinkage > case is dealt with here even though forceEmitFunctionStub(...) would not > be entered for t...

...bMap at the same time. Well, it sort of is, but for a different reason. I'm not sure how I should fix this, so suggestions are welcome. My application is spawning multiple threads that are calling in to the same function. They all call the stub, and they all end up calling into JITResolve::JITCompilerFn. One of them gets the lock and compiles the function. Then, when it releases the lock, another thread tries to continue and immediately gets this exception: lli: JITEmitter.cpp:236: static void* <unnamed>::JITResolver::JITCompilerFn(void*): Assertion `I != JR.state.getStubToFunctionMap(l...

...body's needed this enough to get it working though. I think it'd make some sense to fix it for eager compilation even before getting lazy compilation working. Would you like to write a patch? You'll have to remove all uses of TheJIT and TheJITResolver except for the one in JITResolver::JITCompilerFn, and change the "only one JIT" check to say something about "only one JIT compiling lazily". I don't think this change will require passing an LLVMContext to the JIT--it should just use the Context of the function it's jitting. The code freeze for llvm-2.7 is on Feb 21...

...to get it working > though. > > I think it'd make some sense to fix it for eager compilation even > before getting lazy compilation working. Would you like to write a > patch? You'll have to remove all uses of TheJIT and TheJITResolver > except for the one in JITResolver::JITCompilerFn, and change the "only > one JIT" check to say something about "only one JIT compiling lazily". > > I don't think this change will require passing an LLVMContext to the > JIT--it should just use the Context of the function it's jitting. > > The code free...

Hi everyone ! If I call ExecutionEngine::createJIT (or EngineBuilder::create) more than one time, the second time fails on a assertion "Multiple JIT resolvers?". It seems that the JIT is designed to be a singleton in the process, and I was wondering if it was something mandatory. How hard will it be to make it a non-singleton object ? Is this a JIT-only problem (work needed on JIT

...gt; though. >> >> I think it'd make some sense to fix it for eager compilation even >> before getting lazy compilation working. Would you like to write a >> patch? You'll have to remove all uses of TheJIT and TheJITResolver >> except for the one in JITResolver::JITCompilerFn, and change the "only >> one JIT" check to say something about "only one JIT compiling lazily". >> >> I don't think this change will require passing an LLVMContext to the >> JIT--it should just use the Context of the function it's jitting. >&gt...

...> >> I think it'd make some sense to fix it for eager compilation even > >> before getting lazy compilation working. Would you like to write a > >> patch? You'll have to remove all uses of TheJIT and TheJITResolver > >> except for the one in JITResolver::JITCompilerFn, and change the "only > >> one JIT" check to say something about "only one JIT compiling lazily". > >> > >> I don't think this change will require passing an LLVMContext to the > >> JIT--it should just use the Context of the function it...

...t the patch as a comment to 2606, or should I submit the patch here. Basically the patch involves forcing a stub emission for functions defined across module boundaries (without adding to pending), even though lazy compilation could be turned off. Among the changes, the lazy compilation check in JITCompilerFn(...) is disabled. I'm still adding my own unit tests, but I'd like to know how to approach such a discussion for changes to code areas that I'm not responsible for. Thanks in advance Garrison

On Sat, Sep 20, 2008 at 12:12 PM, madiyaan <ahmadsharif at hotmail.com> wrote: > Hello: > > I am new to llvm. I am looking for an example somewhere, or a > walkthrough/guide on how to do runtime optimization using llvm. Ideally, I > would like to: > > 1. Compile the program from C to LLVM or native with LLVM information > embedded in the binary. > 2. Run the binary

Hi, > Today I've been trying to debug a weird bug that makes JIT crash with > certain code and when using the inliner. This may sound weird, but if I > disable the inliner, it doesn't crash. > I include an example gdb dump below. Does something looks wrong? Do you > think it's a bug in JIT or it's just some other piece of code that is > writing on the JIT

...=11384== at 0x54B6F04: llvm::StringMapEntryBase::getKeyLength() const (StringMap.h:47) ==11384== by 0x59C6CFD: llvm::Value::getNameStr() const (Value.cpp:162) ==11384== by 0x544FE54: llvm::Value::getName() const (Value.h:110) ==11384== by 0x55E7DA8: (anonymous namespace)::JITResolver::JITCompilerFn(void*) (JITEmitter.cpp:269) ==11384== by 0x54AA47B: X86CompilationCallback2 (X86JITInfo.cpp:350) ==11384== by 0x54AA0C8: (within /usr/local/lib/php/extensions/no-debug-non-zts-20071006/phpllvm.so) ==11384== by 0x8F74D78: ??? ==11384== by 0x55E15BF: llvm::JIT::runFunction(llvm::Function...

Hello: I am new to llvm. I am looking for an example somewhere, or a walkthrough/guide on how to do runtime optimization using llvm. Ideally, I would like to: 1. Compile the program from C to LLVM or native with LLVM information embedded in the binary. 2. Run the binary under LLVM's interpreter, and profile the data. I hope LLVM has support for all this, and I don't have to insert my own

...anagerImpl::run(llvm::Function&)+0x72)[0x8063d2] lli(llvm::FunctionPassManager::run(llvm::Function&)+0x3e)[0x80651e] lli(llvm::JIT::runJITOnFunction(llvm::Function*)+0x48)[0x5c4848] lli(llvm::JIT::getPointerToFunction(llvm::Function*)+0x159)[0x5c51e9] lli((anonymous namespace)::JITResolver::JITCompilerFn(void*)+0x2df)[0x5c774f] lli(X86CompilationCallback2+0x43)[0x4ec053] lli[0x4ebfaa] Aborted (core dumped) Is there a way to link the functions declared in the .o file in the bitcode without compiling the C sources with llvm-gcc? Regards, John van Schie

...s manager to control what optimization passes are run at runtime. I'd advise you to do the same. If I understand your requirement correctly, you'd like the JIT to run additional optimization passes when a function is lazily compiled, right? That will require overriding the default JITCompilerFn in JITEmitter.cpp. You'll also have to roll your own lli replacement. Fortunately that's pretty straight forward. Evan > > Consider the following example function: > > int power(int (*func)(int), int x, int n) { > int i; > for (i = 0; i < n; i++) { > x =...

Interesting. Was this the reason you were getting the recursive compilation error in JIT::runJITOnFunctionUnlocked(...) (isAlreadyCodeGenerating)? Do you have the time to try your test with 2.7? Garrison On Jan 22, 2010, at 17:37, James Williams wrote: > I've worked around this issue in my test case by simply calling my personality function on program to ensure it's JIT'ed

...run (this=0x17100d0, F=...) at PassManager.cpp:1230 #14 0x0000000000d3e2f2 in llvm::JIT::runJITOnFunctionUnlocked (this=0x1781e90, F=0x1718320, locked=...) at JIT.cpp:628 #15 0x0000000000d3e6a6 in llvm::JIT::getPointerToFunction (this=0x1781e90, F=0x1718320) at JIT.cpp:680 #16 0x0000000000d44382 in JITCompilerFn (Stub=0x7ffff7fe401c) at JITEmitter.cpp:709 #17 0x0000000000b44caa in X86CompilationCallback2 (StackPtr=0x7fffffffdf58, RetAddr=140737354022940) at X86JITInfo.cpp:365 #18 0x0000000000b44baa in X86CompilationCallback () at X86JITInfo.cpp:40 #19 0x00007ffff7fe401d in ?? () #20 0x00007ffff7f4c030 in m...