Adding Drew and Robert.
On Sun, Nov 19, 2023 at 10:04 PM juzhe.zh...@rivai.ai <juzhe.zh...@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.zh...@rivai.ai
>
>
> *From:* Kito Cheng <kito.ch...@gmail.com>
> *Date:* 2023-11-18 18:32
> *To:* Philipp Tomsich <philipp.toms...@vrull.eu>
> *CC:* Jeff Law <jeffreya...@gmail.com>; juzhe.zh...@rivai.ai; gcc-patches
> <gcc-patches@gcc.gnu.org>; kito.cheng <kito.ch...@sifive.com>;
> cooper.joshua <cooper.jos...@linux.alibaba.com>; Robin Dapp
> <rdapp....@gmail.com>; jkridner <jkrid...@beagleboard.org>
> *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.
>
>
>
