Re: Re: RISC-V: Support XTheadVector extensions

2023-11-20 Thread Jason Kridner
Adding Drew and Robert.

On Sun, Nov 19, 2023 at 10:04 PM 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 
> *Date:* 2023-11-18 18:32
> *To:* Philipp Tomsich 
> *CC:* Jeff Law ; juzhe.zh...@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 t

Re: T-Head Vector for GCC-14? (was Re: RISC-V: Support XTheadVector extensions)

2023-11-29 Thread Jason Kridner
On Tue, Nov 28, 2023 at 5:21 PM Jeff Law  wrote:
>
> On 11/28/23 12:56, Philipp Tomsich wrote:
>
> >> That's obviously a risky thing to do given it was sent right at the end
> >> of the window, but it meets the rules.
> >>
> >> Folks in the call seemed generally amenable to at least trying for 14,
> >> so unless anyone's opposed on the lists it seems like the way to go.
> >> IIRC we ended up with the following TODO list:
> >>
> >> * Make sure this doesn't regress on the targets we already support.
> >>From the sounds of things there's been test suite runs that look
fine,
> >>so hopefully that's all manageable.  Christoph said he'd send
> >>something out, we've had a bunch of test skew so there might be a
bit
> >>lurking but it should be generally manageable.
> >> * We agree on some sort of support lifecycle.  There seemed to be
> >>basically two proposals: merge for 14 with the aim of quickly
> >>deperecating it (maybe even for 15), or merge for 14 with the aim of
> >>keeping it until it ends up un-tested (ie, requiring test results
are
> >>published for every release).
> >
> > We expect real-world users, including the BeagleV-AHEAD community, to
> > need support for the foreseeable future.
> > Keeping it until it ends up untested (and test cases are reasonably
> > clean) sounds like a good threshold to ensure the integrity of the
> > codebase while giving this a clear path to stay in for its useful
> > life.
> I can live with it being in the tree as long as it's maintained
> (measured by ongoing testing with reasonable results).
>
> I'd proposed that it could end up deprecated quickly, but that was based
> on the assumption that once V1.0 compliant hardware was widely available
> that we'd see less and less interest in the thead extensions.
>

At BeagleBoard.org, we focus on long-term support and availability.
Long-term support is a key for us engaging with education, both
institutional and continuing, and industrial automation. Getting this into
mainline such that we can develop solutions that integrate with mainline
Linux distributions is key for us to enable broader RISC-V adoption. If it
is deprecated at some point, that won't be terrible as long as we are able
to get to a good snapshot where integration with the rest of the open
source developer community has reasonably happened.

The good news is it *will* get tested. We have confidence in that side of
things. We have a great community that will engage the compiler and
identify regressions.

My expectation is that the Alibaba folks really know the C910 CPU core and
will help us get things right. I'll be here to help escalate issues to them
if they become unresponsive to the list. Others involved in the
BeagleBoard.org project will help make sure I know when I need to escalate
such issues.

Let me know if there's anything I can do to encourage this being merged and
worrying about deprecation later.

--
https://beagleboard.org/about/jkridner - a 501c3 non-profit educating
around open hardware computing