maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Analysis/ValueTracking/select-pattern.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

50 lines
1.0 KiB
LLVM
Raw Normal View History

[NFC] Update test checks llvm-svn: 361695
2019-05-25 21:11:22 +08:00
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
[ValueTracking] add recursion depth param to matchSelectPattern We're getting bug reports: https://bugs.llvm.org/show_bug.cgi?id=35807 https://bugs.llvm.org/show_bug.cgi?id=35840 https://bugs.llvm.org/show_bug.cgi?id=36045 ...where we blow up the stack in value tracking because other passes are sending in selects that have an operand that is itself the select. We don't currently have a reliable way to avoid analyzing dead code that may take non-standard forms, so bail out when things go too far. This mimics the recursion depth limitations in other parts of value tracking. Unfortunately, this pushes the underlying problems for other passes (jump-threading, simplifycfg, correlated-propagation) into hiding. If someone wants to uncover those again, the first draft of this patch on Phab would do that (it would assert rather than bail out). Differential Revision: https://reviews.llvm.org/D42442 llvm-svn: 323331
2018-01-24 23:20:37 +08:00
; RUN: opt -simplifycfg < %s -S | FileCheck %s
; The dead code would cause a select that had itself
; as an operand to be analyzed. This would then cause
; infinite recursion and eventual crash.
define void @PR36045(i1 %t, i32* %b) {
; CHECK-LABEL: @PR36045(
; CHECK-NEXT: entry:
[SimplifyCFG] Added condition assumption for unreachable blocks Summary: PR41688 Reviewers: spatel, efriedma, craig.topper, hfinkel, reames Reviewed By: hfinkel Subscribers: javed.absar, dmgreen, fhahn, hfinkel, reames, nikic, lebedev.ri, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61409 llvm-svn: 361707
2019-05-26 06:34:27 +08:00
; CHECK-NEXT: [[TMP0:%.*]] = xor i1 [[T:%.*]], true
; CHECK-NEXT: call void @llvm.assume(i1 [[TMP0]])
[ValueTracking] add recursion depth param to matchSelectPattern We're getting bug reports: https://bugs.llvm.org/show_bug.cgi?id=35807 https://bugs.llvm.org/show_bug.cgi?id=35840 https://bugs.llvm.org/show_bug.cgi?id=36045 ...where we blow up the stack in value tracking because other passes are sending in selects that have an operand that is itself the select. We don't currently have a reliable way to avoid analyzing dead code that may take non-standard forms, so bail out when things go too far. This mimics the recursion depth limitations in other parts of value tracking. Unfortunately, this pushes the underlying problems for other passes (jump-threading, simplifycfg, correlated-propagation) into hiding. If someone wants to uncover those again, the first draft of this patch on Phab would do that (it would assert rather than bail out). Differential Revision: https://reviews.llvm.org/D42442 llvm-svn: 323331
2018-01-24 23:20:37 +08:00
; CHECK-NEXT: ret void
;
entry:
br i1 %t, label %if, label %end
if:
br i1 %t, label %unreach, label %pre
unreach:
unreachable
pre:
%p = phi i32 [ 70, %if ], [ %sel, %for ]
br label %for
for:
%cmp = icmp sgt i32 %p, 8
%add = add i32 %p, 2
%sel = select i1 %cmp, i32 %p, i32 %add
%cmp21 = icmp ult i32 %sel, 21
br i1 %cmp21, label %pre, label %for.end
for.end:
br i1 %t, label %unreach2, label %then12
then12:
store i32 0, i32* %b
br label %unreach2
unreach2:
%spec = phi i32 [ %sel, %for.end ], [ 42, %then12 ]
unreachable
end:
ret void
}