Adding Drew and Robert. On Sun, Nov 19, 2023 at 10:04 PM juzhe.zhong@rivai.ai wrote: > 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. > > >