diff mbox series

[v1,08/15] tcg/riscv: Add support for basic vector opcodes

Message ID 20240813113436.831-9-zhiwei_liu@linux.alibaba.com (mailing list archive)
State New, archived
Headers show
Series tcg/riscv: Add support for vector | expand

Commit Message

LIU Zhiwei Aug. 13, 2024, 11:34 a.m. UTC 
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(+)

Comments

Richard Henderson Aug. 14, 2024, 9:13 a.m. UTC | #1 
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~
Richard Henderson Aug. 14, 2024, 9:17 a.m. UTC | #2 
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?


r~
LIU Zhiwei Aug. 20, 2024, 1:56 a.m. UTC | #3 
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~
LIU Zhiwei Aug. 20, 2024, 1:57 a.m. UTC | #4 
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~
Richard Henderson Aug. 20, 2024, 5:14 a.m. UTC | #5 
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~
diff mbox series

Patch

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();
     }