mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-10-19 11:02:59 +02:00
f9a3ecf57f
Summary: It was detected that the reassociate pass could enter an inifite loop when analysing dead code. Simply skipping to analyse basic blocks that are dead avoids such problems (and as a side effect we avoid spending time on optimising dead code). The solution is using the same Reverse Post Order ordering of the basic blocks when doing the optimisations, as when building the precalculated rank map. A nice side-effect of this solution is that we now know that we only try to do optimisations for blocks with ranked instructions. Fixes https://llvm.org/bugs/show_bug.cgi?id=30818 Reviewers: llvm-commits, davide, eli.friedman, mehdi_amini Subscribers: dberlin Differential Revision: https://reviews.llvm.org/D26154 llvm-svn: 285793
38 lines
921 B
LLVM
38 lines
921 B
LLVM
; RUN: opt < %s -reassociate -disable-output
|
|
|
|
; It has been detected that dead loops like the one in this test case can be
|
|
; created by -jump-threading (it was detected by a csmith generated program).
|
|
;
|
|
; According to -verify this is valid input (even if it could be discussed if
|
|
; the dead loop really satisfies SSA form).
|
|
;
|
|
; The problem found was that the -reassociate pass ends up in an infinite loop
|
|
; when analysing the 'deadloop1' basic block. See "Bugzilla - Bug 30818".
|
|
define void @deadloop1() {
|
|
br label %endlabel
|
|
|
|
deadloop1:
|
|
%1 = xor i32 %2, 7
|
|
%2 = xor i32 %1, 8
|
|
br label %deadloop1
|
|
|
|
endlabel:
|
|
ret void
|
|
}
|
|
|
|
|
|
; Another example showing that dead code could result in infinite loops in
|
|
; reassociate pass. See "Bugzilla - Bug 30818".
|
|
define void @deadloop2() {
|
|
br label %endlabel
|
|
|
|
deadloop2:
|
|
%1 = and i32 %2, 7
|
|
%2 = and i32 %3, 8
|
|
%3 = and i32 %1, 6
|
|
br label %deadloop2
|
|
|
|
endlabel:
|
|
ret void
|
|
}
|