================
@@ -194,15 +194,12 @@ define void @vpmerge_vpload_store(<vscale x 2 x i32>
%passthru, ptr %p, <vscale
ret void
}
-; FIXME: Merge vmerge.vvm and vleffN.v
declare { <vscale x 2 x i32>, i64 } @llvm.riscv.vleff.nxv2i32(<vscale x 2 x
i32>, ptr, i64)
define <vscale x 2 x i32> @vpmerge_vleff(<vscale x 2 x i32> %passthru, ptr %p,
<vscale x 2 x i1> %m, i32 zeroext %vl) {
; CHECK-LABEL: vpmerge_vleff:
; CHECK: # %bb.0:
-; CHECK-NEXT: vsetvli zero, a1, e32, m1, ta, ma
-; CHECK-NEXT: vle32ff.v v9, (a0)
-; CHECK-NEXT: vsetvli zero, a1, e32, m1, tu, ma
-; CHECK-NEXT: vmerge.vvm v8, v8, v9, v0
+; CHECK-NEXT: vsetvli zero, a1, e32, m1, tu, mu
+; CHECK-NEXT: vle32ff.v v8, (a0), v0.t
----------------
topperc wrote:
I'm trying to decide if this is correct. It's certainly a weird test case. You
would normally want the vp.merge to use vl produced by vleff.
If the VL gets trimmed by the vleff, the elements between the input VL and the
trimmed VL are undefined if the mask bit for those elements are non-zero. The
spec allows hardware to write the active elements past the trimmed VL to any
value.
I think we're ok here. If vleff trims any elements they would be undefined in
`%b`. The vp.merge would propagate them if the mask bit is non-zero. If the
mask is 0 the vp.merge would replace them with passthru. That seems to be what
the combined vp.merge would do.
https://github.com/llvm/llvm-project/pull/90049
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
