]> granicus.if.org Git - llvm/commitdiff
[x86] avoid adc/sbb assert when both sides of add are zexted (PR32316)
authorSanjay Patel <spatel@rotateright.com>
Fri, 17 Mar 2017 17:27:31 +0000 (17:27 +0000)
committerSanjay Patel <spatel@rotateright.com>
Fri, 17 Mar 2017 17:27:31 +0000 (17:27 +0000)
As noted in the comment, we might want to account for this case,
but I didn't look at what that would mean for the asm.

I'm also not sure why this only reproduces with avx512, but I'm
putting a conservative fix in for now to avoid the crash.

Also, if both sides of an add are zexted, shouldn't we shrink that add?

https://bugs.llvm.org/show_bug.cgi?id=32316

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

lib/Target/X86/X86ISelLowering.cpp
test/CodeGen/X86/avx512-adc-sbb.ll [new file with mode: 0644]

index 63a69f54be2b3953699044a82f8c91bf41bec9b1..a7e82493b1f25e7d5a5112f7e3c4e2fc5608951e 100644 (file)
@@ -34266,12 +34266,16 @@ static SDValue combineAddOrSubToADCOrSBB(SDNode *N, SelectionDAG &DAG) {
     std::swap(X, Y);
 
   // Look through a one-use zext.
-  if (Y.getOpcode() == ISD::ZERO_EXTEND && Y.hasOneUse())
+  bool PeekedThroughZext = false;
+  if (Y.getOpcode() == ISD::ZERO_EXTEND && Y.hasOneUse()) {
     Y = Y.getOperand(0);
+    PeekedThroughZext = true;
+  }
 
   // If this is an add, canonicalize a setcc operand to the RHS.
   // TODO: Incomplete? What if both sides are setcc?
-  if (!IsSub && X.getOpcode() == X86ISD::SETCC &&
+  // TODO: Should we allow peeking through a zext of the other operand?
+  if (!IsSub && !PeekedThroughZext && X.getOpcode() == X86ISD::SETCC &&
       Y.getOpcode() != X86ISD::SETCC)
     std::swap(X, Y);
 
diff --git a/test/CodeGen/X86/avx512-adc-sbb.ll b/test/CodeGen/X86/avx512-adc-sbb.ll
new file mode 100644 (file)
index 0000000..c994fde
--- /dev/null
@@ -0,0 +1,27 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=x86_64-unknown-unknown -mattr=avx512f %s -o - | FileCheck %s
+
+; This asserted because we didn't account for a zext of a non-SETCC node:
+; https://bugs.llvm.org/show_bug.cgi?id=32316
+
+define i8 @PR32316(i8 %t1, i32 %t5, i8 %t8)  {
+; CHECK-LABEL: PR32316:
+; CHECK:       # BB#0:
+; CHECK-NEXT:    xorl %eax, %eax
+; CHECK-NEXT:    testb %dil, %dil
+; CHECK-NEXT:    sete %al
+; CHECK-NEXT:    cmpl %esi, %eax
+; CHECK-NEXT:    seta %al
+; CHECK-NEXT:    cmpb $1, %dl
+; CHECK-NEXT:    sbbb $-1, %al
+; CHECK-NEXT:    retq
+  %t2 = icmp eq i8 %t1, 0
+  %t3 = zext i1 %t2 to i32
+  %t6 = icmp ugt i32 %t3, %t5
+  %t7 = zext i1 %t6 to i8
+  %t9 = icmp ne i8 %t8, 0
+  %t10 = zext i1 %t9 to i8
+  %t11 = add i8 %t7, %t10
+  ret i8 %t11
+}
+