The 8x4 and 4x4 use a needlessly large multiplier (unless/until we care
about embedded 64-bit-vector hardware). This is merely suboptimal.
The 8x4 case also uses an incorrect vector length, which leads to incorrect
behaviour on future/hypothetical hardware with 256-bit or larger vectors.
Pointed-out-by: Martin Storsjö <mar...@martin.st>
---
libavcodec/riscv/vc1dsp_rvv.S | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/riscv/vc1dsp_rvv.S b/libavcodec/riscv/vc1dsp_rvv.S
index 1a503ecc87..4a00945ead 100644
--- a/libavcodec/riscv/vc1dsp_rvv.S
+++ b/libavcodec/riscv/vc1dsp_rvv.S
@@ -68,7 +68,7 @@ endfunc
func ff_vc1_inv_trans_8x4_dc_rvv, zve64x
lh t2, (a2)
- vsetivli zero, 8, e8, mf2, ta, ma
+ vsetivli zero, 4, e8, mf4, ta, ma
vlse64.v v0, (a0), a1
sh1add t2, t2, t2
addi t2, t2, 1
@@ -84,14 +84,14 @@ func ff_vc1_inv_trans_8x4_dc_rvv, zve64x
vmax.vx v4, v4, zero
vsetvli zero, zero, e8, m2, ta, ma
vnclipu.wi v0, v4, 0
- vsetivli zero, 8, e8, mf2, ta, ma
+ vsetivli zero, 4, e8, mf4, ta, ma
vsse64.v v0, (a0), a1
ret
endfunc
func ff_vc1_inv_trans_4x4_dc_rvv, zve32x
lh t2, (a2)
- vsetivli zero, 4, e8, mf2, ta, ma
+ vsetivli zero, 4, e8, mf4, ta, ma
vlse32.v v0, (a0), a1
slli t1, t2, 4
add t2, t2, t1
@@ -107,7 +107,7 @@ func ff_vc1_inv_trans_4x4_dc_rvv, zve32x
vmax.vx v2, v2, zero
vsetvli zero, zero, e8, m1, ta, ma
vnclipu.wi v0, v2, 0
- vsetivli zero, 4, e8, mf2, ta, ma
+ vsetivli zero, 4, e8, mf4, ta, ma
vsse32.v v0, (a0), a1
ret
endfunc
--
2.43.0
