1*cee313d2SEric Christopher; RUN: opt < %s -reassociate -disable-output
2*cee313d2SEric Christopher
3*cee313d2SEric Christopher; It has been detected that dead loops like the one in this test case can be
4*cee313d2SEric Christopher; created by -jump-threading (it was detected by a csmith generated program).
5*cee313d2SEric Christopher;
6*cee313d2SEric Christopher; According to -verify this is valid input (even if it could be discussed if
7*cee313d2SEric Christopher; the dead loop really satisfies SSA form).
8*cee313d2SEric Christopher;
9*cee313d2SEric Christopher; The problem found was that the -reassociate pass ends up in an infinite loop
10*cee313d2SEric Christopher; when analysing the 'deadloop1' basic block. See "Bugzilla - Bug 30818".
11*cee313d2SEric Christopherdefine void @deadloop1() {
12*cee313d2SEric Christopher  br label %endlabel
13*cee313d2SEric Christopher
14*cee313d2SEric Christopherdeadloop1:
15*cee313d2SEric Christopher  %1 = xor i32 %2, 7
16*cee313d2SEric Christopher  %2 = xor i32 %1, 8
17*cee313d2SEric Christopher  br label %deadloop1
18*cee313d2SEric Christopher
19*cee313d2SEric Christopherendlabel:
20*cee313d2SEric Christopher  ret void
21*cee313d2SEric Christopher}
22*cee313d2SEric Christopher
23*cee313d2SEric Christopher
24*cee313d2SEric Christopher; Another example showing that dead code could result in infinite loops in
25*cee313d2SEric Christopher; reassociate pass. See "Bugzilla - Bug 30818".
26*cee313d2SEric Christopherdefine void @deadloop2() {
27*cee313d2SEric Christopher  br label %endlabel
28*cee313d2SEric Christopher
29*cee313d2SEric Christopherdeadloop2:
30*cee313d2SEric Christopher  %1 = and i32 %2, 7
31*cee313d2SEric Christopher  %2 = and i32 %3, 8
32*cee313d2SEric Christopher  %3 = and i32 %1, 6
33*cee313d2SEric Christopher  br label %deadloop2
34*cee313d2SEric Christopher
35*cee313d2SEric Christopherendlabel:
36*cee313d2SEric Christopher  ret void
37*cee313d2SEric Christopher}
38