On 29/10/26 19:33, Aurelien Jarno wrote:
On 2026-10-28 15:33, Philippe Mathieu-Daudé wrote:and/or/xor_vec always have VECE 0, yet their constant was matched as a byte element and applied at the stale SEW of the previous op: "bic v4.8h, #0xf0" became "vand.vi ..., 15".Add the 'N' constraint: use the smallest element size at which the constant replicates, if that element fits simm5, and switch SEW to it. A wider element can't fit when the smallest doesn't: its upper half repeats the smaller element, which would then be 0 or -1. Cc: [email protected] Fixes: 5a63f5998791 ("tcg/riscv: Add support for basic vector opcodes") Reported-by: Aurelien Jarno <[email protected]> Suggested-by: Richard Henderson <[email protected]> Signed-off-by: Philippe Mathieu-Daudé <[email protected]> --- tcg/riscv64/tcg-target-con-set.h | 1 + tcg/riscv64/tcg-target-con-str.h | 1 + tcg/riscv64/tcg-target.c.inc | 53 +++++++++++++++++++++++++++----- 3 files changed, 48 insertions(+), 7 deletions(-)
@@ -2807,16 +2845,16 @@ static void tcg_out_vec_op(TCGContext *s, TCGOpcode opc, } break; case INDEX_op_and_vec: - set_vtype_len(s, type); - tcg_out_opc_vv_vi(s, OPC_VAND_VV, OPC_VAND_VI, a0, a1, a2, c2); + tcg_out_opc_vv_vi_logical(s, type, OPC_VAND_VV, OPC_VAND_VI, + a0, a1, a2, c2); break; case INDEX_op_or_vec: - set_vtype_len(s, type); - tcg_out_opc_vv_vi(s, OPC_VOR_VV, OPC_VOR_VI, a0, a1, a2, c2); + tcg_out_opc_vv_vi_logical(s, type, OPC_VOR_VV, OPC_VOR_VI, + a0, a1, a2, c2); break; case INDEX_op_xor_vec: - set_vtype_len(s, type); - tcg_out_opc_vv_vi(s, OPC_VXOR_VV, OPC_VXOR_VI, a0, a1, a2, c2); + tcg_out_opc_vv_vi_logical(s, type, OPC_VXOR_VV, OPC_VXOR_VI, + a0, a1, a2, c2); break; case INDEX_op_not_vec: set_vtype_len(s, type); @@ -3008,10 +3046,11 @@ tcg_target_op_def(TCGOpcode op, TCGType type, unsigned flags) case INDEX_op_sari_vec: case INDEX_op_rotli_vec: return C_O1_I1(v, v); - case INDEX_op_add_vec: case INDEX_op_and_vec: case INDEX_op_or_vec: case INDEX_op_xor_vec: + return C_O1_I2(v, v, vN); + case INDEX_op_add_vec: case INDEX_op_ssadd_vec: case INDEX_op_sssub_vec: case INDEX_op_usadd_vec:I am still wondering why not propagating VECE for logical ops at the TCG level, instead of recomputing it at the TCG target level. But this is how TCG is currently designed,
AND/OR/XOR are bitwise, so VECE doesn't matter to the generic layer. Indeed propagating it would be a separate tcg-op change.
so: Reviewed-by: Aurelien Jarno <[email protected]>
Thanks!
