[llvm-branch-commits] [RISCV] Remove hasSideEffects=1 for saturating/fault-only-first instructions (PR #90049)

[Craig Topper via llvm-branch-commits]

================
@@ -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