Re: Re: RISC-V: Support XTheadVector extensions

["juzhe.zhong@rivai.ai" <juzhe.zhong@rivai.ai>]

[-- Attachment #1: Type: text/plain, Size: 5423 bytes --]

As kito's suggestions. I just have a quick try.

This patch should does following things:

1. Remove all new API that RVV1.0 doesn't have. E.g. vlb.
    They should be another separate patch to be reviewed.
    So the first series patch should be "Support part of theadvector API base on current RVV1.0 API"

2. Here is a another approach which must work for theadvector:

   diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index ae528db1898..24b514c58df 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -646,6 +646,7 @@ extern bool th_classify_address (struct riscv_address_info *,
 extern const char *th_output_move (rtx, rtx);
 extern bool th_print_operand_address (FILE *, machine_mode, rtx);
 #endif
+extern void th_vector_asm_output_opcode (FILE *, const char *);

 extern bool riscv_use_divmod_expander (void);
 void riscv_init_cumulative_args (CUMULATIVE_ARGS *, tree, rtx, tree, int);
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 3701f41b1b3..9631a428341 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -10088,6 +10088,13 @@ extract_base_offset_in_addr (rtx mem, rtx *base, rtx *offset)
   return false;
 }

+void
+th_vector_asm_output_opcode (FILE *f, const char *ptr)
+{
+  if (ptr[0] == 'v')
+    fprintf (f, "th.");
+}
+
 /* Initialize the GCC target structure.  */
 #undef TARGET_ASM_ALIGNED_HI_OP
 #define TARGET_ASM_ALIGNED_HI_OP "\t.half\t"
diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
index 6205d7533f4..be02a926028 100644
--- a/gcc/config/riscv/riscv.h
+++ b/gcc/config/riscv/riscv.h
@@ -1206,4 +1206,6 @@ extern void riscv_remove_unneeded_save_restore_calls (void);
 #define HAVE_POST_MODIFY_DISP TARGET_XTHEADMEMIDX
 #define HAVE_PRE_MODIFY_DISP  TARGET_XTHEADMEMIDX

+#define ASM_OUTPUT_OPCODE(STREAM, PTR) th_vector_asm_output_opcode (STREAM, PTR);
+
 #endif /* ! GCC_RISCV_H */

It does work:

/tmp/cc0yrKxw.s:1692: Error: unrecognized opcode `th.vsetivli zero,8,e8,mf2,ta,ma'
/tmp/cc0yrKxw.s:1693: Error: unrecognized opcode `th.vmv.v.i v1,0'
/tmp/cc0yrKxw.s:1694: Error: unrecognized opcode `th.vse8.v v1,0(a5)'
/tmp/cc0yrKxw.s:1696: Error: unrecognized opcode `th.vse8.v v1,0(a5)'
make[2]: *** [Makefile:935: _gcov.o] Error 1
make[2]: *** Waiting for unfinished jobs....
/tmp/cc2KYYTs.s: Assembler messages:
/tmp/cc2KYYTs.s:1606: Error: unrecognized opcode `th.vsetivli zero,8,e8,mf2,ta,ma'
/tmp/cc2KYYTs.s:1610: Error: unrecognized opcode `th.vle8.v v1,0(a1)'
/tmp/cc2KYYTs.s:1615: Error: unrecognized opcode `th.vse8.v v1,0(sp)'
/tmp/cc2KYYTs.s:1617: Error: unrecognized opcode `th.vle8.v v1,0(a2)'
/tmp/cc2KYYTs.s:1618: Error: unrecognized opcode `th.vse8.v v1,0(a5)'
/tmp/cc2KYYTs.s:1651: Error: unrecognized opcode `th.vsetivli zero,8,e8,mf2,ta,ma'
/tmp/cc2KYYTs.s:1671: Error: unrecognized opcode `th.vle8.v v1,0(a4)'
/tmp/cc2KYYTs.s:1674: Error: unrecognized opcode `th.vse8.v v1,0(a0)'
/tmp/cc2KYYTs.s:2469: Error: unrecognized opcode `th.vsetivli zero,8,e8,mf2,ta,ma'
/tmp/cc2KYYTs.s:2569: Error: unrecognized opcode `th.vsetivli zero,8,e8,mf2,ta,ma'
/tmp/cc2KYYTs.s:2580: Error: unrecognized opcode `th.vle8.v v1,0(a2)'
/tmp/cc2KYYTs.s:2581: Error: unrecognized opcode `th.vse8.v v1,0(a5)'
/tmp/cc2KYYTs.s:2643: Error: unrecognized opcode `th.vsetivli zero,8,e8,mf2,ta,ma'
/tmp/cc2KYYTs.s:2671: Error: unrecognized opcode `th.vsetivli zero,8,e8,mf2,ta,ma'
/tmp/cc2KYYTs.s:3294: Error: unrecognized opcode `th.vsetivli zero,8,e8,mf2,ta,ma'
/tmp/cc2KYYTs.s:3317: Error: unrecognized opcode `th.vle8.v v1,0(a4)'
/tmp/cc2KYYTs.s:3319: Error: unrecognized opcode `th.vse8.v v1,0(a4)'
/tmp/cc2KYYTs.s:3322: Error: unrecognized opcode `th.vle8.v v1,0(a4)'
/tmp/cc2KYYTs.s:3324: Error: unrecognized opcode `th.vse8.v v1,0(a4)'

But we need binutils support theadvector first, otherwise, it will fail during building.

3. Add theadvector gating on target-support.exp. We don't want to run theadvector test
    when we don't enable theadvector.

Thanks.



juzhe.zhong@rivai.ai
 
From: Kito Cheng
Date: 2023-11-18 18:32
To: Philipp Tomsich
CC: Jeff Law; juzhe.zhong@rivai.ai; gcc-patches; kito.cheng; cooper.joshua; Robin Dapp; jkridner
Subject: Re: RISC-V: Support XTheadVector extensions
I guess it would be worth to state my thought publicly:
 
I *support* adding the T-head vector (a.k.a. vector 0.7) to upstream
GCC since T-Head vector already ships a large enough number of boards,
also it's not really T-head's problem as Palmer described in another
mail.
 
My biggest concern before is T-head folks didn't involved into
community work too much, so accept that definitely will increasing
work for maintainers, however I saw T-head folks is trying to
contribute stuffs to upstream now, so may not a concern now, also I
believe accept this patch will encourage they work more on upstream
together, which is benefit to each other.
 
Back to the one of the biggest issues for the patch set: GCC 14 or GCC
15. My general thought is it may be OK if it's less invasive enough,
then should be OK for GCC 14, but I don't have a strong opinion, since
as you know I am not the main developer of the vector part, so I will
let Ju-Zhe make the final decision, because he is the one who
contributes most things to RISC-V vector gcc support.