[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