Hello,
On 2026-05-06 10:47, Michael Neuling wrote:
Jussi,
Thanks for the reply.
m4 batching code path selects 128-bit vectors (4 32-bit elements or
16 8-bit elements) and "m4" grouping. Whatever HW supports VLEN>128
or VLEN=128 not should not matter here.
I think the code's assumption around __riscv_vset_v_u32m1_u32m4() may
be wrong.
Thanks for checking this out and for the reproducer. I tested with clang
and same problem persists, __riscv_vset_v_u32m1_u32m4 usage must be
wrong. I'll check for proper fix.
Btw, VLEN=512 gives yet another output:
$ clang --target=riscv64-linux-gnu libgcrypt-rvv-vlen128-assumption.c -o
libgcrypt-rvv-vlen128-assumption -O2 -march=rv64gcv -static
$ qemu-riscv64 -cpu max,vlen=512 ./libgcrypt-rvv-vlen128-assumption
Element-by-element view of out[0..15]:
out[ 0] = 10001111
out[ 1] = 10002222
out[ 2] = 10003333
out[ 3] = 10004444
out[ 4] = 00000000
out[ 5] = 00000000
out[ 6] = 00000000
out[ 7] = 00000000
out[ 8] = 00000000
out[ 9] = 00000000
out[10] = 00000000
out[11] = 00000000
out[12] = 00000000
out[13] = 00000000
out[14] = 00000000
out[15] = 00000000
libgcrypt-shaped layout (VLEN=128 assumption): BUG -- AES_CRYPT m4 vl=16
will not find the 4 blocks here
Where each loaded m1 register actually lands in g (per RVV intrinsic
spec, sub-register N -> elements N*VLMAX_m1 .. (N+1)*VLMAX_m1 - 1):
out[0..3] = sub-register 0 (= r0 + r0-tail)
... and so on for sub-registers 1..3
-Jussi
_______________________________________________
Gcrypt-devel mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
