loop-rotate doesn't correctly update analysis info

[nlewycky]

Bugzilla Link	1542
Resolution	FIXED
Resolved on	Feb 22, 2010 12:46
Version	trunk
OS	Linux
Blocks	#1692
Attachments	testcase

Extended Description

The attached is a miscompile was reduced by bugpoint. Run "opt
bugpoint-tooptimize.bc -loop-rotate -licm -lcssa" to reproduce.

I strongly recommend that anyone trying to visualize what's going on use opt
--print-cfg on the before and after.

The problem is in the optimization of the bb38 and bb32 loop. This sequence in
bb32 is clearly decrementing a value:

%tmp36 = load i32* %tmp5
%tmp37 = sub i32 %tmp36, 1
store i32 %tmp37, i32* %tmp5

however in the optimized code, the load of %tmp5 is hoisted into bb.nph outside
the loop (%tmp5.promoted).

[nlewycky]

Actually, hoisting it out of the loop is not, alone, buggy behaviour. The output
program doesn't have a phi node in cond_true43 to choose the %tmp5.promoted the
first time and %tmp37 (the value subtracted by 1) each run through the loop.

It's transformed a finite loop into an infinite loop.

[nlewycky]

Also, if you run "opt -loop-rotate | opt -licm | opt -lcssa" you get a different
output that does have the needed phi nodes.

Therefore, some pass is not properly updating its analysis or is claiming to
maintain an analysis it doesn't.

[nlewycky]

Devang, I've reverted LoopRotate.cpp r37953, your fix to #1692 and this bug
disappears.

[llvmbot]

Nick,

In your test case cond_next has no predecessors. Is this expected ?

cond_next: ; No predecessors!
br label %bb44

[nlewycky]

It's bugpoint output, so it's expected. In the code before bugpoint, that block
would've had predecessors. :) I have no idea why bugpoint didn't remove it
though. Perhaps the bug doesn't occur without it?

[llvmbot]

Fixed.

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070709/051774.html