[RISCV] Optimize the AVL of vleNff.v/clarify if we need to preserve vl output

[lukel97]

In RISCVVLOptimizer we currently don't reduce the AVL of vleNff.v.

#121705 originally proposed to handle it, but in the review I argued that this would affect the output vl: #121705 (comment)

However I think I was wrong here, since I recently realised that after #90049 we actually fold vmerge.vvm masks into vleNff.v, e.g.

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, tu, mu
; CHECK-NEXT:    vle32ff.v v8, (a0), v0.t
; CHECK-NEXT:    ret
  %1 = zext i32 %vl to i64
  %a = call { <vscale x 2 x i32>, i64 } @llvm.riscv.vleff.nxv2i32(<vscale x 2 x i32> undef, ptr %p, i64 %1)
  %b = extractvalue { <vscale x 2 x i32>, i64 } %a, 0
  %c = call <vscale x 2 x i32> @llvm.vp.merge.nxv2i32(<vscale x 2 x i1> %m, <vscale x 2 x i32> %b, <vscale x 2 x i32> %passthru, i32 %vl)
  ret <vscale x 2 x i32> %c
}

So if we currently fold vmerge masks into vleNff.vs, this may affect the output vl.

Given this, is it safe to assume that we can add masks or tweak the AVL of a vleNff.v? Presumably as long as we don't increase the AVL/output vl, i.e. keep it within the range of implementation allowed values.

In which case we should probably go ahead and handle vleNff.vs in RISCVVLOptimizer.

[llvmbot]

@llvm/issue-subscribers-backend-risc-v

Author: Luke Lau (lukel97)

In RISCVVLOptimizer we currently don't reduce the AVL of vleNff.v.

#121705 originally proposed to handle it, but in the review I argued that this would affect the output vl: #121705 (comment)

However I think I was wrong here, since I recently realised that after #90049 we actually fold vmerge.vvm masks into vleNff.v, e.g.

define &lt;vscale x 2 x i32&gt; @<!-- -->vpmerge_vleff(&lt;vscale x 2 x i32&gt; %passthru, ptr %p, &lt;vscale x 2 x i1&gt; %m, i32 zeroext %vl) {
; CHECK-LABEL: vpmerge_vleff:
; CHECK:       # %bb.0:
; CHECK-NEXT:    vsetvli zero, a1, e32, m1, tu, mu
; CHECK-NEXT:    vle32ff.v v8, (a0), v0.t
; CHECK-NEXT:    ret
  %1 = zext i32 %vl to i64
  %a = call { &lt;vscale x 2 x i32&gt;, i64 } @<!-- -->llvm.riscv.vleff.nxv2i32(&lt;vscale x 2 x i32&gt; undef, ptr %p, i64 %1)
  %b = extractvalue { &lt;vscale x 2 x i32&gt;, i64 } %a, 0
  %c = call &lt;vscale x 2 x i32&gt; @<!-- -->llvm.vp.merge.nxv2i32(&lt;vscale x 2 x i1&gt; %m, &lt;vscale x 2 x i32&gt; %b, &lt;vscale x 2 x i32&gt; %passthru, i32 %vl)
  ret &lt;vscale x 2 x i32&gt; %c
}

So if we currently fold vmerge masks into vleNff.vs, this may affect the output vl.

Given this, is it safe to assume that we can add masks or tweak the AVL of a vleNff.v? Presumably as long as we don't increase the AVL/output vl, i.e. keep it within the range of implementation allowed values.

In which case we should probably go ahead and handle vleNff.vs in RISCVVLOptimizer.