Running ./llc test.bc results to (bytecode passes verifier): llc: /home/asl/proj/llvm/src/lib/CodeGen/LiveVariables.cpp:157: void llvm::LiveVariables::HandleVirtRegUse(llvm::LiveVariables::VarInfo&, llvm::MachineBasicBlock*, llvm::MachineInstr*): Assertion `VRInfo.DefInst && "Register use before def!"' failed. ./llc((anonymous namespace)::PrintStackTrace()+0x1f)[0x859b96f] /lib/libc.so.6(abort+0xeb)[0xb7d83133] /lib/libc.so.6(__assert_fail+0xeb)[0xb7d7b4f3] ./llc(llvm::LiveVariables::HandleVirtRegUse(llvm::LiveVariables::VarInfo&, llvm::MachineBasicBlock*, llvm::MachineInstr*)+0x13c)[0x842bbec]
Created attachment 509 [details] test.bc bytecode
evan, can you investigate?
This test is huge and bugpoint is having all kinds of trouble with it. Anton, do you have any luck reducing it? It looks like a phi node updating problem though.
Created attachment 511 [details] Somewhat reduced test case
This is bad LLVM code: cond_true.i: ; preds = %meshBB1602 %ov1051 = xor int %cv2693, 29 ; <int> [#uses=4] %ov1408 = xor int %ov1051, 0 ; <int> [#uses=1] %tmp8.i = invoke fastcc uint %_ZN10polynomialIdE11stretch_fftEv( "struct.polynomial<double>"* %a1.i ) to label %meshBB1569 unwind label %cleanup86.i ; <uint> [#uses=2] invcont7.i: ; preds = %meshBB1569 %tmp.i.i3 = seteq uint %tmp8.i, 0 ; <bool> [#uses=1] %ov1039 = xor int %cv2797, 226 ; <int> [#uses=2] br bool %tmp.i.i3, label %cond_next.i, label %cond_true.i.i4 %meshBB1569 is just a bunch of phi node but it does not reference nor define %tmp8.i live variable analysis chokes in invcont7.i because %tmp8.i is used but it is not defined nor live-in. Chris believes this is a verifier bug.
the verifier should reject this: int %foo() { %A = invoke int %foo( ) to label %L unwind label %L ; <int> [#uses=1] L: ; preds = %0, %0 ret int %A } %A does not dominate L.
Here's another case the verifier should reject that crashes livevar: int %foo() { br bool false, label %L1, label %L2 L1: %A = invoke int %foo() to label %L unwind label %L L2: br label %L L: ret int %A }
I've fixed the verifier bug, but the new check exposes bugs in other passes, it will take a while to track these down. -Chris
This is actually a verifier bug not rejecting broken code. Fixed with this patch: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061211/041486.html Testcases here: test/Regression/Verifier/invoke-[12].ll Note that the broken LLVM code was made by some transformation that is buggy. That means that if you try to compile the source that produced this again, you'll get an assert. Please file another bug so we can fix that. Thanks, -Chris
invoke-1.ll is not rejected by verifier. Everything is ok for invoke-2.ll
Fixed with this patch: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061218/041558.html