* RISC-V: Support XTheadVector extensions @ 2023-11-17 11:39 juzhe.zhong 2023-11-17 16:47 ` Jeff Law ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: juzhe.zhong @ 2023-11-17 11:39 UTC (permalink / raw) To: gcc-patches Cc: kito.cheng, kito.cheng, cooper.joshua, Robin Dapp, jeffreyalaw [-- Attachment #1: Type: text/plain, Size: 1096 bytes --] 90% theadvector extension reusing current RVV 1.0 instructions patterns: Just change ASM, For example: @@ -2923,7 +2923,7 @@ (define_insn "*pred_mulh<v_su><mode>_scalar" (match_operand:VFULLI_D 3 "register_operand" "vr,vr, vr, vr")] VMULH) (match_operand:VFULLI_D 2 "vector_merge_operand" "vu, 0, vu, 0")))] "TARGET_VECTOR" - "vmulh<v_su>.vx\t%0,%3,%z4%p1" + "%^vmulh<v_su>.vx\t%0,%3,%z4%p1" [(set_attr "type" "vimul") (set_attr "mode" "<MODE>")]) + if (letter == '^') + { + if (TARGET_XTHEADVECTOR) + fputs ("th.", file); + return; + } For almost all patterns, you just simply append "th." in the ASM prefix. like change "vmulh.vv" -> "th.vmulh.vv" Almost all theadvector instructions are not new features, all same as RVV1.0. Why do you invent the such ISA doesn't include any features that RVV1.0 doesn't satisfy ? I am not explicitly object this patch. But I should know the reason. Btw, stage 1 will close soon. So I will review this patch on GCC-15 as long as all other RISC-V maintainers agree. juzhe.zhong@rivai.ai ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RISC-V: Support XTheadVector extensions 2023-11-17 11:39 RISC-V: Support XTheadVector extensions juzhe.zhong @ 2023-11-17 16:47 ` Jeff Law 2023-11-18 9:45 ` Philipp Tomsich 2023-11-17 17:11 ` RISC-V: " Palmer Dabbelt 2023-11-18 9:11 ` Christoph Müllner 2 siblings, 1 reply; 15+ messages in thread From: Jeff Law @ 2023-11-17 16:47 UTC (permalink / raw) To: juzhe.zhong, gcc-patches Cc: kito.cheng, kito.cheng, cooper.joshua, Robin Dapp On 11/17/23 04:39, juzhe.zhong@rivai.ai wrote: > 90% theadvector extension reusing current RVV 1.0 instructions patterns: > Just change ASM, For example: > > @@ -2923,7 +2923,7 @@ (define_insn "*pred_mulh<v_su><mode>_scalar" > (match_operand:VFULLI_D 3 "register_operand" "vr,vr, vr, vr")] VMULH) > (match_operand:VFULLI_D 2 "vector_merge_operand" "vu, 0, vu, 0")))] > "TARGET_VECTOR" > - "vmulh<v_su>.vx\t%0,%3,%z4%p1" > + "%^vmulh<v_su>.vx\t%0,%3,%z4%p1" > [(set_attr "type" "vimul") > (set_attr "mode" "<MODE>")]) > > + if (letter == '^') > + { > + if (TARGET_XTHEADVECTOR) > + fputs ("th.", file); > + return; > + } I assume this hunk is meant for riscv_output_operand in riscv.cc. We may also need to add '^' to the punct_valid_p hook. But yes, this is the preferred way to go when all we need to do is prefix the instruction with "th.". > > Btw, stage 1 will close soon. So I will review this patch on GCC-15 as > long as all other RISC-V maintainers agree. I *think* it's a gcc-15 issue. Philipp T. and I briefly spoke about this at the RVI summit a couple weeks back and he indicated the thead vector work was targeting gcc-15. Jeff ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RISC-V: Support XTheadVector extensions 2023-11-17 16:47 ` Jeff Law @ 2023-11-18 9:45 ` Philipp Tomsich 2023-11-18 10:32 ` Kito Cheng 0 siblings, 1 reply; 15+ messages in thread From: Philipp Tomsich @ 2023-11-18 9:45 UTC (permalink / raw) To: Jeff Law Cc: juzhe.zhong, gcc-patches, kito.cheng, kito.cheng, cooper.joshua, Robin Dapp, jkridner On Fri, 17 Nov 2023 at 22:47, Jeff Law <jeffreyalaw@gmail.com> wrote: > > > > On 11/17/23 04:39, juzhe.zhong@rivai.ai wrote: > > 90% theadvector extension reusing current RVV 1.0 instructions patterns: > > Just change ASM, For example: > > > > @@ -2923,7 +2923,7 @@ (define_insn "*pred_mulh<v_su><mode>_scalar" > > (match_operand:VFULLI_D 3 "register_operand" "vr,vr, vr, vr")] VMULH) > > (match_operand:VFULLI_D 2 "vector_merge_operand" "vu, 0, vu, 0")))] > > "TARGET_VECTOR" > > - "vmulh<v_su>.vx\t%0,%3,%z4%p1" > > + "%^vmulh<v_su>.vx\t%0,%3,%z4%p1" > > [(set_attr "type" "vimul") > > (set_attr "mode" "<MODE>")]) > > > > + if (letter == '^') > > + { > > + if (TARGET_XTHEADVECTOR) > > + fputs ("th.", file); > > + return; > > + } > I assume this hunk is meant for riscv_output_operand in riscv.cc. We > may also need to add '^' to the punct_valid_p hook. But yes, this is > the preferred way to go when all we need to do is prefix the instruction > with "th.". > > > > > > Btw, stage 1 will close soon. So I will review this patch on GCC-15 as > > long as all other RISC-V maintainers agree. > I *think* it's a gcc-15 issue. Philipp T. and I briefly spoke about > this at the RVI summit a couple weeks back and he indicated the thead > vector work was targeting gcc-15. To restate the intent clearly: - Getting this merged into GCC14 would be our most favored outcome, as boards with XTheadV are quite common in the field: Allwinner D1, BeagleBoard BeagleV-Ahead, Sophgo Milk-V; - If that is not possible and we end up with an "ok for 15", we can still resolve the downstream ecosystem issues (primarily felt by the BeagleV-Ahead community) gracefully. From our brief discussion, I understood you thought it more realistic to land this early into GCC15. If we end up targeting GCC15, I would still like to achieve an agreement on design early. This would allow our team to make any needed changes and maintain them in a vendor-branch (on the GCC GIT reposirty) until GCC15 opens up. Philipp. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RISC-V: Support XTheadVector extensions 2023-11-18 9:45 ` Philipp Tomsich @ 2023-11-18 10:32 ` Kito Cheng 2023-11-18 15:16 ` 钟居哲 ` (2 more replies) 0 siblings, 3 replies; 15+ messages in thread From: Kito Cheng @ 2023-11-18 10:32 UTC (permalink / raw) To: Philipp Tomsich Cc: Jeff Law, juzhe.zhong, gcc-patches, kito.cheng, cooper.joshua, Robin Dapp, jkridner 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Re: RISC-V: Support XTheadVector extensions 2023-11-18 10:32 ` Kito Cheng @ 2023-11-18 15:16 ` 钟居哲 2023-11-20 3:04 ` juzhe.zhong 2023-11-30 12:01 ` 回复:RISC-V: " joshua 2 siblings, 0 replies; 15+ messages in thread From: 钟居哲 @ 2023-11-18 15:16 UTC (permalink / raw) To: kito.cheng, philipp.tomsich Cc: Jeff Law, gcc-patches, kito.cheng, cooper.joshua, rdapp.gcc, jkridner [-- Attachment #1: Type: text/plain, Size: 1772 bytes --] Currently I start to work on full coverage testing (with different compile option test GCC testsuite) and fix bugs which is highest priority definitely. I am not able to find the time review this patch on GCC-14 for now. So conservatively, postpone it to GCC-15. If we are lucky that I stablize RVV support quickly, we still have a chance to make it landed on GCC-14. It all depends on my review. But no worry, I will review that eventually. 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Re: RISC-V: Support XTheadVector extensions 2023-11-18 10:32 ` Kito Cheng 2023-11-18 15:16 ` 钟居哲 @ 2023-11-20 3:04 ` juzhe.zhong 2023-11-20 16:58 ` Jason Kridner 2023-11-30 12:01 ` 回复:RISC-V: " joshua 2 siblings, 1 reply; 15+ messages in thread From: juzhe.zhong @ 2023-11-20 3:04 UTC (permalink / raw) To: kito.cheng, philipp.tomsich Cc: jeffreyalaw, gcc-patches, Kito.cheng, cooper.joshua, Robin Dapp, jkridner [-- 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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Re: RISC-V: Support XTheadVector extensions 2023-11-20 3:04 ` juzhe.zhong @ 2023-11-20 16:58 ` Jason Kridner 0 siblings, 0 replies; 15+ messages in thread From: Jason Kridner @ 2023-11-20 16:58 UTC (permalink / raw) To: juzhe.zhong Cc: Drew Fustini, Kito.cheng, Robert Nelson, Robin Dapp, cooper.joshua, gcc-patches, jeffreyalaw, kito.cheng, philipp.tomsich [-- Attachment #1: Type: text/plain, Size: 5916 bytes --] Adding Drew and Robert. On Sun, Nov 19, 2023 at 10:04 PM juzhe.zhong@rivai.ai <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 <kito.cheng@gmail.com> > *Date:* 2023-11-18 18:32 > *To:* Philipp Tomsich <philipp.tomsich@vrull.eu> > *CC:* Jeff Law <jeffreyalaw@gmail.com>; juzhe.zhong@rivai.ai; gcc-patches > <gcc-patches@gcc.gnu.org>; kito.cheng <kito.cheng@sifive.com>; > cooper.joshua <cooper.joshua@linux.alibaba.com>; Robin Dapp > <rdapp.gcc@gmail.com>; jkridner <jkridner@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. > > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* 回复:RISC-V: Support XTheadVector extensions 2023-11-18 10:32 ` Kito Cheng 2023-11-18 15:16 ` 钟居哲 2023-11-20 3:04 ` juzhe.zhong @ 2023-11-30 12:01 ` joshua 2 siblings, 0 replies; 15+ messages in thread From: joshua @ 2023-11-30 12:01 UTC (permalink / raw) To: Kito Cheng Cc: Jeff Law, juzhe.zhong, gcc-patches, kito.cheng, Robin Dapp, jkridner, philipp.tomsich [-- Attachment #1: Type: text/plain, Size: 1916 bytes --] Hi Kito, Thank you for your support. We will get involved into community work actively for our XTheadVector patches. Let's work on upstream together during this process. Currently, we are polishing up our patches according to Ju-Zhe's suggestions. Patch v3 with higher quality and less invasion will come soon. Joshua ------------------------------------------------------------------ 发件人:Kito Cheng <kito.cheng@gmail.com> 发送时间:2023年11月18日(星期六) 18:33 收件人:Philipp Tomsich<philipp.tomsich@vrull.eu> 抄 送:Jeff Law<jeffreyalaw@gmail.com>; "juzhe.zhong@rivai.ai"<juzhe.zhong@rivai.ai>; "gcc-patches"<gcc-patches@gcc.gnu.org>; "kito.cheng"<kito.cheng@sifive.com>; "cooper.joshua"<cooper.joshua@linux.alibaba.com>; Robin Dapp<rdapp.gcc@gmail.com>; jkridner<jkridner@beagleboard.org> 主 题: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. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RISC-V: Support XTheadVector extensions 2023-11-17 11:39 RISC-V: Support XTheadVector extensions juzhe.zhong 2023-11-17 16:47 ` Jeff Law @ 2023-11-17 17:11 ` Palmer Dabbelt 2023-11-17 23:16 ` 钟居哲 2023-11-18 9:11 ` Christoph Müllner 2 siblings, 1 reply; 15+ messages in thread From: Palmer Dabbelt @ 2023-11-17 17:11 UTC (permalink / raw) To: juzhe.zhong Cc: gcc-patches, Kito Cheng, kito.cheng, cooper.joshua, rdapp.gcc, jeffreyalaw On Fri, 17 Nov 2023 03:39:48 PST (-0800), juzhe.zhong@rivai.ai wrote: > 90% theadvector extension reusing current RVV 1.0 instructions patterns: > Just change ASM, For example: > > @@ -2923,7 +2923,7 @@ (define_insn "*pred_mulh<v_su><mode>_scalar" > (match_operand:VFULLI_D 3 "register_operand" "vr,vr, vr, vr")] VMULH) > (match_operand:VFULLI_D 2 "vector_merge_operand" "vu, 0, vu, 0")))] > "TARGET_VECTOR" > - "vmulh<v_su>.vx\t%0,%3,%z4%p1" > + "%^vmulh<v_su>.vx\t%0,%3,%z4%p1" > [(set_attr "type" "vimul") > (set_attr "mode" "<MODE>")]) > + if (letter == '^') > + { > + if (TARGET_XTHEADVECTOR) > + fputs ("th.", file); > + return; > + } > > For almost all patterns, you just simply append "th." in the ASM prefix. > like change "vmulh.vv" -> "th.vmulh.vv" > > Almost all theadvector instructions are not new features, all same as RVV1.0. > Why do you invent the such ISA doesn't include any features that RVV1.0 doesn't satisfy ? > > I am not explicitly object this patch. But I should know the reason. There's some more in the later threads, but with the top posting it kind of got lost so I'm just replying here. This really isn't T-Head's fault: we announced V-0.7 as a stable draft that was being implemented, and then T-Head went and implemented it. Most of that history has been scrubbed by RVI, but you can still find some stuff like this old talk on YouTube <https://www.youtube.com/watch?v=F66F1nT1T8o>. In general we've just figured out a way to make things work when HW vendors end up in a grey area in RISC-V land. That obviously results in a bunch of pain for the SW people, but this stuff is only useful if we can run on real HW and that always involves some amount of pain. Hopefully we can get to a point where we make fewer problems for ourselves, but we've got a long history to dig out from and there's going to be a lot more of this in the future. So I don't like this XTHeadV stuff, but I think we're best to take it: these guys tried to do the right thing and got thrown under the bus by RVI, we should help them. This is almost certainly going to be a lot more pain that we're used to, just given the size of the extensions in question, but I still think it's the right way to go. The other option is to essentially just tell them to fork the ISA, which isn't good for anyone. > Btw, stage 1 will close soon. So I will review this patch on GCC-15 as long as all other RISC-V maintainers agree. I agree this is gcc-15 material: there's a lot of subtle differences in behavior between 0.7 and 1.0, even when the mnemonics are the same. We're already pretty buried in testing for 14, so trying to pick up another target is going to be a huge headache (particularly one that's a bit special). > > > > > juzhe.zhong@rivai.ai ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Re: RISC-V: Support XTheadVector extensions 2023-11-17 17:11 ` RISC-V: " Palmer Dabbelt @ 2023-11-17 23:16 ` 钟居哲 2023-11-18 0:01 ` Jeff Law 0 siblings, 1 reply; 15+ messages in thread From: 钟居哲 @ 2023-11-17 23:16 UTC (permalink / raw) To: palmer Cc: gcc-patches, kito.cheng, kito.cheng, cooper.joshua, rdapp.gcc, Jeff Law [-- Attachment #1: Type: text/plain, Size: 3662 bytes --] >> I assume this hunk is meant for riscv_output_operand in riscv.cc. We >> may also need to add '^' to the punct_valid_p hook. But yes, this is >> the preferred way to go when all we need to do is prefix the instruction >> with "th.". No. I don't think we need to add '^' . I don't want theadvector to touch any codes of vector.md. Mixing up theadvector with RVV1.0 is a nighmare for RVV maintain. People like me don't want to touch any thing related to Thead. But anyway, I will take care of that in GCC-15. juzhe.zhong@rivai.ai From: Palmer Dabbelt Date: 2023-11-18 01:11 To: juzhe.zhong CC: gcc-patches; Kito Cheng; kito.cheng; cooper.joshua; rdapp.gcc; jeffreyalaw Subject: Re: RISC-V: Support XTheadVector extensions On Fri, 17 Nov 2023 03:39:48 PST (-0800), juzhe.zhong@rivai.ai wrote: > 90% theadvector extension reusing current RVV 1.0 instructions patterns: > Just change ASM, For example: > > @@ -2923,7 +2923,7 @@ (define_insn "*pred_mulh<v_su><mode>_scalar" > (match_operand:VFULLI_D 3 "register_operand" "vr,vr, vr, vr")] VMULH) > (match_operand:VFULLI_D 2 "vector_merge_operand" "vu, 0, vu, 0")))] > "TARGET_VECTOR" > - "vmulh<v_su>.vx\t%0,%3,%z4%p1" > + "%^vmulh<v_su>.vx\t%0,%3,%z4%p1" > [(set_attr "type" "vimul") > (set_attr "mode" "<MODE>")]) > + if (letter == '^') > + { > + if (TARGET_XTHEADVECTOR) > + fputs ("th.", file); > + return; > + } > > For almost all patterns, you just simply append "th." in the ASM prefix. > like change "vmulh.vv" -> "th.vmulh.vv" > > Almost all theadvector instructions are not new features, all same as RVV1.0. > Why do you invent the such ISA doesn't include any features that RVV1.0 doesn't satisfy ? > > I am not explicitly object this patch. But I should know the reason. There's some more in the later threads, but with the top posting it kind of got lost so I'm just replying here. This really isn't T-Head's fault: we announced V-0.7 as a stable draft that was being implemented, and then T-Head went and implemented it. Most of that history has been scrubbed by RVI, but you can still find some stuff like this old talk on YouTube <https://www.youtube.com/watch?v=F66F1nT1T8o>. In general we've just figured out a way to make things work when HW vendors end up in a grey area in RISC-V land. That obviously results in a bunch of pain for the SW people, but this stuff is only useful if we can run on real HW and that always involves some amount of pain. Hopefully we can get to a point where we make fewer problems for ourselves, but we've got a long history to dig out from and there's going to be a lot more of this in the future. So I don't like this XTHeadV stuff, but I think we're best to take it: these guys tried to do the right thing and got thrown under the bus by RVI, we should help them. This is almost certainly going to be a lot more pain that we're used to, just given the size of the extensions in question, but I still think it's the right way to go. The other option is to essentially just tell them to fork the ISA, which isn't good for anyone. > Btw, stage 1 will close soon. So I will review this patch on GCC-15 as long as all other RISC-V maintainers agree. I agree this is gcc-15 material: there's a lot of subtle differences in behavior between 0.7 and 1.0, even when the mnemonics are the same. We're already pretty buried in testing for 14, so trying to pick up another target is going to be a huge headache (particularly one that's a bit special). > > > > > juzhe.zhong@rivai.ai ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RISC-V: Support XTheadVector extensions 2023-11-17 23:16 ` 钟居哲 @ 2023-11-18 0:01 ` Jeff Law 2023-11-18 0:04 ` 钟居哲 2023-11-28 19:45 ` Palmer Dabbelt 0 siblings, 2 replies; 15+ messages in thread From: Jeff Law @ 2023-11-18 0:01 UTC (permalink / raw) To: 钟居哲, palmer Cc: gcc-patches, kito.cheng, kito.cheng, cooper.joshua, rdapp.gcc On 11/17/23 16:16, 钟居哲 wrote: > >> I assume this hunk is meant for riscv_output_operand in riscv.cc. We >>>may also need to add '^' to the punct_valid_p hook. But yes, this is >>>the preferred way to go when all we need to do is prefix the instruction >>>with "th.". > > No. I don't think we need to add '^' . I don't want theadvector to touch > any codes > of vector.md. > Mixing up theadvector with RVV1.0 is a nighmare for RVV maintain. > People like me don't want to touch any thing related to Thead. > But anyway, I will take care of that in GCC-15. I suspect it's going to be even worse if you we have multiple patterns with the same underlying RTL, but just different output strings. The standard way to handle that has been with an output modifier and/or ASSEMBLER_DIALECT. If you look at the PA port for example, the assembler syntax changed dramatically between the PA1.0/PA1.1 era and the PA2.0 era. But we support both variants trivially without duplicating all the patterns. But we've got time to sort this out. I don't think the code in question was targeted towards gcc-14. jeff ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Re: RISC-V: Support XTheadVector extensions 2023-11-18 0:01 ` Jeff Law @ 2023-11-18 0:04 ` 钟居哲 2023-11-28 19:45 ` Palmer Dabbelt 1 sibling, 0 replies; 15+ messages in thread From: 钟居哲 @ 2023-11-18 0:04 UTC (permalink / raw) To: Jeff Law, palmer Cc: gcc-patches, kito.cheng, kito.cheng, cooper.joshua, rdapp.gcc [-- Attachment #1: Type: text/plain, Size: 1620 bytes --] >> I suspect it's going to be even worse if you we have multiple patterns >> with the same underlying RTL, but just different output strings. No. We don't need to add (duplicate) any new patterns. I know RVV GCC very well. I know how to do that. juzhe.zhong@rivai.ai From: Jeff Law Date: 2023-11-18 08:01 To: 钟居哲; palmer CC: gcc-patches; kito.cheng; kito.cheng; cooper.joshua; rdapp.gcc Subject: Re: RISC-V: Support XTheadVector extensions On 11/17/23 16:16, 钟居哲 wrote: > >> I assume this hunk is meant for riscv_output_operand in riscv.cc. We >>>may also need to add '^' to the punct_valid_p hook. But yes, this is >>>the preferred way to go when all we need to do is prefix the instruction >>>with "th.". > > No. I don't think we need to add '^' . I don't want theadvector to touch > any codes > of vector.md. > Mixing up theadvector with RVV1.0 is a nighmare for RVV maintain. > People like me don't want to touch any thing related to Thead. > But anyway, I will take care of that in GCC-15. I suspect it's going to be even worse if you we have multiple patterns with the same underlying RTL, but just different output strings. The standard way to handle that has been with an output modifier and/or ASSEMBLER_DIALECT. If you look at the PA port for example, the assembler syntax changed dramatically between the PA1.0/PA1.1 era and the PA2.0 era. But we support both variants trivially without duplicating all the patterns. But we've got time to sort this out. I don't think the code in question was targeted towards gcc-14. jeff ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RISC-V: Support XTheadVector extensions 2023-11-18 0:01 ` Jeff Law 2023-11-18 0:04 ` 钟居哲 @ 2023-11-28 19:45 ` Palmer Dabbelt 2023-11-28 22:14 ` Jeff Law 1 sibling, 1 reply; 15+ messages in thread From: Palmer Dabbelt @ 2023-11-28 19:45 UTC (permalink / raw) To: jeffreyalaw Cc: juzhe.zhong, gcc-patches, Kito Cheng, kito.cheng, cooper.joshua, Robin Dapp On Fri, 17 Nov 2023 16:01:27 PST (-0800), jeffreyalaw@gmail.com wrote: > > > On 11/17/23 16:16, 钟居哲 wrote: >> >> I assume this hunk is meant for riscv_output_operand in riscv.cc. We >>>>may also need to add '^' to the punct_valid_p hook. But yes, this is >>>>the preferred way to go when all we need to do is prefix the instruction >>>>with "th.". >> >> No. I don't think we need to add '^' . I don't want theadvector to touch >> any codes >> of vector.md. >> Mixing up theadvector with RVV1.0 is a nighmare for RVV maintain. >> People like me don't want to touch any thing related to Thead. >> But anyway, I will take care of that in GCC-15. > I suspect it's going to be even worse if you we have multiple patterns > with the same underlying RTL, but just different output strings. > > The standard way to handle that has been with an output modifier and/or > ASSEMBLER_DIALECT. If you look at the PA port for example, the > assembler syntax changed dramatically between the PA1.0/PA1.1 era and > the PA2.0 era. But we support both variants trivially without > duplicating all the patterns. IMO we're just stuck between a rock and a hard place here. Specifically, this isn't just an assembly syntax change but also comes with a bunch of behaviorial changes to the instructions in question -- I'm specifically thinking of things like the register packing, which IIRC changed a ton between 0.7 and 0.8 (and then again more for 1.0). That's the kind of stuff that tends to have non-local implications on the port, and thus can trip people up. So if we model this as just assembly syntax then we risk people tripping over the differences, but if we try to model it as a whole different extension then we have more code to manage. I'd start with the assembly syntax approach, as it should be the option with less code which is always nice. If that turns out to be a problem then we can always just duplicate the patterns, but it's way harder to merge them back together if we start out with things duplicated. During the patchwork call we also ended up talking about the P extension (and the likely vendor flavors). Nothing's appeared for there yet, but the theory is that the RZ/Five (Renesas' line of RISC-V chips that came out earlier this year) has some P-related extension. There's also some SIMD in CORE-V, as well as a bunch of low-hanging fruit missing from V that we'll probably see more vendor extensions for. So I think if the goal is to have a single vector target for RISC-V then we've probably lost already. > But we've got time to sort this out. I don't think the code in question > was targeted towards gcc-14. [In case anyone else is watching: see the forked thread, it might be amied for 14 now...] > > > jeff ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RISC-V: Support XTheadVector extensions 2023-11-28 19:45 ` Palmer Dabbelt @ 2023-11-28 22:14 ` Jeff Law 0 siblings, 0 replies; 15+ messages in thread From: Jeff Law @ 2023-11-28 22:14 UTC (permalink / raw) To: Palmer Dabbelt Cc: juzhe.zhong, gcc-patches, Kito Cheng, kito.cheng, cooper.joshua, Robin Dapp On 11/28/23 12:45, Palmer Dabbelt wrote: > > IMO we're just stuck between a rock and a hard place here. Specifically, > this isn't just an assembly syntax change but also comes with a bunch of > behaviorial changes to the instructions in question -- I'm specifically > thinking of things like the register packing, which IIRC changed a ton > between 0.7 and 0.8 (and then again more for 1.0). That's the kind of > stuff that tends to have non-local implications on the port, and thus > can trip people up. > > So if we model this as just assembly syntax then we risk people tripping > over the differences, but if we try to model it as a whole different > extension then we have more code to manage. I'd start with the assembly > syntax approach, as it should be the option with less code which is > always nice. If that turns out to be a problem then we can always just > duplicate the patterns, but it's way harder to merge them back together > if we start out with things duplicated. The way I think about the assembly bits is it allows us to share a good amount of code between the two implementations. There's obviously going to be some differences that will require more extensive work and that's where I think most of our review effort ought to be. > > During the patchwork call we also ended up talking about the P extension > (and the likely vendor flavors). Nothing's appeared for there yet, but > the theory is that the RZ/Five (Renesas' line of RISC-V chips that came > out earlier this year) has some P-related extension. There's also some > SIMD in CORE-V, as well as a bunch of low-hanging fruit missing from V > that we'll probably see more vendor extensions for. The only P bits that made the gcc-14 deadline were those from Embecosm, so I'd tend to want to push all the other P stuff out to gcc-15. > > So I think if the goal is to have a single vector target for RISC-V then > we've probably lost already. That's probably not feasible. But I think there's a good amount of sharable bits between the V1.0 and the thead-vector support. > >> But we've got time to sort this out. I don't think the code in question >> was targeted towards gcc-14. > > [In case anyone else is watching: see the forked thread, it might be > amied for 14 now...] It's aimed for evaluation/review given the submission occurred before the gcc-14 deadline. jeff ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: RISC-V: Support XTheadVector extensions 2023-11-17 11:39 RISC-V: Support XTheadVector extensions juzhe.zhong 2023-11-17 16:47 ` Jeff Law 2023-11-17 17:11 ` RISC-V: " Palmer Dabbelt @ 2023-11-18 9:11 ` Christoph Müllner 2 siblings, 0 replies; 15+ messages in thread From: Christoph Müllner @ 2023-11-18 9:11 UTC (permalink / raw) To: juzhe.zhong Cc: gcc-patches, kito.cheng, kito.cheng, cooper.joshua, Robin Dapp, jeffreyalaw, Philipp Tomsich On Fri, Nov 17, 2023 at 12:40 PM juzhe.zhong@rivai.ai <juzhe.zhong@rivai.ai> wrote: > > 90% theadvector extension reusing current RVV 1.0 instructions patterns: > Just change ASM, For example: > > @@ -2923,7 +2923,7 @@ (define_insn "*pred_mulh<v_su><mode>_scalar" > (match_operand:VFULLI_D 3 "register_operand" "vr,vr, vr, vr")] VMULH) > (match_operand:VFULLI_D 2 "vector_merge_operand" "vu, 0, vu, 0")))] > "TARGET_VECTOR" > - "vmulh<v_su>.vx\t%0,%3,%z4%p1" > + "%^vmulh<v_su>.vx\t%0,%3,%z4%p1" > [(set_attr "type" "vimul") > (set_attr "mode" "<MODE>")]) > > + if (letter == '^') > + { > + if (TARGET_XTHEADVECTOR) > + fputs ("th.", file); > + return; > + } > > > For almost all patterns, you just simply append "th." in the ASM prefix. > like change "vmulh.vv" -> "th.vmulh.vv" > > Almost all theadvector instructions are not new features, all same as RVV1.0. > Why do you invent the such ISA doesn't include any features that RVV1.0 doesn't satisfy ? > > I am not explicitly object this patch. But I should know the reason. Palmer already outlined the reason why this has been implemented in HW. I want to add some comments on the specification and the design of the SW support. We have to face the fact here, that T-Head implemented the 0.7.1 draft version of RVV (plus a VLENB CSR). I don't want to waste time and discuss who is to blame for that (this has been done elsewhere in enough detail). Also, there are mechanisms now in place to avoid that something like this happens again. When we call this extension "RVV-0.7.1-draft" (plus VLENB), then we are facing arguments that claim that a RVV "draft" cannot be treated as a ratified extension. Further, there are arguments that only one RVV extension exists (the one that was ratified). Therefore, T-Head's vector extension was several times described as a "custom-extension", which is "non-conforming" (uses encoding space of standard extension). Of course, this hides the fact that the extension is identical to RVV 1.0 to a high degree. Anyway, I don't think that these arguments and descriptions are wrong. So, in order to avoid pointless discussions about what it is, and why it is what it is, we simply accepted this description and gave the extension the name XTheadVector. In RISC-V vendor instructions and CSRs need to have vendor prefixes ("th."). The specification can be found (together with all other XThead* extensions) here: https://github.com/T-head-Semi/thead-extension-spec/blob/master/xtheadvector.adoc Some further details, which are worth mentioning here about this specification: * Factional LMUL values are not supported. * Zvlsseg was an extension in RVV 0.7.1, but is part in RVV 1.0. Since T-Head has these instructions as well, we followed the RVV 1.0 idea and made these instructions mandatory for XTheadVector (ie. avoiding introduction of useless extensions). * Zvamo was an extension in RVV 0.7.1, which was dropped in RVV 1.0. Since T-Head has these instructions as well, we defined XTheadZvamo. So the result is that we have a custom extension, which uses the RVI encoding space and which "by accident" has a huge overlap with RVV 1.0. We are all fine with this, as long as this is our ticket to get the extension supported upstream (in the sense that everyone's opinions are respected and a solution is found which will not trigger useless discussions about things that happened a long time ago). The implementation follows this idea: it is a vendor extension and is kept as separate as possible from standard extensions. However, avoid duplication was one of our most important goals, so we came up with reusing the overlapping functionality by just adding the instruction prefixes. For the intrinsics API, we use a more user-friendly (pragmatic) approach: * state the set of supported RVV intrinsic functions * state the missing support of fractional LMUL values * list the extension-specific intrinsic functions for the additional load/store functionality I hope this gives a good overview of our reasoning. Let me know if you have further questions. BR Christoph > > Btw, stage 1 will close soon. So I will review this patch on GCC-15 as long as all other RISC-V maintainers agree. > > > ________________________________ > juzhe.zhong@rivai.ai ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2023-11-30 12:01 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-11-17 11:39 RISC-V: Support XTheadVector extensions juzhe.zhong 2023-11-17 16:47 ` Jeff Law 2023-11-18 9:45 ` Philipp Tomsich 2023-11-18 10:32 ` Kito Cheng 2023-11-18 15:16 ` 钟居哲 2023-11-20 3:04 ` juzhe.zhong 2023-11-20 16:58 ` Jason Kridner 2023-11-30 12:01 ` 回复:RISC-V: " joshua 2023-11-17 17:11 ` RISC-V: " Palmer Dabbelt 2023-11-17 23:16 ` 钟居哲 2023-11-18 0:01 ` Jeff Law 2023-11-18 0:04 ` 钟居哲 2023-11-28 19:45 ` Palmer Dabbelt 2023-11-28 22:14 ` Jeff Law 2023-11-18 9:11 ` Christoph Müllner
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).