[llvm] [InstCombine][RISCV] Convert VPIntrinsics with splat operands to splats (PR #65706)

Michael Maitland via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 11 11:00:20 PDT 2023


================
@@ -729,6 +730,172 @@ bool VectorCombine::foldBitcastShuf(Instruction &I) {
   return true;
 }
 
+/// VP Intrinsics whose vector operands are both splat values may be simplified
+/// into the scalar version of the operation and the result is splatted. This
+/// can lead to scalarization down the line.
+bool VectorCombine::scalarizeVPIntrinsic(VPIntrinsic &VPI) {
+  Value *Op0 = VPI.getArgOperand(0);
+  Value *Op1 = VPI.getArgOperand(1);
+
+  if (!isSplatValue(Op0) || !isSplatValue(Op1))
----------------
michaelmaitland wrote:

> Just to make sure I'm on the same page, I think isSplatValue(Op0) would mean that we would match `(add (add (splat x1), (splat y1)), (add (splat x2), (splat y2)))`

Yes, I agree. The result of the outer add is also a splat.

> getSplatValue would return null on (add (splat x1), (splat y1))

I agree here too. I think we can scalarize in the `isSpaltValue` case which should provide more optimization opportunity.

> I think this patch might already handle that nested case above? Presuming it's iterating from the bottom up.

I also agree here.

I am wondering whether it matters or not whether it is iterating from the bottom up. Consider the hypothetical scenario where it was top down, meaning that the binary (splat) operands were not scalarized. What is to stop this optimization from scalarizing in that case?

https://github.com/llvm/llvm-project/pull/65706


More information about the llvm-commits mailing list