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