similar to: [LLVMdev] Recursive compilation detected

Hi, I've trying to test a pass with a C version of the 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*):

Sure. I've attached the code for the test pass I wrote, as well as the code and bitcode for the testcase I'm running. All the functionality has been stripped out of the pass, and the pass compiles without a problem, but the error appears when the pass is run. Jeff On Tue, 2 Dec 2008 11:06:44 -0800, Devang Patel <dpatel at apple.com> wrote: > On Dec 2, 2008, at 10:40 AM, Jeff

On Dec 2, 2008, at 10:40 AM, Jeff Yeong-Peng Hao wrote: > > Hi, > > I had a question about this as well. The documentation about > writing a > pass shows an example like what John wrote, calling a function pass > within > a module pass on a per function basis. However, if I code it that > way, I > still get the same error: > > opt:

Hi, I had a question about this as well. The documentation about writing a pass shows an example like what John wrote, calling a function pass within a module pass on a per function basis. However, if I code it that way, I still get the same error: opt: /x/jeffhao/llvm/llvm/include/llvm/PassAnalysisSupport.h:232: AnalysisType& llvm::Pass::getAnalysisID(const llvm::PassInfo*,

Hello, As the title line says, I'm getting assertions on recursive JIT compiation, like this: opt: JIT.cpp:627: void llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, const llvm::MutexGuard&): Assertion `!isAlreadyCodeGenerating && "Error: Recursive compilation detected!"' failed. 0 libLLVM-2.7.so 0x012eb2c8 Stack dump: 0. Program arguments: opt

I edit two files named test.h,test.cpp as follow: ///////////////test.h//////////////////////////////////////////////////////////////// class TestClass { private: int fTotal; public: TestClass(); ~TestClass(); }; ///////////test.cpp///////////////////////////////////////////////////////////////////////////// #include "test.h" TestClass::TestClass() { fTotal = 2; }

I edit two files named test.h,test.cpp as follow: ///////////////test.h////////////////////////////////////////////////////////////////class TestClass { private: int fTotal; public: TestClass(); ~TestClass(); };///////////test.cpp/////////////////////////////////////////////////////////////////////////////#include "test.h" TestClass::TestClass() { fTotal = 2; }

Hello, Platform is RHEL5, GCC 4.2.4, x86-32, and LLVM/LLVM-GCC from subversion (yesterday evening). I'm compiling C code into bitcode, and then executing the bitcode using the JIT compiler (lli). I've managed to reproduce a problem when multiple signals go off around the same time. A sample program is below. The result is the "recursive compilation detected" JIT compiler

I just got the CVS version of LLVM running tonight. On my PowerBook, one of the examples (HowToUseJIT) has an assertion error when I try and run it: Running foo: JIT.cpp:217: failed assertion `!isAlreadyCodeGenerating && "Error: Recursive compilation detected!"' However, when I compile and run the same program on x86 Linux, it runs fine (Running foo: Result: 11). I

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 a result, if the call the

I'd like to get some runtime profile data on my code using LLVM. The various -insert-X-profiling passes seem to add the profiling instrumentation to the code, but how do I actually generate profiling output? It seems like utils/profile.pl can do this, but it uses profile_rt.so which doesn't exist. I can manually compile the runtime directory using make install-bytecode, but it

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 introduced to electronic engineers.

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

Please add a test to http://llvm.org/viewvc/llvm-project/llvm/trunk/unittests/ExecutionEngine/JIT/JITTest.cpp?view=markup verifying that recompileAndRelinkFunction() keeps working. Then 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: >>

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

I think so. It also fails the same way on LLVM trunk from last week. The full backtrace is below. It appears that frame #3 is a compilation of __l_personality() and frame #14 is a compilation of f(). The compilation of __l_personality appears to have been triggered by the need to output DWARF information for f(). -- James #0 0x00007ffff6ed84b5 in *__GI_raise (sig=<value optimised out>) at

Thanks for all the hints everyone. Based on your suggestion, O.J., I've added code to toy.cpp from the tutorial to disassemble. ready> 1+1; ready> movabsq $140737353367568, %rax movsd (%rax), %xmm0 ret Evaluated to 2.000000 ready> Which looks correct by inspection - printing the byte array to stdout and feeding it to llvm-mc offline produces the same code as one would also

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

Hi James, Just wanted to update you. As you implied the problem here is that the personality function has to be jitted before the code that contains the corresponding llvm.eh.selector intrinsic instruction is jitted. I verified this by creating a generated version of the personality function which unless I jitted first, gave me the same error when running the code. Since you are using tools