[llvm] [RISCV] Handle undef passthrus in foldVMV_V_V (PR #106943)

Philip Reames via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 3 08:38:16 PDT 2024


================
@@ -194,3 +194,14 @@ define <vscale x 2 x i32> @unfoldable_mismatched_sew(<vscale x 2 x i32> %passthr
   %b = call <vscale x 2 x i32> @llvm.riscv.vmv.v.v.nxv2i32(<vscale x 2 x i32> %passthru, <vscale x 2 x i32> %a.bitcast, iXLen %avl)
   ret <vscale x 2 x i32> %b
 }
+
+define <vscale x 1 x i64> @undef_passthru(<vscale x 1 x i64> %passthru, <vscale x 1 x i64> %x, <vscale x 1 x i64> %y, iXLen %avl) {
+; CHECK-LABEL: undef_passthru:
+; CHECK:       # %bb.0:
+; CHECK-NEXT:    vsetvli zero, a0, e64, m1, tu, ma
+; CHECK-NEXT:    vadd.vv v8, v9, v10
+; CHECK-NEXT:    ret
+  %a = call <vscale x 1 x i64> @llvm.riscv.vadd.nxv1i64.nxv1i64(<vscale x 1 x i64> %passthru, <vscale x 1 x i64> %x, <vscale x 1 x i64> %y, iXLen %avl)
----------------
preames wrote:

Does this actually hold?  Consider:
SrcVL = 2, so elements 0, 1 come from either x or y, but 2 onwards come from passthru
MIVL = 4, so elements 0, 1 come from either x or y, elements 2, 3 come from passthru, and elements 4+ are undefined

Oh, I see it.  You're not changing passthru or VL on Src, you're basically just dropping MI.

I think this might be cleaner if expressed as an early continue here.  This is arguably a different combine entirely.  You're basically just using properties of the vmv.v.v itself to prove it can be elided entirely.  Actually, now that I say that, yeah, this really doesn't depend on Src at all does it?  I don't think you even need the single use condition.  

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


More information about the llvm-commits mailing list