1. Fix the widening of SETCC in WidenVecOp_SETCC. Use the correct return CC type.
authorNadav Rotem <nadav.rotem@intel.com>
Fri, 21 Oct 2011 11:42:07 +0000 (11:42 +0000)
committerNadav Rotem <nadav.rotem@intel.com>
Fri, 21 Oct 2011 11:42:07 +0000 (11:42 +0000)
2. Fix a typo in CONCAT_VECTORS which exposed the bug in #1.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142648 91177308-0d34-0410-b5e6-96231b3b80d8

lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp
lib/CodeGen/SelectionDAG/LegalizeTypes.h
lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
test/CodeGen/X86/2011-10-21-widen-cmp.ll [new file with mode: 0644]

index a5c4c2ded4c56ef7eb00763117d2c8926615a33c..455307197c547b55b34905a28ae603374892aa42 100644 (file)
@@ -2926,7 +2926,7 @@ SDValue DAGTypeLegalizer::PromoteIntRes_SCALAR_TO_VECTOR(SDNode *N) {
 SDValue DAGTypeLegalizer::PromoteIntRes_CONCAT_VECTORS(SDNode *N) {
   DebugLoc dl = N->getDebugLoc();
 
-  SDValue Op0 = N->getOperand(1);
+  SDValue Op0 = N->getOperand(0);
   SDValue Op1 = N->getOperand(1);
   assert(Op0.getValueType() == Op1.getValueType() &&
          "Invalid input vector types");
index 0a8db0897b5bb28db21a99f383d96039c4718114..69c210000156a4d2a0dfaf611cd98695392d4c84 100644 (file)
@@ -633,7 +633,7 @@ private:
   SDValue WidenVecOp_EXTRACT_VECTOR_ELT(SDNode *N);
   SDValue WidenVecOp_EXTRACT_SUBVECTOR(SDNode *N);
   SDValue WidenVecOp_STORE(SDNode* N);
-  SDValue WidenVecOp_SETCC(SDNode* N, unsigned ResNo);
+  SDValue WidenVecOp_SETCC(SDNode* N);
 
   SDValue WidenVecOp_Convert(SDNode *N);
 
index 7fc7525a5b90d9fbb122d0e1ce644b478f42c121..e950e072bc78e45abda272dd0558f5afdaffcba6 100644 (file)
@@ -2033,7 +2033,7 @@ bool DAGTypeLegalizer::WidenVectorOperand(SDNode *N, unsigned ResNo) {
   case ISD::EXTRACT_SUBVECTOR:  Res = WidenVecOp_EXTRACT_SUBVECTOR(N); break;
   case ISD::EXTRACT_VECTOR_ELT: Res = WidenVecOp_EXTRACT_VECTOR_ELT(N); break;
   case ISD::STORE:              Res = WidenVecOp_STORE(N); break;
-  case ISD::SETCC:              Res = WidenVecOp_SETCC(N, ResNo); break;
+  case ISD::SETCC:              Res = WidenVecOp_SETCC(N); break;
 
   case ISD::FP_EXTEND:
   case ISD::FP_TO_SINT:
@@ -2167,27 +2167,30 @@ SDValue DAGTypeLegalizer::WidenVecOp_STORE(SDNode *N) {
                        MVT::Other,&StChain[0],StChain.size());
 }
 
-SDValue DAGTypeLegalizer::WidenVecOp_SETCC(SDNode *N, unsigned ResNo) {
-  assert(ResNo < 2 && "Invalid res num to widen");
+SDValue DAGTypeLegalizer::WidenVecOp_SETCC(SDNode *N) {
   SDValue InOp0 = GetWidenedVector(N->getOperand(0));
   SDValue InOp1 = GetWidenedVector(N->getOperand(1));
-  EVT VT = InOp0.getValueType();
   DebugLoc dl = N->getDebugLoc();
 
   // WARNING: In this code we widen the compare instruction with garbage.
   // This garbage may contain denormal floats which may be slow. Is this a real
   // concern ? Should we zero the unused lanes if this is a float compare ?
 
-  SDValue Zero = DAG.getIntPtrConstant(0);
-  EVT ResVT = EVT::getVectorVT(*DAG.getContext(),
-                               N->getValueType(0).getVectorElementType(),
-                               VT.getVectorNumElements());
-
+  // Get a new SETCC node to compare the newly widened operands.
+  // Only some of the compared elements are legal.
+  EVT SVT = TLI.getSetCCResultType(InOp0.getValueType());
   SDValue WideSETCC = DAG.getNode(ISD::SETCC, N->getDebugLoc(),
-                     ResVT, InOp0, InOp1, N->getOperand(2));
+                     SVT, InOp0, InOp1, N->getOperand(2));
+
+  // Extract the needed results from the result vector.
+  EVT ResVT = EVT::getVectorVT(*DAG.getContext(),
+                               SVT.getVectorElementType(),
+                               N->getValueType(0).getVectorNumElements());
+  SDValue CC = DAG.getNode(ISD::EXTRACT_SUBVECTOR, dl,
+                           ResVT, WideSETCC, DAG.getIntPtrConstant(0));
 
-  return DAG.getNode(ISD::EXTRACT_SUBVECTOR, dl, N->getValueType(0),
-                     WideSETCC, Zero);
+  // Convert the result mask to the correct kind.
+  return DAG.getAnyExtOrTrunc(CC, dl, N->getValueType(0));
 }
 
 
diff --git a/test/CodeGen/X86/2011-10-21-widen-cmp.ll b/test/CodeGen/X86/2011-10-21-widen-cmp.ll
new file mode 100644 (file)
index 0000000..aa1a600
--- /dev/null
@@ -0,0 +1,30 @@
+; RUN: llc < %s -march=x86-64 -mcpu=corei7 | FileCheck %s
+
+target triple = "x86_64-unknown-linux-gnu"
+
+; Check that a <4 x float> compare is generated and that we are
+; not stuck in an endless loop.
+
+; CHECK: cmp_2_floats
+; CHECK: cmpordps
+; CHECK: ret
+
+define void @cmp_2_floats() {
+entry:
+  %0 = fcmp oeq <2 x float> undef, undef
+  %1 = select <2 x i1> %0, <2 x float> undef, <2 x float> undef
+  store <2 x float> %1, <2 x float>* undef
+  ret void
+}
+
+; CHECK: cmp_2_doubles
+; CHECK: cmpordpd
+; CHECK: blendvpd
+; CHECK: ret
+define void @cmp_2_doubles() {
+entry:
+  %0 = fcmp oeq <2 x double> undef, undef
+  %1 = select <2 x i1> %0, <2 x double> undef, <2 x double> undef
+  store <2 x double> %1, <2 x double>* undef
+  ret void
+}