Re: [PATCH v2 02/11] riscv: Restructure callee-saved register save/restore code

just one more nit: Use INVALID_REGNUM as sentinel value for riscv_next_saved_reg, otherwise LGTM, and feel free to commit that separately :) On Mon, Dec 19, 2022 at 9:08 AM Christoph Muellner wrote: > > From: Christoph Müllner > > This patch restructures the loop over the GP registers > which sa

Re: [PATCH v2 03/11] riscv: Add basic XThead* vendor extension support

> + {"xtheadba", ISA_SPEC_CLASS_NONE, 1, 0}, > + {"xtheadbb", ISA_SPEC_CLASS_NONE, 1, 0}, > + {"xtheadbs", ISA_SPEC_CLASS_NONE, 1, 0}, > + {"xtheadcmo", ISA_SPEC_CLASS_NONE, 1, 0}, > + {"xtheadcondmov", ISA_SPEC_CLASS_NONE, 1, 0}, > + {"xtheadfmemidx", ISA_SPEC_CLASS_NONE, 1, 0}, > + {"xthea

Re: [PATCH v2 02/11] riscv: Restructure callee-saved register save/restore code

UM; regno = riscv_next_saved_reg (regno, limit, &offset)) { ... On Mon, Dec 19, 2022 at 5:21 PM Christoph Müllner wrote: > > > > On Mon, Dec 19, 2022 at 7:30 AM Kito Cheng wrote: >> >> just one more nit: Use INVALID_REGNUM as sentinel value for >> riscv_next_

[PATCH] RISC-V: Return const ref. for vl_vtype_info::get_avl_info

Return const reference could prevent unnecessary copying. gcc/ * config/riscv/riscv-vsetvl.h (vl_vtype_info::get_avl_info): Return const reference rather than value. --- gcc/config/riscv/riscv-vsetvl.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config

[committed] RISC-V: Add riscv_vector.h wrapper

Like d0bbecb1c418b680505faa998fe420f0fd4bbfc1, we add a wrapper to prevent it pull stdint.h from standard C library. gcc/testsuite: * gcc.target/riscv/rvv/vsetvl/riscv_vector.h: New. --- .../gcc.target/riscv/rvv/vsetvl/riscv_vector.h| 11 +++ 1 file changed, 11 insertions

Re: [PATCH] RISC-V: Return const ref. for vl_vtype_info: get_avl_info

committed, thanks :) On Wed, Dec 28, 2022 at 7:05 AM juzhe.zhong wrote: > LGTM. > Replied Message > From Kito Cheng > Date 12/27/2022 23:21 > To gcc-patches@gcc.gnu.org > , > kito.ch...@gmail.com , > jim.wilson@gmail.com > , > pal...@dabbelt.com , &g

Re: [PATCH] RISC-V: Add ABI requirement for XTheadFMemIdx tests

LGTM, and maybe change stdint.h to stdint-gcc.h in xtheadmemidx-helpers.h? that could make it more portable on multi-lib testing. On Tue, Nov 7, 2023 at 3:44 AM Christoph Muellner wrote: > > From: Christoph Müllner > > The XTheadFMemIdx tests set the required ABI for RV32, but not > for RV64, wh

Re: [PATCH] RISC-V regression test: Fix FAIL of bb-slp-39.c

LGTM On Tue, Nov 7, 2023 at 10:32 AM Juzhe-Zhong wrote: > > Like s390, add riscv to fix the fail. > > gcc/testsuite/ChangeLog: > > * gcc.dg/vect/bb-slp-39.c: Add RISCV. > > --- > gcc/testsuite/gcc.dg/vect/bb-slp-39.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --

Re: [PATCH] RISC-V: Use stdint-gcc.h in rvv testsuite

LGTM, but title is little bit misleading, it's not really related to rvv, change to either RISC-V or T-head is fine, anyway, you can commit without send v2 :) Christoph Muellner 於 2023年11月7日 週二 17:45 寫道： > From: Christoph Müllner > > stdint.h can be replaced with stdint-gcc.h to resolve some mi

Re: [PATCH] RISC-V: Normalize user vsetvl intrinsics[PR112092]

I thought vsetvli insertion will try to merge them into one for those cases? Could you explain few more reasons why they are not fused now? Not an objection since I could imageing that would be easier to process, just wondering why. On Wed, Nov 8, 2023 at 2:11 PM Juzhe-Zhong wrote: > > Since our

Re: Re: [PATCH] RISC-V: Normalize user vsetvl intrinsics[PR112092]

3 to bb2. > We are not able to remove block bb 1 and bb 2 and create new bb 4 to hold the > vsetvl if bb 1 and bb 2 has the same vsetvl: > > bb 4 (new block) > | > bb 3 > > I don't think we should do this on VSETVL PASS. > ____ > juzhe.

Re: [PATCH] RISC-V: Nan-box the result of movhf on soft-fp16

Thanks for the patch!! We also found the same issue on internal testing works and trying to figure out how to resolve that issue yet, this patch is little bit magic, let me take a closer look.. :P On Wed, Nov 8, 2023 at 11:08 AM KuanLin Chen wrote: > > According to spec, fmv.h checks if the inpu

Re: Re: [PATCH] RISC-V: Normalize user vsetvl intrinsics[PR112092]

On Wed, Nov 8, 2023 at 2:37 PM juzhe.zh...@rivai.ai wrote: > > Another question raise to me. > > Is it necessary we have such many variant of vsetvls? > > I am thinking about redesign: > > __riscv_vsetvl_e8mf8 > __riscv_vsetvl_e16mf4 > __riscv_vsetvl_e32mf2 > __riscv_vsetvl_e64m1 > > They are quit

Re: [PATCH] RISC-V: Fix dynamic LMUL cost model ICE

LGTM, thanks :) On Thu, Nov 9, 2023 at 10:39 AM Juzhe-Zhong wrote: > > When trying to use dynamic LMUL to compile benchmark. > Notice there is a bunch ICEs. > > This patch fixes those ICEs and append tests. > > gcc/ChangeLog: > > * config/riscv/riscv-vector-costs.cc (costs::preferred_new_

Re: [PATCH] minimal support for xtheadv

Hi Yi Xuan: This patch is trivial, and generally LGTM, but I would require putting the spec into https://github.com/riscv-non-isa/riscv-toolchain-conventions before merging this, also don't forget include "RISC-V:" in the title, it would be easier to track during the RISC-V GCC sync meeting :) An

Re: [PATCH] RISC-V: Fix the illegal operands for the XTheadMemidx extension.

Thanks, pushed :) On Thu, Nov 9, 2023 at 3:40 PM Jin Ma wrote: > > The pattern "*extend2_bitmanip" and > "*zero_extendhi2_bitmanip" in bitmanip.md are similar > to the pattern "*th_memidx_bb_extendqi2" and > "*th_memidx_bb_zero_extendhi2" in thead.md, which will > cause the wrong instruction to b

Re: [PATCH] RISC-V: Removed unnecessary sign-extend for vsetvl

Should we need a zero-ext version as well? On Wed, Nov 8, 2023 at 9:39 PM Lehua Ding wrote: > > Committed, thanks Juzhe. > > On 2023/11/8 21:29, juzhe.zhong wrote: > > lgtm > > Replied Message > > From Lehua Ding > > Date 11/08/2023 21:27 > > Togcc-pat

Re: [PATCH] minimal support for xtheadv

Give a few more thought behind my first LGTM: I am OK *IF* binutils bits accepted since it's just kind of bypassing the -march to bintuils to enable those instructions for assembly code. However the situation seems is little more complicated than my expect at beginning...:P Anyway, I still think

Re: [PATCH] RISC-V: Fix bug that XTheadMemPair extension caused fcsr not to be saved and restored before and after interrupt.

LGTM Christoph Müllner 於 2023年11月10日 週五，20:55寫道： > On Fri, Nov 10, 2023 at 8:14 AM Jin Ma wrote: > > > > The t0 register is used as a temporary register for interrupts, so it > needs > > special treatment. It is necessary to avoid using "th.ldd" in the > interrupt > > program to stop the subsequ

Re: [PATCH v2] RISC-V: Fixbug for that XTheadMemPair causes interrupt to fail.

I thought Christoph was already committed? Do you mind describing the difference between v1 and v2? On Fri, Nov 10, 2023 at 9:55 PM Jin Ma wrote: > The t0 register is used as a temporary register for interrupts, so it needs > special treatment. It is necessary to avoid using "th.ldd" in the inte

Re: [PATCH v2 3/3] RISC-V: Add support for XCVbi extension in CV32E40P

I would prefer you suppress those patterns in riscv.cc rather than adjust the including order, T-Head extension goes that way too, so I would prefer to keep it using a consistent way. you can search !TARGET_XTHEAD in riscv.md On Mon, Nov 13, 2023 at 9:36 PM Mary Bennett wrote: > > Spec: > gith

[PATCH] RISC-V: Save/restore ra register correctly [PR112478]

We set ra to fixed register now, but we still need to save/restore that at prologue/epilogue if that has used. gcc/ChangeLog: PR target/112478 * config/riscv/riscv.cc (riscv_save_return_addr_reg_p): Check ra is ever lived. gcc/testsuite/gcc/ChangeLog: PR target/1

[PATCH v2] RISC-V: Implement target attribute

The target attribute which proposed in [1], target attribute allow user to specify a local setting per-function basis. The syntax of target attribute is `__attribute__((target("")))`. and the syntax of `` describes below: ``` ATTR-STRING := ATTR-STRING ';' ATTR | ATTR ATTR:=

Re: [PATCH v2] RISC-V: Implement target attribute

Oh damm, I found it should be v3, but anyway it's the latest version for the target attribute support...

Re: [PATCH] RISC-V: Fix ICE in non-canonical march parsing

LGTM, and BTW...I am thinking we could relax the canonical order during parsing, did you have interesting and time working on that item? On Wed, Nov 15, 2023 at 9:35 AM Patrick O'Neill wrote: > > Passing in a base extension in non-canonical order (i, e, g) causes GCC > to ICE: > xgcc: error: '-ma

Re: [PATCH] RISC-V: Disallow RVV mode address for any load/store[PR112535]

Curious about the code gen impact, does it make IRA/LRA insert one more move like (set (reg:DI) (subreg:DI (reg:V1DI 155) 0)) and then (set (mem:SI (reg:DI)) (const_int 0))? On Wed, Nov 15, 2023 at 3:15 PM Juzhe-Zhong wrote: > This patch is quite obvious patch which disallow for load/store addre

Re: Re: [PATCH] RISC-V: Disallow RVV mode address for any load/store[PR112535]

v v1,0(a5) > lbu a5,%lo(b)(a4) > vse64.v v1,0(a3) > beq a5,zero,.L6 > vmv.x.s a5,v1 > sw zero,0(a5) > > I think the codegen is not good. It should be using scalar load/store. > I think it should be COST MODEL issue. > > ____ > juzhe.zh...

Re: [PATCH] RISC-V: Change unaligned fast/slow/avoid macros to misaligned [PR111557]

ohhh, thanks for fixing that, LGTM! On Thu, Nov 16, 2023 at 7:31 AM Edwin Lu wrote: > > Fix __riscv_unaligned_fast/slow/avoid macro name to > __riscv_misaligned_fast/slow/avoid to be consistent with the RISC-V API Spec > > gcc/ChangeLog: > > * config/riscv/riscv-c.cc (riscv_cpu_cpp_builti

Re: [PATCH] RISC-V: Fix ICE in non-canonical march parsing

toolchain-conventions/pull/14 > Patrick > > On 11/14/23 17:52, Kito Cheng wrote: > > LGTM, and BTW...I am thinking we could relax the canonical order > during parsing, did you have interesting and time working on that > item? > > On Wed, Nov 15, 2023 at 9:35 AM Patrick O&

Re: [PATCH] RISC-V: Save/restore ra register correctly [PR112478]

Committed, thanks for the review and test :) On Thu, Nov 16, 2023 at 7:19 AM Christoph Müllner wrote: > > On Tue, Nov 14, 2023 at 3:15 PM Kito Cheng wrote: > > > > We set ra to fixed register now, but we still need to save/restore that at > > prologue/epilogue if that

Re: [PATCH v2] RISC-V: Implement target attribute

Committed with changelog update :P Thanks for the review. On Thu, Nov 16, 2023 at 7:59 AM Christoph Müllner wrote: > > On Tue, Nov 14, 2023 at 3:15 PM Kito Cheng wrote: > > > > The target attribute which proposed in [1], target attribute allow user > > to specify a lo

Re: Re: [PATCH] RISC-V: testsuite: Fix 32-bit FAILs.

Oh, ok I got why it happened and it is definitely caused by my patch (but not that one, it is caused by another patch[1]), let me describe the reason why I try to emit errors. RISC-V has a crazy number of possible extension combinations, so it's easy to make some mistakes by using some unsupported

Re: [PATCH] RISC-V: Fix bug of tuple move splitter[PR112561]

> diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc > index 6a2009ffb05..08bbb657a06 100644 > --- a/gcc/config/riscv/riscv-v.cc > +++ b/gcc/config/riscv/riscv-v.cc > @@ -374,10 +374,24 @@ void > emit_vlmax_insn_lra (unsigned icode, unsigned insn_flags, rtx *ops, rtx vl) > { >

Re: Re: [PATCH] RISC-V: Fix bug of tuple move splitter[PR112561]

)) > (insn 153 133 154 2 (set (reg:DI 16 a6 [231]) > (reg:DI 6 t1 [247])) "/app/example.c":8:14 206 {*movdi_64bit} > (nil)) > > The latter pass consider "a6" can be replaced by "a7". > Then, the memory address is changed into "a7"

Re: [PATCH] RISC-V: Refactor RVV iterators[NFC]

LGTM, that's a really great clean up :) On Sat, Nov 18, 2023 at 11:12 AM Juzhe-Zhong wrote: > > This patch refactors RVV iteratros for easier maintain. > > E.g. > > (define_mode_iterator V [ > RVVM8QI RVVM4QI RVVM2QI RVVM1QI RVVMF2QI RVVMF4QI (RVVMF8QI > "TARGET_MIN_VLEN > 32") > > RVVM8HI R

Re: [PATCH] RISC-V: Fix bug of tuple move splitter[PR112561]

> On 11/17/23 07:18, Kito Cheng wrote: > > I didn’t take a closer look yet on the ira/lra dump yet, but my feeling > > is that may cause by the earlyclober modifier isn’t work as expect? > > > > Let me take closer look tomorrow. > Remember that constraints aren'

Re: [PATCH V2] RISC-V: Fix bug of tuple move splitter

LGTM, and could you add one more comment before that condition: /* Non-fractional LMUL has whole register moves that don't require a vsetvl for VLMAX. */ On Fri, Nov 17, 2023 at 9:48 PM Juzhe-Zhong wrote: > > Fix segment fault on tuple move: > > bbl loader > z ra 000102

Re: [PATCH v2 1/9] RISC-V: minimal support for xtheadvector

On Sat, Nov 18, 2023 at 12:27 PM Jun Sha (Joshua) wrote: > > This patch is to introduce basic XTheadVector support > (march string parsing and a test for __riscv_xtheadvector) > according to https://github.com/T-head-Semi/thead-extension-spec/ > > Contributors: > Jun Sha (Joshua) >

Re: [PATCH v2 2/9] RISC-V: Handle differences between xtheadvector and vector

> diff --git a/gcc/config/riscv/riscv_th_vector.h > b/gcc/config/riscv/riscv_th_vector.h > new file mode 100644 > index 000..194652032bc > --- /dev/null > +++ b/gcc/config/riscv/riscv_th_vector.h ... > +/* NOTE: This implementation of riscv_vector.h is intentionally short. It > does > +

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

[committed] RISC-V: Fix mismatched new delete for unique_ptr

gcc/ChangeLog: * config/riscv/riscv-target-attr.cc (riscv_target_attr_parser::parse_arch): Use char[] for std::unique_ptr to prevent mismatched new delete issue. (riscv_process_one_target_attr): Ditto. (riscv_process_target_attr): Ditto. --- gcc/config/risc

Re: [PATCH v2] RISC-V: Implement target attribute

Fixed on upstream, thanks for reporting, I guess my host GCC is just too old. It doesn't even not report that bug with -Wall -Wextra.. On Fri, Nov 17, 2023 at 11:41 PM Andreas Schwab wrote: > > In file included from > /daten/riscv64/gcc/gcc-20231117/Build/prev-riscv64-suse-linux/libstdc++-v3/inc

Re: [PATCH 00/44] RISC-V: Various if-conversion fixes and improvements

quick response for this patch set, it's a really huge number of patches, so I'll review it individually, and feel free to commit individual one once got LGTM for each single patch :P On Sun, Nov 19, 2023 at 1:35 PM Maciej W. Rozycki wrote: > > Hi, > > This patch series has come out from a simpl

Re: [PATCH 01/44] testsuite: Add cases for conditional-move and conditional-add operations

ok On Sun, Nov 19, 2023 at 1:35 PM Maciej W. Rozycki wrote: > > Add generic execution tests for expressions that are expected to expand > to conditional-move and conditional-add operations where supported. To > ensure no corner case escapes all relational operators are extensively > covered for

Re: [PATCH 07/44] RISC-V: Use `nullptr' in `riscv_expand_conditional_move'

LGTM On Sun, Nov 19, 2023 at 1:37 PM Maciej W. Rozycki wrote: > > Use `nullptr' for consistency rather than 0 to initialize `invert_ptr'. > > gcc/ > * config/riscv/riscv.cc (riscv_expand_conditional_move): Use > `nullptr' rather than 0 to initialize a pointer. > --- > gcc

Re: [PATCH 03/44] RISC-V: Reorder comment on SFB patterns

LGTM On Sun, Nov 19, 2023 at 1:36 PM Maciej W. Rozycki wrote: > > Our `movcc' expander is no longer specific to short forward branch > targets, so move its associated comment accordingly. > > gcc/ > * config/riscv/riscv.md (movcc): Move comment on SFB > patterns over to...

Re: [PATCH 02/44] RISC-V/testsuite: Add cases for integer SFB cond-move operations

LGTM On Sun, Nov 19, 2023 at 1:36 PM Maciej W. Rozycki wrote: > > Verify, for short forward branch targets and the conditional-move > operations that already work as expected, that if-conversion triggers > via `noce_try_cmove' already at `-mbranch-cost=1' and that extraneous > instructions such a

Re: [PATCH 04/44] RISC-V: Sanitise NEED_EQ_NE_P case with `riscv_emit_int_compare'

LGTM On Sun, Nov 19, 2023 at 1:36 PM Maciej W. Rozycki wrote: > > For the NEED_EQ_NE_P `riscv_emit_int_compare' is documented to only emit > EQ or NE comparisons against zero, however it does not catch incorrect > use where a non-equality comparison has been requested and falls through > to the g

Re: [PATCH 05/44] RISC-V: Fix `mode' usage in `riscv_expand_conditional_move'

LGTM On Sun, Nov 19, 2023 at 1:36 PM Maciej W. Rozycki wrote: > > In `riscv_expand_conditional_move' `mode' is initialized right away from > `GET_MODE (dest)', so remove needless references that refrain from using > the local variable. > > gcc/ > * config/riscv/riscv.cc (riscv_exp

Re: [PATCH 06/44] RISC-V: Avoid repeated GET_MODE calls in `riscv_expand_conditional_move'

LGTM On Sun, Nov 19, 2023 at 1:36 PM Maciej W. Rozycki wrote: > > Use `mode0' and `mode1' shorthands respectively for `GET_MODE (op0)' and > `GET_MODE (op1)' to improve code readability. > > gcc/ > * config/riscv/riscv.cc (riscv_expand_conditional_move): Use > `mode0' and

Re: [PATCH 08/44] RISC-V: Simplify EQ vs NE selection in `riscv_expand_conditional_move'

LGTM On Sun, Nov 19, 2023 at 1:37 PM Maciej W. Rozycki wrote: > > Just choose between EQ and NE at `gen_rtx_fmt_ee' invocation, removing > an extraneous variable only referred once and improving code clarity. > > gcc/ > * config/riscv/riscv.cc (riscv_expand_conditional_move): Remo

Re: [PATCH 10/44] RISC-V/testsuite: Add branched cases for integer cond-move operations

LGTM, thanks for those test cases! On Sun, Nov 19, 2023 at 1:37 PM Maciej W. Rozycki wrote: > > Verify, for T-Head, Ventana and Zicond targets and the integer > conditional-move operations that already work as expected, that > if-conversion does *not* trigger at the respective sufficiently low >

Re: [PATCH 11/44] RISC-V/testsuite: Add branchless cases for integer cond-move operations

LGTM. Just one minor comment, I think we don't really need to check rv64 or rv32 for those compiled without any header file test, but I am fine with that. On Sun, Nov 19, 2023 at 1:37 PM Maciej W. Rozycki wrote: > > Verify, for T-Head, Ventana and Zicond targets and the integer > conditional-move

Re: [PATCH 12/44] RISC-V/testsuite: Add branched cases for FP cond-move operations

LGTM On Sun, Nov 19, 2023 at 1:38 PM Maciej W. Rozycki wrote: > > Verify, for Ventana and Zicond targets and the ordered floating-point > conditional-move operations that already work as expected, that > if-conversion does *not* trigger at `-mbranch-cost=2' setting, which > makes original branche

Re: [PATCH 14/44] RISC-V: Also invert the cond-move condition for GEU and LEU

LGTM On Sun, Nov 19, 2023 at 1:39 PM Maciej W. Rozycki wrote: > > Update `riscv_expand_conditional_move' and handle the missing GEU and > LEU operators there, avoiding an extraneous conditional set operation, > such as with this output: > > sgtua0,a0,a1 > seqza1,a0 >

Re: [PATCH 16/44] RISC-V/testsuite: Add branchless cases for GEU and LEU cond-move operations

LGTM On Sun, Nov 19, 2023 at 1:38 PM Maciej W. Rozycki wrote: > > Verify, for Ventana and Zicond targets and the GEU and LEU > conditional-move operations, that if-conversion triggers via > `noce_try_cmove' at `-mbranch-cost=4' setting, which makes branchless > code sequences produced by if-conve

Re: [PATCH 1/1] RISC-V: Add support for XCVmem extension in CV32E40P

> diff --git a/gcc/config/riscv/constraints.md b/gcc/config/riscv/constraints.md > index 718b4bd77df..f67bff0940f 100644 > --- a/gcc/config/riscv/constraints.md > +++ b/gcc/config/riscv/constraints.md > @@ -35,6 +35,17 @@ > > ;; General constraints > > +(define_memory_constraint "m" > + "An addre

Re: RISC-V: Support XTheadVector extensions

I am less worry about the thead vector combined with other zv extension, instead we should reject those combinations at all. My reason is thead vector is transitional products, they won't have any further new products with that longer, also it's not compatible with all other zv extension in theory

Re: [PATCH V2] RISC-V: Optimize a special case of VLA SLP

The optimization is relatively small, so LGTM, thanks :) On Fri, Nov 24, 2023 at 7:18 AM Juzhe-Zhong wrote: > > When working on fixing bugs of zvl1024b. I notice a special VLA SLP case > can be better optimized. > > v = vec_perm (op1, op2, { nunits - 1, nunits, nunits + 1, ... }) > > Before this

Re: [PATCH 1/4] [RISC-V] prefer Zicond primitive semantics to SFB

Personally I don't like to play with the pattern order to tweak the code gen since it kinda introduces implicit relation/rule here, but I guess the only way to prevent that is to duplicate the pattern for SFB again, which is not an ideal solution... Anyway, it's obviously a better code gen, so LGT

Re: [PATCH] RISC-V: Support highpart register overlap for vwcvt

OK, thanks for moving that forward! but just one nit: don't include godbolt.org url as possible since it's not permanently valid. On Wed, Nov 29, 2023 at 4:36 PM juzhe.zh...@rivai.ai wrote: > > Sorry for sending it twice. > > Add > > Co-authored-by: kito-cheng

Re: [PATCH v1 1/1] RISC-V: Initial RV64E and LP64E support

Pre-approve the fix :) On Thu, Nov 30, 2023 at 6:07 AM Tsukasa OI wrote: > > Hi Patrick, > > Found a cause (although GCC is functionally correct, I forgot to fix > corresponding test case [which assumes that 'E' is not ratified]). > > > #if !defined(__riscv_e) || (__riscv_e != (1 * 1000 * 1000 +

Re: [PATCH] RISC-V: Support widening register overlap for vf4/vf8

LGTM, thanks :) On Thu, Nov 30, 2023 at 2:49 PM Juzhe-Zhong wrote: > > > size_t > foo (char const *buf, size_t len) > { > size_t sum = 0; > size_t vl = __riscv_vsetvlmax_e8m8 (); > size_t step = vl * 4; > const char *it = buf, *end = buf + len; > for (; it + step <= end;) > { >

Re: [PATCH] RISC-V: Update crypto vector ISA info with latest spec

LGTM On Thu, Nov 30, 2023 at 2:16 PM Feng Wang wrote: > > This patch add the Zvkb subset of crypto vector extension. The > corresponding test cases have aslo been modified. > > gcc/ChangeLog: > > * common/config/riscv/riscv-common.cc: Add zvkb ISA info. > * config/riscv/riscv.opt:

Re: Re: [Committed] RISC-V: Support VLS unary floating-point patterns

It seems because math.h, similar issue as stdint.h, does math.h necessary for the test case? juzhe.zh...@rivai.ai 於 2023年9月20日 週三 08:44 寫道： > I didn't see this issue. > They should be the bogus FAILs. > We should either fix testcases or ignore them. > > -- > juzhe.zh.

Re: [Committed] RISC-V: Fix Demand comparison bug[VSETVL PASS]

Does it also happened on gcc 13 branch? If so plz backport :) Juzhe-Zhong 於 2023年9月20日 週三 11:09 寫道： > This bug is exposed when we support VLS integer conversion patterns. > > FAIL: c-c++-common/torture/pr53505.c execution. > > This is because incorrect vsetvl elimination by Phase 4: > >10318

Re: [PATCH] RISC-V: Remove math.h import to resolve missing stubs failures

LGTM Patrick O'Neill 於 2023年9月20日 週三 18:07 寫道： > Resolves some of the missing stubs failures: > fatal error: gnu/stubs-lp64d.h: No such file or directory > compilation terminated. > > 2023-09-20 Juzhe Zhong > > gcc/testsuite/ChangeLog: > > * gcc.target/riscv/rvv/autovec/vls/def.h: Remov

Re: [PATCH] RISC-V: Enable undefined support for RVV auto-vectorization[PR110751]

Cool, LGTM as well! On Thu, Sep 21, 2023 at 10:11 AM Robin Dapp wrote: > > Hi Juzhe, > > with the middle-end changes that's a nice improvement. LGTM. > > Regards > Robin

Re: [Committed] RISC-V: Support VLS unary floating-point patterns

GCC has built in function[1] for those math function stuff, e.g. __builtin_ceilf, so we don't really need math.h :) [1] https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html On Thu, Sep 21, 2023 at 11:20 AM Palmer Dabbelt wrote: > > On Wed, 20 Sep 2023 10:47:23 PDT (-0700), Patrick O'Neill wrot

Re: [PATCH v1] RISC-V: Remove FP run test for ceil.

I guess it just needs more checks than `target { riscv_vector }`, maybe something like `target { riscv_vector_zvfh }`, but anyway I am fine to drop this for now. On Sat, Sep 23, 2023 at 2:11 AM Li, Pan2 wrote: > > Committed, thanks Juzhe. > > > > Pan > > > > From: 钟居哲 > Sent: Saturday, September

Re: [PATCH 2/2] RISC-V: Add support for XCValu extension in CV32E40P

Hi Mary: Several inline comments, mostly are related to the RTX pattern. I guess we don't really need those unspec except clip*. > diff --git a/gcc/config/riscv/corev.md b/gcc/config/riscv/corev.md > index 59aeafe485f..30c8bcbe476 100644 > --- a/gcc/config/riscv/corev.md > +++ b/gcc/config/riscv/

Re: [PATCH V3] RISC-V: Remove mem-to-mem VLS move pattern[PR111566]

> (define_insn_and_split "*mov" >[(set (match_operand:VLS_AVL_IMM 0 "reg_or_mem_operand" "=vr, m, vr") > (match_operand:VLS_AVL_IMM 1 "reg_or_mem_operand" " m,vr, vr"))] >"TARGET_VECTOR > - && (register_operand (operands[0], mode) > + && (can_create_pseudo_p () Why add `can_c

Re: Re: [PATCH V3] RISC-V: Remove mem-to-mem VLS move pattern[PR111566]

that pattern between reload and split2? > > I have no ideal. Some fortran tests just need recognization of mem-to-mem > pattern before RA. > I don't know the reason. > > ____ > juzhe.zh...@rivai.ai > > > From: Kito Cheng > Date: 2023-

Re: [PATCH] RISC-V: Describe -march behavior for dependent extensions

LGTM, BTW, based on the discussion[1], my understanding is: depend == require == imply for the RISC-V ISA spec. [1] https://github.com/riscv/riscv-v-spec/issues/723#issuecomment-922153867 On Wed, Jul 3, 2024 at 9:21 AM Patrick O'Neill wrote: > From: Palmer Dabbelt > > gcc/ChangeLog: > >

Re: [PATCH] RISC-V: Use tu policy for first-element vec_set [PR115725].

Ok for trunk and gcc 14 juzhe.zh...@rivai.ai 於 2024年7月3日 週三 17:43 寫道： > LGTM > > -- > juzhe.zh...@rivai.ai > > > *From:* Robin Dapp > *Date:* 2024-07-03 17:39 > *To:* gcc-patches > *CC:* rdapp.gcc ; palmer ; Kito > Cheng ; juzhe.z

Re: [PATCH v1] RISC-V: Bugfix vfmv insn honor zvfhmin for FP16 SEW [PR115763]

LGTM and ok for gcc 14 as well, btw an idea is that actually could passed via gpr, I mean fpr->gpr and then vmv.v.x, but it's not block commend for this patch. 钟居哲 於 2024年7月3日 週三 22:18 寫道： > LGTM。 > > -- > juzhe.zh...@rivai.ai > > > *From:* pan2.li > *Date:* 2024-07-

Re: [PATCH 2/2] [RISC-V] c implies zca, and conditionally zcf & zcd

LGTM, thanks :) On Tue, Jul 9, 2024 at 10:47 AM Fei Gao wrote: > According to Zc-1.0.4-3.pdf from > > https://github.com/riscvarchive/riscv-code-size-reduction/releases/tag/v1.0.4-3 > The rule is that: > 1. C always implies Zca > 2. C+F implies Zcf (RV32 only) > 3. C+D implies Zcd > > gcc/Change

Re: [PATCH 1/2] RISC-V: Add support for B standard extension

Hi Edwin: Could you add B into riscv_combine_info as well? extension should list there if that extension is just an alias of those extensions, so that GCC will add b into arch string when zba, zbb, zbs, that's necessary during arch string canonicalize, which could be used during multilib match :)

Re: [PATCH 1/2] RISC-V: Add support for B standard extension

Forgot to say: either v2 or another patch are fine to me :) On Tue, Jul 9, 2024 at 11:13 AM Kito Cheng wrote: > > Hi Edwin: > > Could you add B into riscv_combine_info as well? extension should list > there if that extension is just an alias of those extensions, so that > G

Re: [PATCH 3/6] RISC-V: Attribute parser: Use alloca() instead of new + std::unique_ptr

IIRC Jeff mentions that it may introduce buffer overflow if the input string is long enough. On Tue, Jul 9, 2024 at 8:48 PM Christoph Müllner wrote: > > Allocating an object on the heap with new, wrapping it in a > std::unique_ptr and finally getting the buffer via buf.get() > is a correct way to

Re: [PATCH 4/6] RISC-V: Fix comment/naming in attribute parsing code

LGTM, that must be something I didn't update during...reference code from ARM :P On Tue, Jul 9, 2024 at 8:48 PM Christoph Müllner wrote: > > Function target attributes have to be separated by semi-colons. > Let's fix the comment and variable naming to better explain what > the code does. > > gcc

Re: [PATCH 1/6] RISC-V: testsuite: Properly gate LTO tests

LGTM On Tue, Jul 9, 2024 at 8:48 PM Christoph Müllner wrote: > > There are two test cases with the following skip directive: > dg-skip-if "" { *-*-* } { "-flto -fno-fat-lto-objects" } > This reads as: skip if both '-flto' and '-fno-fat-lto-objects' > are present. This is not the case if only '

Re: [PATCH 2/6] RISC-V: Deduplicate arch subset list processing

LGTM, thanks for simplifying this :) On Tue, Jul 9, 2024 at 8:48 PM Christoph Müllner wrote: > > We have a code duplication in riscv_set_arch_by_subset_list() and > riscv_parse_arch_string(), where the latter function parses an ISA string > into a subset_list before doing the same as the former f

Re: [PATCH 6/6] RISC-V: Allow adding enabled extension via target arch attributes

LGTM, thanks for fixing this...and will take a detailed review on the remaining patch in the next few days :) On Tue, Jul 9, 2024 at 8:51 PM Christoph Müllner wrote: > > The set of enabled extensions can be extended via target arch function > attributes by listing each extension with a '+' prefi

Re: [PATCH] RISC-V: Disable misaligned vector access in hook riscv_slow_unaligned_access

> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc > index 61fa74e9322..87270fd7af4 100644 > --- a/gcc/config/riscv/riscv.cc > +++ b/gcc/config/riscv/riscv.cc > @@ -10271,7 +10271,7 @@ riscv_cannot_copy_insn_p (rtx_insn *insn) > static bool > riscv_slow_unaligned_access (machine

Re: [PATCH 1/3 v3] RISC-V: Add vector type of BFloat16 format

OK for this patch set, I know you already got LGTM from JuZhe or me before, so just an explicitly ack to let you know it's still OK once CI is passed. On Thu, Jul 11, 2024 at 3:11 PM Feng Wang wrote: > > v3: Rebase > v2: Rebase > The vector type of BFloat16 format is added in this patch, > subseq

Re: [PATCH v2] RISC-V: NO_WARNING preferred else value for RVV

Lgtm, thanks :) YunQiang Su 於 2024年7月11日 週四，20:45寫道： > From: YunQiang Su > > PR target/115840. > > In riscv_preferred_else_value, we create an uninitialized tmp var > for else value, instead of the 0 (as default_preferred_else_value) > or the pre-exists VAR (as aarch64 does), so that we can use

Re: [PATCH v2] RISC-V: Disable misaligned vector access in hook riscv_slow_unaligned_access[PR115862]

LGTM, but...this seems to have discovered another bug in the current trunk? could you take a look? Will trigger by -O2 -march=rv64gcv_zvl512b -mabi=lp64d or -O2 -march=rv64gcv_zvl256b -mabi=lp64d during RTL pass: combine x.c: In function '__libc_mallinfo': x.c:47:1: internal compiler error: in sm

Re: Re: [PATCH v2] RISC-V: Disable misaligned vector access in hook riscv_slow_unaligned_access[PR115862]

x27;t PR115862 the same bug as this one? > > ____ > xu...@eswincomputing.com > > > From: Kito Cheng > Date: 2024-07-12 14:33 > To: Li Xu > CC: gcc-patches; juzhe.zhong; rdapp.gcc > Subject: Re: [PATCH v2] RISC-V: Disable misaligned vector access in hook > riscv_slo

[committed] RISC-V: Add SiFive extensions, xsfvcp and xsfcease

We have already upstreamed these extensions into binutils, and now we need GCC to recognize these extensions and pass them to binutils as well. We also plan to upstream intrinsics in the near future. :) gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_implied_info): Add xsfvcp.

Re: [PATCH 5/6] RISC-V: Rewrite target attribute handling

LGTM, and could you backport this to the GCC 14 branch as well? On Tue, Jul 9, 2024 at 8:50 PM Christoph Müllner wrote: > > The target-arch attribute handling in RISC-V is only a few months old, > but already saw a rewrite (9941f0295a14), which addressed an important > issue. This rewrite introd

Re: [PATCH 5/6] RISC-V: Rewrite target attribute handling

On Tue, Jul 16, 2024 at 1:09 AM Christoph Müllner wrote: > > On Mon, Jul 15, 2024 at 11:10 AM Kito Cheng wrote: > > > > LGTM, and could you backport this to the GCC 14 branch as well? > > Rebased, retested (multilib), fixed an issue related to Zca/Zcd and pushed. > &

Re: [PATCH 5/6] RISC-V: Rewrite target attribute handling

On Tue, Jul 16, 2024 at 4:25 PM Christoph Müllner wrote: > > On Tue, Jul 16, 2024 at 4:45 AM Kito Cheng wrote: > > > > On Tue, Jul 16, 2024 at 1:09 AM Christoph Müllner > > wrote: > > > > > > On Mon, Jul 15, 2024 at 11:10 AM Kito Cheng wrote: > &g

[PATCH] RISC-V: Implement __init_riscv_features_bits, __riscv_feature_bits, and __riscv_vendor_feature_bits

This provides a common abstraction layer to probe the available extensions at run-time. These functions can be used to implement function multi-versioning or to detect available extensions. The advantages of providing this abstraction layer are: - Easy to port to other new platforms. - Easier to m

Re: [PATCH] RISC-V: Implement __init_riscv_features_bits, __riscv_feature_bits, and __riscv_vendor_feature_bits

On Wed, Jul 17, 2024 at 1:14 AM Palmer Dabbelt wrote: > > On Tue, 16 Jul 2024 07:49:13 PDT (-0700), kito.ch...@sifive.com wrote: > > This provides a common abstraction layer to probe the available extensions > > at > > run-time. These functions can be used to implement function > > multi-version

Re: [PATCH] RISC-V: Fix testcase missing arch attribute

LGTM :) On Wed, Jul 17, 2024 at 9:15 AM Edwin Lu wrote: > > The C + F extentions implies the zcf extension on rv32. Add missing zcf > extension for the rv32 target. > > gcc/testsuite/ChangeLog: > > * gcc.target/riscv/target-attr-16.c: Update expected assembly > > Signed-off-by: Edwin Lu

[PATCH v2] RISC-V: Implement __init_riscv_features_bits, __riscv_feature_bits, and __riscv_vendor_feature_bits

This provides a common abstraction layer to probe the available extensions at run-time. These functions can be used to implement function multi-versioning or to detect available extensions. The advantages of providing this abstraction layer are: - Easy to port to other new platforms. - Easier to m

Re: [PATCH] RISC-V: Add Zvfbfwma extension to the -march= option

LGTM, I agree we should only implement what Embedded Processor implies, we have no way to know that from the arch string On Wed, May 15, 2024 at 1:35 PM Xiao Zeng wrote: > > This patch would like to add new sub extension (aka Zvfbfwma) to the > -march= option. It introduces a new data type BF

Re: [PATCH] RISC-V: Fix cbo.zero expansion for rv32

LGTM :) On Wed, May 15, 2024 at 2:48 PM Christoph Müllner wrote: > > Emitting a DI pattern won't find a match for rv32 and manifests in > the failing test case gcc.target/riscv/cmo-zicboz-zic64-1.c. > Let's fix this in the expansion and also address the different > code that gets generated for rv

Re: [PATCH] RISC-V: testsuite: Drop march-string in cpymemsi-1.c

Just one minor question > diff --git a/gcc/testsuite/gcc.target/riscv/cpymemsi-1.c > b/gcc/testsuite/gcc.target/riscv/cpymemsi-1.c > index 983b564ccaf..aee54d9aa00 100644 > --- a/gcc/testsuite/gcc.target/riscv/cpymemsi-1.c > +++ b/gcc/testsuite/gcc.target/riscv/cpymemsi-1.c > @@ -1,6 +1,5 @@ > /

<    1   2   3   4   5   6   7   8   9   10   >