vsm3me.vv intrinsic allows vd/vs2 register overlap, generates illegal instruction causing trap in spike

[Usman Faizyab]

Hi,
I am facing an issue related to the vs3me.vv intrinsic. The issue is that the vsm3me.vv instruction (Zvksh, SM3 message expansion) is documented as a
reserved encoding when the destination register group (vd) overlaps the first source register group (vs2). When compiling code that uses the __riscv_vsm3me_vv_u32m1  

intrinsic with GCC, the compiler allocates the same physical vector register group for vd and vs2, producing an encoding that traps as trap_illegal_instruction when executed on Spike.

I have checked the RISC-V Vector Crypto specification for vsm3me.vv
(https://docs.riscv.org/reference/isa/v20260120/unpriv/vector-crypto.html#insns-vsm3me) and according to it the destination register group must not overlap the vs2 source register group; an encoding where they overlap is reserved. Spike enforces this at runtime (see require_vsm3_constraints in riscv-isa-sim, which checks insn.rd() != insn.rs2()), so any such encoding traps. 

The issue can be seen in the following images where a test file containing vsm3me.vv intrinsic is compiled using the gcc, it results in a vsm3me.vv assembly instruction with overlapped vs and vs2:

#include <riscv_vector.h>
vuint32m1_t f(vuint32m1_t vs2, vuint32m1_t vs1, size_t vl) {
    return __riscv_vsm3me_vv_u32m1(vs2, vs1, vl);
}

#include <riscv_vector.h>
vuint32m4_t f(vuint32m4_t vs2, vuint32m4_t vs1, size_t vl) {
    return __riscv_vsm3me_vv_u32m4(vs2, vs1, vl);
}

For more details, you can see the issue (https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1872#issue-4828960918) that I have created in the riscv-gnu-toolchain repository.

Any help would be appreciated. If you've seen a similar issue before, please share a link to the relevant discussion or bug report.

Thanks and Regards,
Usman Faizyab Khan