[Bug target/126196] New: 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 / __riscv_vsm3

[usman.faizyab at blueridgeglobal dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126196

            Bug ID: 126196
           Summary: 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 / __riscv_vsm3
           Product: gcc
           Version: 16.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: usman.faizyab at blueridgeglobal dot net
  Target Milestone: ---

Created attachment 64988
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=64988&action=edit
We can see the disassembly showing that the destination and source register
overlap in the vsm3me.vv instruction

Per the RISC-V Vector Crypto specification for vsm3me.vv
(https://docs.riscv.org/reference/isa/v20260120/unpriv/vector-crypto.html#insns-vsm3me),
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.

I have attached the output of the disassembly of the following code: 

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