search for: runjitonfunctionunlock

...e compilation of Fb until we have finished the compilation of Fa, unless Fb has previously been compiled. Let's say we used JITEmitter::getLazyFunctionStub(...). If a user called getPointerToFunction(...) on Fa, everything would work fine. In compiling Fa, getPointerToFunction(...) (via JIT::runJITOnFunctionUnlocked(...)) would encounter Fb in module B, run getLazyFunctionStub(...) on it, and then finish with the evaluation of the pending list; again via runJITOnFunctionUnlocked(). The latter functionality would result in the compilation of Fb. Say however we instead had Fa1 call Fb, and Fa2 in sequence (Fa...

...total total.s"; ran ./total. It seems to work: $ ./total __l_personality called$ Of course it is probably supposed to work from the JIT too (I don't know anything about the JIT), but it clearly doesn't: when I tried I got: lli: lib/ExecutionEngine/JIT/JIT.cpp:624: void llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, const llvm::MutexGuard&): Assertion `!isAlreadyCodeGenerating && "Error: Recursive compilation detected!"' failed. ... 6 lli 0x0000000000d3f5e2 llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 62 7 lli...

In thinking about this we could use a Mutex::tryacquire(...) (non-recursive), around JIT::runJITOnFunctionUnlocked(...)'s while loop, and use your JITEmitter:: getLazyFunctionStub(...) suggestion in place of forceEmitFunctionStub(...). Is the lock attempt too heavy, even if it is implemented with atomics? I'll implement this when I have time. Garrison On Feb 17, 2010, at 15:42, Garrison Venn wrote:...

...in *__GI_abort () at abort.c:92 #2 0x00007ffff6ed1481 in *__GI___assert_fail ( assertion=0x11acb18 "!isAlreadyCodeGenerating && \"Error: Recursive compilation detected!\"", file=<value optimised out>, line=624, function=0x11ad740 "void llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, const llvm::MutexGuard&)") at assert.c:81 #3 0x0000000000d3e2c2 in llvm::JIT::runJITOnFunctionUnlocked (this=0x1781e90, F=0x17196b0, locked=...) at JIT.cpp:624 #4 0x0000000000d3e6a6 in llvm::JIT::getPointerToFunction (this=0x1781e90, F=0x17196b0) at JIT.cpp:680 #5 0x0...

...o > work: > > $ ./total > __l_personality called$ > > Of course it is probably supposed to work from the JIT too (I don't know > anything about the JIT), but it clearly doesn't: when I tried I got: > > lli: lib/ExecutionEngine/JIT/JIT.cpp:624: void > llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, const > llvm::MutexGuard&): Assertion `!isAlreadyCodeGenerating && "Error: Recursive > compilation detected!"' failed. > ... > 6 lli 0x0000000000d3f5e2 > llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard > con...

...otal >> __l_personality called$ >> >> Of course it is probably supposed to work from the JIT too (I don't know >> anything about the JIT), but it clearly doesn't: when I tried I got: >> >> lli: lib/ExecutionEngine/JIT/JIT.cpp:624: void >> llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, const >> llvm::MutexGuard&): Assertion `!isAlreadyCodeGenerating && "Error: Recursive >> compilation detected!"' failed. >> ... >> 6 lli 0x0000000000d3f5e2 >> llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm:...

...----------- I compile and run the program by: $ clang++ -emit-llvm -S example.cc -o example.S $ llvm-as example.S -o example.bc $ lli example.bc and get the "Recursive compilation" error output: lli: /home/dongpeng/Program/llvm/lib/ExecutionEngine/JIT/JIT.cpp:467: void llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, const llvm::MutexGuard&): Assertion `!isAlreadyCodeGenerating && "Error: Recursive compilation detected!"' failed. 0 lli 0x0000000001323d37 llvm::sys::PrintStackTrace(_IO_FILE*) + 38 1 lli 0x0000000001323fbe 2 lli 0...

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 before any unwind...

...seems to work: > > $ ./total > __l_personality called$ > > Of course it is probably supposed to work from the JIT too (I don't know > anything about the JIT), but it clearly doesn't: when I tried I got: > > lli: lib/ExecutionEngine/JIT/JIT.cpp:624: void llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, const llvm::MutexGuard&): Assertion `!isAlreadyCodeGenerating && "Error: Recursive compilation detected!"' failed. > ... > 6 lli 0x0000000000d3f5e2 llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 62 > 7...

...ager::run (this=0x4b566c0, F=@0x4530c60) at /tmp/llvm-svn/llvm/lib/VMCore/PassManager.cpp:1324 #10 0x0000000802f50500 in llvm::JIT::jitTheFunction (this=0x327a7e0, F=0x4530c60, locked=@0x7fffffff9840) at /tmp/llvm-svn/llvm/lib/ExecutionEngine/JIT/JIT.cpp:655 #11 0x0000000802f5037b in llvm::JIT::runJITOnFunctionUnlocked (this=0x327a7e0, F=0x4530c60, locked=@0x7fffffff9840) at /tmp/llvm-svn/llvm/lib/ExecutionEngine/JIT/JIT.cpp:633 #12 0x0000000802f507e4 in llvm::JIT::getPointerToFunction (this=0x327a7e0, F=0x4530c60) at /tmp/llvm-svn/llvm/lib/ExecutionEngine/JIT/JIT.cpp:719 Here is the stack when RET instru...

...cursion. This print statement makes it clear that the JIT compiler was working on sigsegv_handler before it attempted to start on timer_handler. ===================================== Recursive compilation: Function: timer_handler, existing function sigsegv_handler lli: JIT.cpp:579: void llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, const llvm::MutexGuard&): Assertion `!isAlreadyCodeGenerating && "Error: Recursive compilation detected!"' failed. 0 lli 0x08a5308e 1 lli 0x08a53601 2 0x008e0420 __kernel_sigreturn + 0 3 libc.so.6 0x00146ac1 abort + 257 4...

I've worked around this issue in my test case by simply calling my personality function on program to ensure it's JIT'ed before any unwind happens. -- James 2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > No, there is no magic. :-) > > To me though, the tools are magic, because I have no clue what they are > doing without looking at them and using them. >

...l::run(llvm::Function&) + 129 12 lli 0x0000000103481542 llvm::FunctionPassManager::run(llvm::Function&) + 162 13 lli 0x0000000102ebb2cf llvm::JIT::jitTheFunction(llvm::Function*, llvm::MutexGuard const&) + 63 14 lli 0x0000000102ebb17a llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 122 15 lli 0x0000000102ebb5b7 llvm::JIT::getPointerToFunction(llvm::Function*) + 695 16 lli 0x0000000102eb9bfb llvm::JIT::runFunction(llvm::Function*, std::vector<llvm::GenericValue, std::allocator<llvm::GenericValu...

2010/1/22 Duncan Sands <baldrick at free.fr> > Hi James, > > > Yes - sorry I was unclear. I have pruned everything down to a pretty >> minimal test: >> - LLVM 2.6 compiled from source >> - A slightly modified version of Duncan's example ll assembly posted >> earlier >> - A minimal personality function (just a call to fprintf()) in a separate

JIT::runJITOnFunctionUnlocked makes sure that functions referenced by the current function are JIT-ed. In my case, I may be compiling foo(), during which I notice that I need to build bar(), which refers to foo(). The compiler dies JIT-ing foo() because it's not done yet. Specifically, I'm in the middle of generating...

On Aug 27, 2010, at 11:00 AMPDT, Eric Christopher wrote: >>> >>> For some reason I am getting this error even when I only have an >>> empty 'main' function. So I couldn't create .ll file reproducing >>> it and I have to debug myself. >>> >>> The function causing the problem is stub created in >>> JIT::runFunction:

...66c0, F=@0x4530c60) at > /tmp/llvm-svn/llvm/lib/VMCore/PassManager.cpp:1324 > #10 0x0000000802f50500 in llvm::JIT::jitTheFunction (this=0x327a7e0, > F=0x4530c60, locked=@0x7fffffff9840) at > /tmp/llvm-svn/llvm/lib/ExecutionEngine/JIT/JIT.cpp:655 > #11 0x0000000802f5037b in llvm::JIT::runJITOnFunctionUnlocked > (this=0x327a7e0, F=0x4530c60, locked=@0x7fffffff9840) at > /tmp/llvm-svn/llvm/lib/ExecutionEngine/JIT/JIT.cpp:633 > #12 0x0000000802f507e4 in llvm::JIT::getPointerToFunction > (this=0x327a7e0, F=0x4530c60) at > /tmp/llvm-svn/llvm/lib/ExecutionEngine/JIT/JIT.cpp:719 > > >...

Hi Garrison, I am not a specialist of the code but here is my 2 cents: - I like the idea that in lazy-mode the call (in module or not) is treated by a stub (like every calls). - If the jit is in non-lazy mode, I'm not really fan of the "stub" solution. Is it not possible to use the same mechanism as it already exists : add the function to pending list and emit it after the current

...unOnFunction(llvm::Function&) + 362 10 libLLVM-3.4.so 0x00007f1250a464fe llvm::legacy::FunctionPassManagerImpl::run(llvm::Function&) + 238 11 libLLVM-3.4.so 0x00007f1250a4639d llvm::legacy::FunctionPassManager::run(llvm::Function&) + 93 12 libLLVM-3.4.so 0x00007f1250bca1dd llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 45 13 libLLVM-3.4.so 0x00007f1250bca435 llvm::JIT::getPointerToFunction(llvm::Function*) + 261 14 lli 0x0000000000409f95 main + 4437 15 libc.so.6 0x00007f124effcf45 __libc_start_main + 245 16 lli 0x00000000004069bd Sta...

...e been triggered by the > need to output DWARF information for f(). > > -- James > > [snip] > > On 22/01/2010, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: >> 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 >> [snip]