[PATCH] D11678: [CodeGen] Fixes *absdiff* intrinsic: LangRef doc/test case improvement and corresponding code change

Ahmed Bougacha via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 26 13:38:46 PDT 2015


ab added a subscriber: ab.
ab added a comment.

I'm not a fan of the way the tests are written: they seem both too brittle and too strict.

FWIW, I'd start by using utils/update_llc_test_checks.py, and then refining away the non-ABI-specified registers into regexes.


================
Comment at: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp:726
@@ -725,2 +725,3 @@
   SDLoc dl(Op);
-  SDValue Tmp1, Tmp2, Tmp3, Tmp4;
+  SDValue Sub, Neg, Cmp;
+  SDValue Op0 = Op.getOperand(0);
----------------
Can you define these at the point of initialization instead?

================
Comment at: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp:735
@@ +734,3 @@
+  unsigned NumElt = VT.getVectorNumElements();
+  MVT NVT;
+  if (isUabsdiff) {
----------------
Again, please initialize variables when defining them.

Given line 745, NVT is unnecessary, I think. The block at l736 could just set VT instead.

================
Comment at: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp:737-738
@@ +736,4 @@
+  if (isUabsdiff) {
+    NVT = TLI.getTypeToPromoteTo(ISD::UABSDIFF, EltVT.getSimpleVT());
+    NVT = MVT::getVectorVT(NVT, NumElt);
+    Op0 = DAG.getNode(ISD::ZERO_EXTEND, dl, NVT, Op0);
----------------
This logic is fishy, IMO: it doesn't make sense for targets to set the element type promotion rule, and asking for the promoted vector type might get us a widened version.

What about using:

    VT.widenIntegerVectorElementType(*DAG.getContext());

which sounds like what you want, given that there's no other sensible thing the target could do.

================
Comment at: lib/Target/X86/X86ISelLowering.cpp:318-323
@@ -317,2 +317,8 @@
   // encoding.
+  setOperationAction(ISD::UABSDIFF         , MVT::i8   , Promote);
+  AddPromotedToType (ISD::UABSDIFF         , MVT::i8   , MVT::i16);
+  setOperationAction(ISD::UABSDIFF         , MVT::i16  , Promote);
+  AddPromotedToType (ISD::UABSDIFF         , MVT::i16  , MVT::i32);
+  setOperationAction(ISD::UABSDIFF         , MVT::i32  , Promote);
+  AddPromotedToType (ISD::UABSDIFF         , MVT::i32  , MVT::i64);
   setOperationAction(ISD::CTTZ             , MVT::i8   , Promote);
----------------
This will become unnecessary if you use EVT::widenIntegerVectorElementType above.

================
Comment at: test/CodeGen/X86/absdiff_128.ll:11-12
@@ +10,4 @@
+; CHECK:      punpckldq
+; CHECK-DAG:  movd   %xmm1, [[SRC:%e[a-d]+x]]
+; CHECK-DAG:  movd   %xmm0, [[DST:%e[a-d]+x]]
+; CHECK:      subl [[SRC]], [[DST]]
----------------
The a-d seems too restrictive (what about, say, %r9d?), and '+' seems unnecessary.

================
Comment at: test/CodeGen/X86/absdiff_256.ll:5
@@ +4,3 @@
+
+define <16 x i32> @test_sabsdiff_v16i32_expand(<16 x i32> %a1, <16 x i32> %a2) {
+; CHECK-LABEL: test_sabsdiff_v16i32_expand
----------------
Why test v16i32?  IMHO the output is huge without providing more coverage.

Should this be v16i16 or something?


http://reviews.llvm.org/D11678





More information about the llvm-commits mailing list