riscv: Allow vector constants in riscv_const_insns.

  Hi,

I figured I'm going to start sending some patches that build on top
of the upcoming RISC-V autovectorization.  This one is obviously
not supposed to be installed before the basic support lands but
it's small enough that it shouldn't hurt to send it now.

This patch allows vector constants in riscv_const_insns in order
for them to be properly recognized as immediate operands such that
we can emit vmv.v.i instructions via autovec.

Bootstrapped and regtested on riscv32gcv and riscv64gcv.

Regards
 Robin

--

gcc/ChangeLog:

	* config/riscv/riscv.cc (riscv_const_insns): Add permissible
	vector constants.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/rvv/autovec/vmv-imm.c: New test.
---
 gcc/config/riscv/riscv.cc                     |  10 +-
 .../gcc.target/riscv/rvv/autovec/vmv-imm.c    | 109 ++++++++++++++++++
 2 files changed, 118 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vmv-imm.c
  

On 4/28/23 10:10, Robin Dapp wrote:
> Hi,
> 
> I figured I'm going to start sending some patches that build on top
> of the upcoming RISC-V autovectorization.  This one is obviously
> not supposed to be installed before the basic support lands but
> it's small enough that it shouldn't hurt to send it now.
> 
> This patch allows vector constants in riscv_const_insns in order
> for them to be properly recognized as immediate operands such that
> we can emit vmv.v.i instructions via autovec.
> 
> Bootstrapped and regtested on riscv32gcv and riscv64gcv.
> 
> Regards
>   Robin
> 
> --
> 
> gcc/ChangeLog:
> 
> 	* config/riscv/riscv.cc (riscv_const_insns): Add permissible
> 	vector constants.
> 
> gcc/testsuite/ChangeLog:
> 
> 	* gcc.target/riscv/rvv/autovec/vmv-imm.c: New test.
OK for the trunk once the basic bits are in.
jeff
  

This ideal of this patch looks good to me.
But I think this patch should be able to handle more cases (not only -16 ~ 15) in case of CONST_VECTOR initialization.

Case 1 (Other constant value that is not -16 ~ 15):
void vmv_m##VAL (TYPE dst[], int n) \
{                                                     \
    for (int i = 0; i < n; i++)                         \
      dst[i] = 100; \
  }

I guess for const_vector:100 is not optimal currently so far, I think you may try (and add testcases).
Such code can be:

Codegen 1:                            Codegen 2:
li a5,100                                  vlse.v v24, (a5), zero ;; a5 address memory has the value of 100.
vmv.v.x v1, a5

I am not sure codegen 1 or codegen 2, which one is better. I think you can decide it.
But my idea is that I think this patch should not only handle he constant value of -16 ~ 15, but also other constant value should be handled and tested in this patch.

Case 2 (Constant value within 32bit for INT64 in RV32 system):

This is a special case:

void vmv_i64 (TYPE dst[], int n)
{                                                    
    for (int i = 0; i < n; i++)                        
      dst[i] = 0xAAAAAAAA;
 }

In this case, the Codegen should be similiar with Case 1 since each scalar register can hold the whole constant value.


Case 3 (Constant value over 32bit for INT64 in RV32 system):

This is a special case:

void vmv_i64 (TYPE dst[], int n)
{                                                    
    for (int i = 0; i < n; i++)                        
      dst[i] = 0xAAAAAAAAA;
 }

In this case, since each scalar register can only hold 32bit value that is not the whole constant value (0xAAAAAAAAA)
I think in this case, we can only use vlse.v...

Would you refine this patch more? Thanks.


juzhe.zhong@rivai.ai
 
From: Robin Dapp
Date: 2023-04-29 00:10
To: gcc-patches; Kito Cheng; Kito.cheng; palmer; juzhe.zhong@rivai.ai; Michael Collison; jeffreyalaw
Subject: [PATCH] riscv: Allow vector constants in riscv_const_insns.
Hi,
 
I figured I'm going to start sending some patches that build on top
of the upcoming RISC-V autovectorization.  This one is obviously
not supposed to be installed before the basic support lands but
it's small enough that it shouldn't hurt to send it now.
 
This patch allows vector constants in riscv_const_insns in order
for them to be properly recognized as immediate operands such that
we can emit vmv.v.i instructions via autovec.
 
Bootstrapped and regtested on riscv32gcv and riscv64gcv.
 
Regards
Robin
 
--
 
gcc/ChangeLog:
 
* config/riscv/riscv.cc (riscv_const_insns): Add permissible
vector constants.
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/rvv/autovec/vmv-imm.c: New test.
---
gcc/config/riscv/riscv.cc                     |  10 +-
.../gcc.target/riscv/rvv/autovec/vmv-imm.c    | 109 ++++++++++++++++++
2 files changed, 118 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/vmv-imm.c
 
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index eb7364ca110..6f9c6743028 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -1228,7 +1228,15 @@ riscv_const_insns (rtx x)
     case CONST_DOUBLE:
     case CONST_VECTOR:
       /* We can use x0 to load floating-point zero.  */
-      return x == CONST0_RTX (GET_MODE (x)) ? 1 : 0;
+      if (x == CONST0_RTX (GET_MODE (x)))
+ return 1;
+      /* Constants from -16 to 15 can be loaded with vmv.v.i.
+ The Wc0, Wc1 constraints are already covered by the
+ vi constraint so we do not need to check them here
+ separately.  */
+      else if (TARGET_VECTOR && satisfies_constraint_vi (x))
+ return 1;
+      return 0;
     case CONST:
       /* See if we can refer to X directly.  */
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/vmv-imm.c b/gcc/testsuite/gcc.target/riscv/rvv/autovec/vmv-imm.c
new file mode 100644
index 00000000000..42ca56d4b5c
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/vmv-imm.c
@@ -0,0 +1,109 @@
+/* { dg-do run } */
+/* { dg-additional-options "-std=c99 --param=riscv-autovec-preference=scalable -fno-vect-cost-model -fno-builtin --save-temps" } */
+
+#include <stdint.h>
+#include <assert.h>
+
+#define VMV_POS(TYPE,VAL) \
+  __attribute__ ((noipa))                               \
+  void vmv_##VAL (TYPE dst[], int n) \
+  {                                                     \
+    for (int i = 0; i < n; i++)                         \
+      dst[i] = VAL; \
+  }
+
+#define VMV_NEG(TYPE,VAL) \
+  __attribute__ ((noipa))                               \
+  void vmv_m##VAL (TYPE dst[], int n) \
+  {                                                     \
+    for (int i = 0; i < n; i++)                         \
+      dst[i] = -VAL; \
+  }
+
+#define TEST_ALL() \
+VMV_NEG(int8_t,16) \
+VMV_NEG(int8_t,15)    \
+VMV_NEG(int8_t,14)    \
+VMV_NEG(int8_t,13)    \
+VMV_NEG(int16_t,12)     \
+VMV_NEG(int16_t,11)     \
+VMV_NEG(int16_t,10)     \
+VMV_NEG(int16_t,9) \
+VMV_NEG(int32_t,8) \
+VMV_NEG(int32_t,7) \
+VMV_NEG(int32_t,6) \
+VMV_NEG(int32_t,5) \
+VMV_NEG(int64_t,4) \
+VMV_NEG(int64_t,3) \
+VMV_NEG(int64_t,2) \
+VMV_NEG(int64_t,1) \
+VMV_POS(uint8_t,0) \
+VMV_POS(uint8_t,1) \
+VMV_POS(uint8_t,2) \
+VMV_POS(uint8_t,3) \
+VMV_POS(uint16_t,4) \
+VMV_POS(uint16_t,5) \
+VMV_POS(uint16_t,6) \
+VMV_POS(uint16_t,7) \
+VMV_POS(uint32_t,8) \
+VMV_POS(uint32_t,9) \
+VMV_POS(uint32_t,10) \
+VMV_POS(uint32_t,11) \
+VMV_POS(uint64_t,12) \
+VMV_POS(uint64_t,13) \
+VMV_POS(uint64_t,14) \
+VMV_POS(uint64_t,15)
+
+TEST_ALL()
+
+#define SZ 32
+
+#define TEST_POS(TYPE,VAL) \
+  TYPE a##TYPE##VAL[SZ];   \
+  vmv_##VAL (a##TYPE##VAL, SZ);   \
+  for (int i = 0; i < SZ; i++)   \
+    assert (a##TYPE##VAL[i] == VAL);
+
+#define TEST_NEG(TYPE,VAL) \
+  TYPE am##TYPE##VAL[SZ];   \
+  vmv_m##VAL (am##TYPE##VAL, SZ); \
+  for (int i = 0; i < SZ; i++)   \
+    assert (am##TYPE##VAL[i] == -VAL);
+
+int main ()
+{
+  TEST_NEG(int8_t, 16)
+  TEST_NEG(int8_t, 15)
+  TEST_NEG(int8_t, 14)
+  TEST_NEG(int8_t, 13)
+  TEST_NEG(int16_t, 12)
+  TEST_NEG(int16_t, 11)
+  TEST_NEG(int16_t, 10)
+  TEST_NEG(int16_t, 9)
+  TEST_NEG(int32_t, 8)
+  TEST_NEG(int32_t, 7)
+  TEST_NEG(int32_t, 6)
+  TEST_NEG(int32_t, 5)
+  TEST_NEG(int64_t, 4)
+  TEST_NEG(int64_t, 3)
+  TEST_NEG(int64_t, 2)
+  TEST_NEG(int64_t, 1)
+  TEST_POS(uint8_t, 0)
+  TEST_POS(uint8_t, 1)
+  TEST_POS(uint8_t, 2)
+  TEST_POS(uint8_t, 3)
+  TEST_POS(uint16_t, 4)
+  TEST_POS(uint16_t, 5)
+  TEST_POS(uint16_t, 6)
+  TEST_POS(uint16_t, 7)
+  TEST_POS(uint32_t, 8)
+  TEST_POS(uint32_t, 9)
+  TEST_POS(uint32_t, 10)
+  TEST_POS(uint32_t, 11)
+  TEST_POS(uint64_t, 12)
+  TEST_POS(uint64_t, 13)
+  TEST_POS(uint64_t, 14)
+  TEST_POS(uint64_t, 15)
+}
+
+/* { dg-final { scan-assembler-times "vmv.v.i" 32 } } */
-- 
2.40.0
  

On 5/3/23 23:07, juzhe.zhong@rivai.ai wrote:
> This ideal of this patch looks good to me.
> But I think this patch should be able to handle more cases (not only -16 
> ~ 15) in case of CONST_VECTOR initialization.
> 
> Case 1 (Other constant value that is not -16 ~ 15):
> void vmv_m##VAL (TYPE dst[], int n) \
> {                                                     \
>      for (int i = 0; i < n; i++)                         \
>        dst[i] = 100; \
>    }
> 
> I guess for const_vector:100 is not optimal currently so far, I think 
> you may try (and add testcases).
> Such code can be:
> 
> Codegen 1:                            Codegen 2:
> li a5,100                                  vlse.v v24, (a5), zero ;; a5 
> address memory has the value of 100.
> vmv.v.x v1, a5
> 
> I am not sure codegen 1 or codegen 2, which one is better. I think you 
> can decide it.
> But my idea is that I think this patch should not only handle he 
> constant value of -16 ~ 15, but also other constant value should be 
> handled and tested in this patch.
> 
> Case 2 (Constant value *within 32bit* for INT64 in *RV32* system):
> 
> This is a special case:
> 
> void vmv_i64 (TYPE dst[], int n)
> {
>      for (int i = 0; i < n; i++)
>        dst[i] = *0xAAAAAAAA*;
>   }
> 
> In this case, the Codegen should be similiar with Case 1 since each 
> scalar register can hold the whole constant value.
> 
> 
> Case 3 (Constant value over* 32bit* for INT64 in *RV32* system):
> 
> This is a special case:
> 
> void vmv_i64 (TYPE dst[], int n)
> {
>      for (int i = 0; i < n; i++)
>        dst[i] = *0xAAAAAAAAA*;
>   }
> 
> In this case, since each scalar register can only hold 32bit value that 
> is not the whole constant value (*0xAAAAAAAAA)*
> I think in this case, we can only use vlse.v...
> 
> Would you refine this patch more? Thanks.
I think we can add those as distinct patches.  The [-16..15] change is 
simple, stands on its own and I don't see any strong reason to make it 
wait for handling additional cases.

Remember, there are multiple engineers working in this space now.  So 
things which are clearly correct should move forward quickly so that we 
don't end up duplicating work.

Handling the additional cases can be handled as a distinct patch on its 
own.

Jeff
  

OK, you can go ahead commit patch.
I am gonna send another patch to fix this.

Besides, I saw you have commit some redundant incorrect codes, I will clean them up in another patch.



juzhe.zhong@rivai.ai
 
From: Jeff Law
Date: 2023-05-07 04:11
To: juzhe.zhong@rivai.ai; Robin Dapp; gcc-patches; kito.cheng; Kito.cheng; palmer; collison
Subject: Re: [PATCH] riscv: Allow vector constants in riscv_const_insns.
 
 
On 5/3/23 23:07, juzhe.zhong@rivai.ai wrote:
> This ideal of this patch looks good to me.
> But I think this patch should be able to handle more cases (not only -16 
> ~ 15) in case of CONST_VECTOR initialization.
> 
> Case 1 (Other constant value that is not -16 ~ 15):
> void vmv_m##VAL (TYPE dst[], int n) \
> {                                                     \
>      for (int i = 0; i < n; i++)                         \
>        dst[i] = 100; \
>    }
> 
> I guess for const_vector:100 is not optimal currently so far, I think 
> you may try (and add testcases).
> Such code can be:
> 
> Codegen 1:                            Codegen 2:
> li a5,100                                  vlse.v v24, (a5), zero ;; a5 
> address memory has the value of 100.
> vmv.v.x v1, a5
> 
> I am not sure codegen 1 or codegen 2, which one is better. I think you 
> can decide it.
> But my idea is that I think this patch should not only handle he 
> constant value of -16 ~ 15, but also other constant value should be 
> handled and tested in this patch.
> 
> Case 2 (Constant value *within 32bit* for INT64 in *RV32* system):
> 
> This is a special case:
> 
> void vmv_i64 (TYPE dst[], int n)
> {
>      for (int i = 0; i < n; i++)
>        dst[i] = *0xAAAAAAAA*;
>   }
> 
> In this case, the Codegen should be similiar with Case 1 since each 
> scalar register can hold the whole constant value.
> 
> 
> Case 3 (Constant value over* 32bit* for INT64 in *RV32* system):
> 
> This is a special case:
> 
> void vmv_i64 (TYPE dst[], int n)
> {
>      for (int i = 0; i < n; i++)
>        dst[i] = *0xAAAAAAAAA*;
>   }
> 
> In this case, since each scalar register can only hold 32bit value that 
> is not the whole constant value (*0xAAAAAAAAA)*
> I think in this case, we can only use vlse.v...
> 
> Would you refine this patch more? Thanks.
I think we can add those as distinct patches.  The [-16..15] change is 
simple, stands on its own and I don't see any strong reason to make it 
wait for handling additional cases.
 
Remember, there are multiple engineers working in this space now.  So 
things which are clearly correct should move forward quickly so that we 
don't end up duplicating work.
 
Handling the additional cases can be handled as a distinct patch on its 
own.
 
Jeff