From: TANG Tiancheng <tangtiancheng.ttc@alibaba-inc.com>
Signed-off-by: TANG Tiancheng <tangtiancheng.ttc@alibaba-inc.com>
Reviewed-by: Liu Zhiwei <zhiwei_liu@linux.alibaba.com>
---
tcg/riscv/tcg-target-con-set.h | 1 +
tcg/riscv/tcg-target.c.inc | 33 +++++++++++++++++++++++++++++++++
2 files changed, 34 insertions(+)
diff --git a/tcg/riscv/tcg-target-con-set.h b/tcg/riscv/tcg-target-con-set.h
index d73a62b0f2..8a0de18257 100644
--- a/tcg/riscv/tcg-target-con-set.h
+++ b/tcg/riscv/tcg-target-con-set.h
@@ -23,3 +23,4 @@ C_O1_I4(r, r, rI, rM, rM)
C_O2_I4(r, r, rZ, rZ, rM, rM)
C_O0_I2(v, r)
C_O1_I1(v, r)
+C_O1_I2(v, v, v)
diff --git a/tcg/riscv/tcg-target.c.inc b/tcg/riscv/tcg-target.c.inc
index f60913e805..650b5eff1a 100644
--- a/tcg/riscv/tcg-target.c.inc
+++ b/tcg/riscv/tcg-target.c.inc
@@ -289,6 +289,12 @@ typedef enum {
OPC_VSE32_V = 0x6027 | V_SUMOP,
OPC_VSE64_V = 0x7027 | V_SUMOP,
+ OPC_VADD_VV = 0x57 | V_OPIVV,
+ OPC_VSUB_VV = 0x8000057 | V_OPIVV,
+ OPC_VAND_VV = 0x24000057 | V_OPIVV,
+ OPC_VOR_VV = 0x28000057 | V_OPIVV,
+ OPC_VXOR_VV = 0x2c000057 | V_OPIVV,
+
OPC_VMV_V_V = 0x5e000057 | V_OPIVV,
OPC_VMV_V_I = 0x5e000057 | V_OPIVI,
OPC_VMV_V_X = 0x5e000057 | V_OPIVX,
@@ -2158,6 +2164,21 @@ static void tcg_out_vec_op(TCGContext *s, TCGOpcode opc,
case INDEX_op_st_vec:
tcg_out_st(s, type, a0, a1, a2);
break;
+ case INDEX_op_add_vec:
+ tcg_out_opc_vv(s, OPC_VADD_VV, a0, a1, a2, true);
+ break;
+ case INDEX_op_sub_vec:
+ tcg_out_opc_vv(s, OPC_VSUB_VV, a0, a1, a2, true);
+ break;
+ case INDEX_op_and_vec:
+ tcg_out_opc_vv(s, OPC_VAND_VV, a0, a1, a2, true);
+ break;
+ case INDEX_op_or_vec:
+ tcg_out_opc_vv(s, OPC_VOR_VV, a0, a1, a2, true);
+ break;
+ case INDEX_op_xor_vec:
+ tcg_out_opc_vv(s, OPC_VXOR_VV, a0, a1, a2, true);
+ break;
case INDEX_op_mov_vec: /* Always emitted via tcg_out_mov. */
case INDEX_op_dup_vec: /* Always emitted via tcg_out_dup_vec. */
default:
@@ -2177,6 +2198,12 @@ void tcg_expand_vec_op(TCGOpcode opc, TCGType type, unsigned vece,
int tcg_can_emit_vec_op(TCGOpcode opc, TCGType type, unsigned vece)
{
switch (opc) {
+ case INDEX_op_add_vec:
+ case INDEX_op_sub_vec:
+ case INDEX_op_and_vec:
+ case INDEX_op_or_vec:
+ case INDEX_op_xor_vec:
+ return 1;
default:
return 0;
}
@@ -2327,6 +2354,12 @@ static TCGConstraintSetIndex tcg_target_op_def(TCGOpcode op)
case INDEX_op_dupm_vec:
case INDEX_op_ld_vec:
return C_O1_I1(v, r);
+ case INDEX_op_add_vec:
+ case INDEX_op_sub_vec:
+ case INDEX_op_and_vec:
+ case INDEX_op_or_vec:
+ case INDEX_op_xor_vec:
+ return C_O1_I2(v, v, v);
default:
g_assert_not_reached();
}
--
2.43.0On 8/13/24 21:34, LIU Zhiwei wrote: > + OPC_VADD_VV = 0x57 | V_OPIVV, > + OPC_VSUB_VV = 0x8000057 | V_OPIVV, > + OPC_VAND_VV = 0x24000057 | V_OPIVV, > + OPC_VOR_VV = 0x28000057 | V_OPIVV, > + OPC_VXOR_VV = 0x2c000057 | V_OPIVV, Immediate operand variants to be handled as a follow-up? r~
On 2024/8/14 17:17, Richard Henderson wrote: > On 8/13/24 21:34, LIU Zhiwei wrote: >> + OPC_VADD_VV = 0x57 | V_OPIVV, >> + OPC_VSUB_VV = 0x8000057 | V_OPIVV, >> + OPC_VAND_VV = 0x24000057 | V_OPIVV, >> + OPC_VOR_VV = 0x28000057 | V_OPIVV, >> + OPC_VXOR_VV = 0x2c000057 | V_OPIVV, > > Immediate operand variants to be handled as a follow-up? Do you mean VXOR_VI? We use vxor.vi for not_vec already in patch 10. Zhiwei > > > r~
On 8/20/24 11:57, LIU Zhiwei wrote: > > On 2024/8/14 17:17, Richard Henderson wrote: >> On 8/13/24 21:34, LIU Zhiwei wrote: >>> + OPC_VADD_VV = 0x57 | V_OPIVV, >>> + OPC_VSUB_VV = 0x8000057 | V_OPIVV, >>> + OPC_VAND_VV = 0x24000057 | V_OPIVV, >>> + OPC_VOR_VV = 0x28000057 | V_OPIVV, >>> + OPC_VXOR_VV = 0x2c000057 | V_OPIVV, >> >> Immediate operand variants to be handled as a follow-up? > Do you mean VXOR_VI? We use vxor.vi for not_vec already in patch 10. Yes, and you match the 5-bit signed operand in patch 9. All that is required is to put the two together here. r~
On 8/13/24 21:34, LIU Zhiwei wrote:
> From: TANG Tiancheng <tangtiancheng.ttc@alibaba-inc.com>
>
> Signed-off-by: TANG Tiancheng <tangtiancheng.ttc@alibaba-inc.com>
> Reviewed-by: Liu Zhiwei <zhiwei_liu@linux.alibaba.com>
> ---
> tcg/riscv/tcg-target-con-set.h | 1 +
> tcg/riscv/tcg-target.c.inc | 33 +++++++++++++++++++++++++++++++++
> 2 files changed, 34 insertions(+)
>
> diff --git a/tcg/riscv/tcg-target-con-set.h b/tcg/riscv/tcg-target-con-set.h
> index d73a62b0f2..8a0de18257 100644
> --- a/tcg/riscv/tcg-target-con-set.h
> +++ b/tcg/riscv/tcg-target-con-set.h
> @@ -23,3 +23,4 @@ C_O1_I4(r, r, rI, rM, rM)
> C_O2_I4(r, r, rZ, rZ, rM, rM)
> C_O0_I2(v, r)
> C_O1_I1(v, r)
> +C_O1_I2(v, v, v)
> diff --git a/tcg/riscv/tcg-target.c.inc b/tcg/riscv/tcg-target.c.inc
> index f60913e805..650b5eff1a 100644
> --- a/tcg/riscv/tcg-target.c.inc
> +++ b/tcg/riscv/tcg-target.c.inc
> @@ -289,6 +289,12 @@ typedef enum {
> OPC_VSE32_V = 0x6027 | V_SUMOP,
> OPC_VSE64_V = 0x7027 | V_SUMOP,
>
> + OPC_VADD_VV = 0x57 | V_OPIVV,
> + OPC_VSUB_VV = 0x8000057 | V_OPIVV,
> + OPC_VAND_VV = 0x24000057 | V_OPIVV,
> + OPC_VOR_VV = 0x28000057 | V_OPIVV,
> + OPC_VXOR_VV = 0x2c000057 | V_OPIVV,
> +
> OPC_VMV_V_V = 0x5e000057 | V_OPIVV,
> OPC_VMV_V_I = 0x5e000057 | V_OPIVI,
> OPC_VMV_V_X = 0x5e000057 | V_OPIVX,
> @@ -2158,6 +2164,21 @@ static void tcg_out_vec_op(TCGContext *s, TCGOpcode opc,
> case INDEX_op_st_vec:
> tcg_out_st(s, type, a0, a1, a2);
> break;
> + case INDEX_op_add_vec:
> + tcg_out_opc_vv(s, OPC_VADD_VV, a0, a1, a2, true);
> + break;
> + case INDEX_op_sub_vec:
> + tcg_out_opc_vv(s, OPC_VSUB_VV, a0, a1, a2, true);
> + break;
> + case INDEX_op_and_vec:
> + tcg_out_opc_vv(s, OPC_VAND_VV, a0, a1, a2, true);
> + break;
> + case INDEX_op_or_vec:
> + tcg_out_opc_vv(s, OPC_VOR_VV, a0, a1, a2, true);
> + break;
> + case INDEX_op_xor_vec:
> + tcg_out_opc_vv(s, OPC_VXOR_VV, a0, a1, a2, true);
> + break;
As with load/store/move, and/or/xor can avoid changing element type.
Thus I think the vtype setup before the switch is premature.
r~
On 2024/8/14 17:13, Richard Henderson wrote:
> On 8/13/24 21:34, LIU Zhiwei wrote:
>> From: TANG Tiancheng <tangtiancheng.ttc@alibaba-inc.com>
>>
>> Signed-off-by: TANG Tiancheng <tangtiancheng.ttc@alibaba-inc.com>
>> Reviewed-by: Liu Zhiwei <zhiwei_liu@linux.alibaba.com>
>> ---
>> tcg/riscv/tcg-target-con-set.h | 1 +
>> tcg/riscv/tcg-target.c.inc | 33 +++++++++++++++++++++++++++++++++
>> 2 files changed, 34 insertions(+)
>>
>> diff --git a/tcg/riscv/tcg-target-con-set.h
>> b/tcg/riscv/tcg-target-con-set.h
>> index d73a62b0f2..8a0de18257 100644
>> --- a/tcg/riscv/tcg-target-con-set.h
>> +++ b/tcg/riscv/tcg-target-con-set.h
>> @@ -23,3 +23,4 @@ C_O1_I4(r, r, rI, rM, rM)
>> C_O2_I4(r, r, rZ, rZ, rM, rM)
>> C_O0_I2(v, r)
>> C_O1_I1(v, r)
>> +C_O1_I2(v, v, v)
>> diff --git a/tcg/riscv/tcg-target.c.inc b/tcg/riscv/tcg-target.c.inc
>> index f60913e805..650b5eff1a 100644
>> --- a/tcg/riscv/tcg-target.c.inc
>> +++ b/tcg/riscv/tcg-target.c.inc
>> @@ -289,6 +289,12 @@ typedef enum {
>> OPC_VSE32_V = 0x6027 | V_SUMOP,
>> OPC_VSE64_V = 0x7027 | V_SUMOP,
>> + OPC_VADD_VV = 0x57 | V_OPIVV,
>> + OPC_VSUB_VV = 0x8000057 | V_OPIVV,
>> + OPC_VAND_VV = 0x24000057 | V_OPIVV,
>> + OPC_VOR_VV = 0x28000057 | V_OPIVV,
>> + OPC_VXOR_VV = 0x2c000057 | V_OPIVV,
>> +
>> OPC_VMV_V_V = 0x5e000057 | V_OPIVV,
>> OPC_VMV_V_I = 0x5e000057 | V_OPIVI,
>> OPC_VMV_V_X = 0x5e000057 | V_OPIVX,
>> @@ -2158,6 +2164,21 @@ static void tcg_out_vec_op(TCGContext *s,
>> TCGOpcode opc,
>> case INDEX_op_st_vec:
>> tcg_out_st(s, type, a0, a1, a2);
>> break;
>> + case INDEX_op_add_vec:
>> + tcg_out_opc_vv(s, OPC_VADD_VV, a0, a1, a2, true);
>> + break;
>> + case INDEX_op_sub_vec:
>> + tcg_out_opc_vv(s, OPC_VSUB_VV, a0, a1, a2, true);
>> + break;
>> + case INDEX_op_and_vec:
>> + tcg_out_opc_vv(s, OPC_VAND_VV, a0, a1, a2, true);
>> + break;
>> + case INDEX_op_or_vec:
>> + tcg_out_opc_vv(s, OPC_VOR_VV, a0, a1, a2, true);
>> + break;
>> + case INDEX_op_xor_vec:
>> + tcg_out_opc_vv(s, OPC_VXOR_VV, a0, a1, a2, true);
>> + break;
>
> As with load/store/move, and/or/xor can avoid changing element type.
> Thus I think the vtype setup before the switch is premature.
Agree. We have implemented this feature on the v2 patch set.
Thanks,
Zhiwei
>
>
> r~
© 2016 - 2024 Red Hat, Inc.