On Fri, 28 Feb 2025 06:47:24 +0100, "Robin Dapp" wrote: > > This patch modifies the sequence: > > vsetvli zero,a4,e32,m4,ta,ma + vsetvli zero,a4,e8,m2,ta,ma > > to: > > vsetvli zero,a4,e32,m8,ta,ma + vsetvli zero,zero,e8,m2,ta,ma > > Functionally, there is no difference. However, this change resolves the > > issue with "e64,mf4", and allows the second vsetvli to omit a4, which is > > beneficial. > > My question rather was: Why did your test check for the presence of this a4? > Did you see a different issue in an unreduced test apart from what is tested > right now (which seems at least partially wrong)?
Okay, let me explain the background of my previous patch. Prior to applying my patch, for the test case bug-10.c (a reduced example of a larger program with incorrect runtime results), the vsetvli sequence compiled with --param=vsetvl-strategy=simple was as follows: 1. vsetvli zero,a4,e16,m4,ta,ma + vsetvli zero,a4,e32,m8,ta,ma + vsetvli zero,a4,e8,m2,ta,ma The vsetvli sequence compiled with --param=vsetvl-strategy=optim was as follows: 2. vsetvli zero,a4,e32,m4,ta,ma + vsetvli zero,zero,e8,m2,ta,ma Although vl remains unchanged, the SEW/LMUL ratio in sequence 2 changes, leading to undefined behavior. The RVV specification includes the following content related to this: 6.2. AVL encoding ... When rs1=x0 and rd=x0, the instruction operates as if the current vector length in vl is used as the AVL, and the resulting value is written to vl, but not to a destination register. This form can only be used when VLMAX and hence vl is not actually changed by the new SEW/LMUL ratio. Use of the instruction with a new SEW/LMUL ratio that would result in a change of VLMAX is reserved. Implementations may set vill in this case. Ref: https://github.com/riscvarchive/riscv-v-spec/releases/tag/v1.0 > > Here are three issues with this test case: > > 1. The test case does not seem to take effect, as it appears to pass both > > before and after applying the patch for RV64. > > 2. Since no mabi is specified, it consistently fails for RV32 with the > > error: > > "Excess errors: cc1: error: ABI requires '-march=rv32'." > > 3. The test case seems to contain a lot of unnecessary code; perhaps we can > > streamline it. Perhaps you could give this a try. /* { dg-do compile { target { rv64 } } } */ /* { dg-options "-march=rv64gcv_zvfh -mabi=lp64d -O3" } */ #include <riscv_vector.h> _Float16 a (uint64_t); int8_t b () { int c = 100; double *d; _Float16 *e; for (size_t f;; c -= f) { f = c; __riscv_vsll_vx_u8mf8 (__riscv_vid_v_u8mf8 (f), 2, f); vfloat16mf4_t g; a (1); g = __riscv_vfmv_s_f_f16mf4 (2, f); vfloat64m1_t i = __riscv_vfmv_s_f_f64m1 (30491, f); vuint16mf4_t j; __riscv_vsoxei16_v_f16mf4 (e, j, g, f); vuint8mf8_t k = __riscv_vsll_vx_u8mf8 (__riscv_vid_v_u8mf8 (f), 3, f); __riscv_vsoxei8_v_f64m1 (d, k, i, f); } } /* { dg-final { scan-assembler-not "e64,mf4" } } */ Best regards, Jin Ma > As referenced in the PR the issue is flaky and only rarely occurs, under > specific circumstances (and is latent on trunk). The test case was already > reduced. > > You're right about the missing -mabi of course, I keep forgetting it... > > -- > Regards > Robin
