[PATCH] [X86][SSE] Improve matching of SSE blend instructions with splatted vector inputs

[Chandler Carruth]

I generally think this entire thing should be handled in the target-independent dag combiner. We should always canonicalize a splat-like shuffle into a buildvector that is obviously a splat. And we should always canonicalize a shuffle of such a buildvector into a blend IMO.

At the very least, I'd prefer to see these at x86 DAG combines rather than doing it in the lowering unless (as mentioned below) you have test cases where the pattern only emerges while lowering.


REPOSITORY
  rL LLVM

================
Comment at: lib/Target/X86/X86ISelLowering.cpp:7366-7369
@@ +7365,6 @@
+    if (auto *BVOp = dyn_cast<BuildVectorSDNode>(V.getNode())) {
+      if (BVOp->getConstantSplatNode(&UndefElements) && UndefElements.none())
+        return true;
+      if (BVOp->getConstantFPSplatNode(&UndefElements) && UndefElements.none())
+        return true;
+    }
----------------
Why are only constants safe here? Shouldn't it be any buildvector of a single scalar SDValue without undefs?

I also could have sworn there was already a predicate for this...

================
Comment at: lib/Target/X86/X86ISelLowering.cpp:7372-7376
@@ +7371,7 @@
+    if (auto *SVNOp = dyn_cast<ShuffleVectorSDNode>(V.getNode())) {
+      ArrayRef<int> SVNMask = SVNOp->getMask();
+      for (int i = 0, Size = SVNMask.size(); i < Size; ++i)
+        if (SVNMask[i] < 0 || SVNMask[i] != SVNMask[0])
+          return false;
+      return true;
+    }
----------------
If we fail to turn this kind of shuffle vector into a buildvector splat, we should fix that in the target independent dag combining, no?

The only time I've been  unable to do this is when the pattern didn't emerge until *during* lowering. Do you have test cases showing that?

http://reviews.llvm.org/D6652

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/