[llvm] [RISCV] Fold (vslide1up undef, v, (extract_elt x, 0)) into (vslideup x, v, 1) (PR #154847)

Min-Yih Hsu via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 3 11:11:32 PDT 2025


================
@@ -21151,6 +21151,36 @@ SDValue RISCVTargetLowering::PerformDAGCombine(SDNode *N,
       return N->getOperand(0);
     break;
   }
+  case RISCVISD::VSLIDE1UP_VL:
+  case RISCVISD::VFSLIDE1UP_VL: {
+    using namespace SDPatternMatch;
+    SDValue SrcVec;
+    SDLoc DL(N);
+    MVT VT = N->getSimpleValueType(0);
+    // If the scalar we're sliding in was extracted from the first element of a
+    // vector, we can use that vector as the passthru in a normal slideup of 1.
+    // This saves us an extract_element instruction (i.e. vfmv.f.s, vmv.x.s).
+    if (N->getOperand(0).isUndef() &&
+        sd_match(N->getOperand(2),
+                 m_AnyOf(m_ExtractElt(m_Value(SrcVec), m_Zero()),
----------------
mshockwave wrote:

> say a i32 vector to a i64 scalar, I think an additional zext SDNode will be applied on that i64 before any use.

Well, I was only half-right about that: for extractelt generated from IR or any normal ways, that's the case. But for extractelt generated during legalization no additional zext/sext would be added because they're subject to be lowered into vmv.x.s which sign-extends its result.
I, therefore, added a check to make sure the element type of SrcVecis the same as that of vslide1up

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


More information about the llvm-commits mailing list