Shivram Khandeparker
2010-Jun-10 07:18 UTC
[LLVMdev] Assertion failure in llc when using exception handling
Hi, I'm trying to compile an llvm program which makes use of exception handling. While compiling the code with llc i get the following assertion failure llc: FunctionLoweringInfo.cpp:163: void llvm::FunctionLoweringInfo::clear(): Assertion `CatchInfoFound.size() == CatchInfoLost.size() && "Not all catch info was assigned to a landing pad!"' failed. 0 llc 0x0000000000d5d23f 1 llc 0x0000000000d5f026 2 libpthread.so.0 0x00007f47688d38f0 3 libc.so.6 0x00007f4767bc3a75 gsignal + 53 4 libc.so.6 0x00007f4767bc75c0 abort + 384 5 libc.so.6 0x00007f4767bbc941 __assert_fail + 241 6 llc 0x00000000008a5a19 llvm::FunctionLoweringInfo::clear() + 1353 7 llc 0x00000000009364de llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 3102 8 llc 0x0000000000ce828f llvm::FPPassManager::runOnFunction(llvm::Function&) + 671 9 llc 0x0000000000ce834b llvm::FPPassManager::runOnModule(llvm::Module&) + 75 10 llc 0x0000000000ce7d84 llvm::MPPassManager::runOnModule(llvm::Module&) + 564 11 llc 0x0000000000ce7ee0 llvm::PassManagerImpl::run(llvm::Module&) + 160 12 llc 0x0000000000565941 main + 3009 13 libc.so.6 0x00007f4767baec4d __libc_start_main + 253 14 llc 0x0000000000563849 Stack dump: 0. Program arguments: llc b.bc 1. Running pass 'Function Pass Manager' on module 'b.bc'. 2. Running pass 'X86 DAG->DAG Instruction Selection' on function '@main' Aborted I only get this error when the b.bc file is generated with opt -O3. The program compiles and executes just fine with opt -O2. I was able to find out the minimum number of optimization passes that cause this crash. They are opt -inline -jump-threading -instcombine -licm -loop-unswitch -o b.bc a.bc I'm attaching the original unoptimized file a.bc.gz and the optimized version b.bc.gz. I apologize for sending in such large files, but I just couldn't reproduce this problem with smaller programs. By putting some debug statements in llc I was able to narrow the problem in b.bc down to following lines of code Unwind.i74.i.i: ; preds %normal44.i79.i.i %153 = call i8* @llvm.eh.exception() ; <i8*> [#uses=2] %154 = call i32 (i8*, i8*, ...)* @llvm.eh.selector(i8* %153, i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*), i8* null) ; <i32> [#uses=0] invoke void @_Unwind_Resume_or_Rethrow(i8* %153) to label %.noexc83.i.i unwind label %lpad51.preheader.i.i lpad51.preheader.i.i: ; preds = %Unwind.i74.i.i, %Unwind.i61.i.i %155 = icmp eq i8* %58, null ; <i1> [#uses=1] %156 = bitcast i8* %61 to %File* ; <%File*> [#uses=1] br i1 %155, label %Unwind.loopexit.us-lcssa.us.i.i, label %normal31.i.i.i Unwind.loopexit.us-lcssa.us.i.i: ; preds %lpad51.preheader.i.i %157 = call i8* @llvm.eh.exception() ; <i8*> [#uses=2] %158 = call i32 (i8*, i8*, ...)* @llvm.eh.selector(i8* %157, i8* bitcast (i32 (...)* @__gxx_personality_v0 to i8*), i8* null) ; <i32> [#uses=0] br label %Unwind.i.i The Unwind.loopexit.us-lcssa.us.i.i landing pad gets added to CatchInfoLost but not to CatchInfoFound which causes the assertion to fail. I have also attached the output from bugpoint -run-llc b.bc Is there something wrong with the original ll code I am generating? I will be glad to provide more information. Thanks, Shivram -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100610/40efc586/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: a.bc.gz Type: application/x-gzip Size: 55178 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100610/40efc586/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: b.bc.gz Type: application/x-gzip Size: 12469 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100610/40efc586/attachment-0001.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: bugpoint-reduced-simplified.bc Type: application/octet-stream Size: 1188 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100610/40efc586/attachment.obj>
Duncan Sands
2010-Jun-10 08:28 UTC
[LLVMdev] Assertion failure in llc when using exception handling
Hi Shivram,> I'm trying to compile an llvm program which makes use of exception > handling. While compiling the code with llc i get the following > assertion failurean unfortunate weakness of the code generators is that they require calls to eh.selector to be in a landing pad (landing pad = where an invoke unwinds to). They can also handle some simple cases when the selector call is outside the landing pad. In practice, as long as the original call to eh.selector that you generate is in a landing pad, and at the start of the landing pad (just after the eh.exception call and any phi nodes) it is intended that the current logic is good enough to handle any situations caused by optimization. Was the original call at the start of a landing pad? By the way, there are various ways of fixing this codegen problem. But since there is a plan to redesign exception handling in LLVM, it seems pointless to spend much time on it. Ciao, Duncan.
Shivram Khandeparker
2010-Jun-10 10:13 UTC
[LLVMdev] Assertion failure in llc when using exception handling
Forgot to reply all. Duncan suggested that I put the selector call before the store but that didn't help. I get the same assertion failure. On Thu, Jun 10, 2010 at 2:50 PM, Shivram Khandeparker <shivramk at gmail.com>wrote:> HI Duncan, > > On Thu, Jun 10, 2010 at 1:58 PM, Duncan Sands <baldrick at free.fr> wrote: > >> an unfortunate weakness of the code generators is that they require calls >> to >> eh.selector to be in a landing pad (landing pad = where an invoke unwinds >> to). They can also handle some simple cases when the selector call is >> outside >> the landing pad. In practice, as long as the original call to eh.selector >> that >> you generate is in a landing pad, and at the start of the landing pad >> (just >> after the eh.exception call and any phi nodes) it is intended that the >> current >> logic is good enough to handle any situations caused by optimization. Was >> the >> original call at the start of a landing pad? >> > > I am aware of this. All of the landing pads in my original code look like > the following > > lpad: ; preds = %return7 > %46 = call i8* @llvm.eh.exception() ; <i8*> [#uses=2] > store i8* %46, i8** %22 > %47 = call i32 (i8*, i8*, ...)* @llvm.eh.selector(i8* %46, i8* bitcast > (i32 (...)* @__gxx_personality_v0 to i8*), i8* null) ; <i32> [#uses=0] > br label %destructor > > eh.selector always follows the eh.exception call and the store. > > >> By the way, there are various ways of fixing this codegen problem. But >> since >> there is a plan to redesign exception handling in LLVM, it seems pointless >> to >> spend much time on it. >> > > It would be great if you could suggest a workaround till exception handling > in LLVM gets redesigned. I would really like to get this working as soon as > possible. > > Regards, > Shivram >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100610/f922f553/attachment.html>
Duncan Sands
2010-Jun-10 10:32 UTC
[LLVMdev] Assertion failure in llc when using exception handling
Hi Shivram,> lpad: ; preds = %return7 > %46 = call i8* @llvm.eh.exception() ; <i8*> [#uses=2] > store i8* %46, i8** %22 > %47 = call i32 (i8*, i8*, ...)* @llvm.eh.selector(i8* %46, i8* > bitcast (i32 (...)* @__gxx_personality_v0 to i8*), i8* null) ; <i32> > [#uses=0] > > > try putting eh.selector call before the store. > > > Tried. The optimized code looks a little different now but I'm getting > the same assert failure in llc.please open a bugreport. Best wishes, Duncan. PS: Fixing this propoerly in the code generator is a lot of work. The reason it is a lot of work (rather than trivial, like in gcc) is due to the design of exception handling in LLVM. PPS: Please don't forget to send replies to the mailing list.
Kenneth Uildriks
2010-Jun-10 13:02 UTC
[LLVMdev] Assertion failure in llc when using exception handling
On Thu, Jun 10, 2010 at 3:28 AM, Duncan Sands <baldrick at free.fr> wrote:> Hi Shivram, > >> I'm trying to compile an llvm program which makes use of exception >> handling. While compiling the code with llc i get the following >> assertion failure > > an unfortunate weakness of the code generators is that they require calls to > eh.selector to be in a landing pad (landing pad = where an invoke unwinds > to). They can also handle some simple cases when the selector call is outside > the landing pad. In practice, as long as the original call to eh.selector that > you generate is in a landing pad, and at the start of the landing pad (just > after the eh.exception call and any phi nodes) it is intended that the current > logic is good enough to handle any situations caused by optimization. Was the > original call at the start of a landing pad? > > By the way, there are various ways of fixing this codegen problem. But since > there is a plan to redesign exception handling in LLVM, it seems pointless to > spend much time on it.Is the plan still as specified in http://www.nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt? Is there a particular person or persons considered highly likely to work on it at a roughly known time? (I wish I had the time and knowledge to knock it out myself...) I have been putting off implementing exception handling in my front end, and would like to know whether to continue putting it off. Also, a more general question: is exception handling (in the hardware/OS) more or less universally supported across LLVM target platforms?
Reasonably Related Threads
- [LLVMdev] "Not all catch info was assigned to a landing pad!"' failed
- [LLVMdev] "Not all catch info was assigned to a landing pad!"' failed
- [LLVMdev] ARM and lowerinvoke
- [LLVMdev] ARM and lowerinvoke
- [LLVMdev] ExtractBasicBlock() on block that ends with invoke or unreachable triggers assert() in llc