Re-apply r73718, now that the fix in r73787 is in, and add a
hand-crafted testcase which demonstrates the bug that was exposed
in 254.gap.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73793 91177308-0d34-0410-b5e6-96231b3b80d8
diff --git a/test/CodeGen/X86/optimize-max-2.ll b/test/CodeGen/X86/optimize-max-2.ll
new file mode 100644
index 0000000..effc3fc
--- /dev/null
+++ b/test/CodeGen/X86/optimize-max-2.ll
@@ -0,0 +1,30 @@
+; RUN: llvm-as < %s | llc -march=x86-64 > %t
+; RUN: grep cmov %t | count 2
+; RUN: grep jne %t | count 1
+
+; LSR's OptimizeMax function shouldn't try to eliminate this max, because
+; it has three operands.
+
+target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128"
+
+define void @foo(double* nocapture %p, i64 %x, i64 %y) nounwind {
+entry:
+ %tmp = icmp eq i64 %y, 0 ; <i1> [#uses=1]
+ %umax = select i1 %tmp, i64 1, i64 %y ; <i64> [#uses=2]
+ %tmp8 = icmp ugt i64 %umax, %x ; <i1> [#uses=1]
+ %umax9 = select i1 %tmp8, i64 %umax, i64 %x ; <i64> [#uses=1]
+ br label %bb4
+
+bb4: ; preds = %bb4, %entry
+ %i.07 = phi i64 [ 0, %entry ], [ %2, %bb4 ] ; <i64> [#uses=2]
+ %scevgep = getelementptr double* %p, i64 %i.07 ; <double*> [#uses=2]
+ %0 = load double* %scevgep, align 8 ; <double> [#uses=1]
+ %1 = fmul double %0, 2.000000e+00 ; <double> [#uses=1]
+ store double %1, double* %scevgep, align 8
+ %2 = add i64 %i.07, 1 ; <i64> [#uses=2]
+ %exitcond = icmp eq i64 %2, %umax9 ; <i1> [#uses=1]
+ br i1 %exitcond, label %return, label %bb4
+
+return: ; preds = %bb4
+ ret void
+}