On 9/3/26 07:00, Max Chou wrote:
According to the RISC-V unpriviledge spec, "vset{i}vl{i} and whole register loads and stores do not depend upon vtype." The whole-register vector move instructions reuqire legal vtype that trap when VILL is set.The tcg_out_mov in tcg/riscv64 missed the vtype setup before emitting the OPC_VMVNR_V. Fixes: d4be6ee1111 ("tcg/riscv: Implement vector mov/dup{m/i}") Signed-off-by: Max Chou <[email protected]> --- tcg/riscv64/tcg-target.c.inc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tcg/riscv64/tcg-target.c.inc b/tcg/riscv64/tcg-target.c.inc index 2ce9d47a633..fbfb4c44470 100644 --- a/tcg/riscv64/tcg-target.c.inc +++ b/tcg/riscv64/tcg-target.c.inc @@ -778,6 +778,8 @@ static bool tcg_out_mov(TCGContext *s, TCGType type, TCGReg ret, TCGReg arg) { int lmul = type - riscv_lg2_vlenb; int nf = 1 << MAX(lmul, 0); + + set_vtype_len(s, type); tcg_out_opc_vi(s, OPC_VMVNR_V, ret, arg, nf - 1); } break;
If I understand correctly, this happens when vtype is completely unset, such as the first use within the TB, or call-clobbered after a helper.
We don't actually need @type, just not the "uninitialized" type, TCG_TYPE_COUNT, per init_setting_vtype.
That you encountered a reg-reg move in such a situation makes me wonder if we have failed to correctly mark all of these vector registers call-clobbered?
r~
