Re: [PATCH] RISC-V: Add an implicit dependency for Zawrs

LGTM, and let me know if you need my help to commit that :) On Mon, Sep 30, 2024 at 9:37 AM Xiao Zeng wrote: > > There is a description in > : > > "The instructions in the Zawrs extension are only useful in conjunction > with th

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

Hi Yang-Yu Yeah, I was planning to send another version to update the interface to the latest, but I'm just too busy (too lazy?) to update, anyway will send new revision soon, However...one of our folk are also working on target_clone/target_versions, not sure what your current status is? Maybe w

Re: [PATCH] RISC-V: Implement TARGET_CAN_INLINE_P

Hi Yang-Yu: > > Specially, we can reproduce the result on BananaPi-F3 Hardware: > > Use this GCC branch with my patch: > https://github.com/cyyself/gcc/tree/rv_can_inline > > And compile the coremark on this branch: > https://github.com/cyyself/coremark/tree/rva22_v_hotspot > > With command `make

Re: [RFC PATCH] Enable vectorization for unknown tripcount in very cheap cost model but disable epilog vectorization.

> > So should we adjust very-cheap to allow niter peeling as proposed or > > should we switch > > the default at -O2 to cheap? > > Any thoughts from other backend maintainers? No preference from RISC-V since is variable length vector flavor, so no epilogue for those case, I mean it's already vecto

Re: [PATCH] RISC-V/libgcc: Save/Restore routines for E goes with ABI.

LGTM, you just need write few more boring ChangeLog in commit log like below: libgcc/ChangeLog: * config/riscv/save-restore.S: Check with __riscv_abi_rve rather than __riscv_32e. Anyway I committed to trunk with that changelog :) On Fri, Sep 27, 2024 at 5:19 PM Tsung Chun Lin wrote: > >

Re: [PATCH v1 2/2] RISC-V: Add testcases for form 4 of signed scalar SAT_ADD

LGTM 於 2024年9月20日 週五 10:21 寫道： > From: Pan Li > > Form 4: > #define DEF_SAT_S_ADD_FMT_4(T, UT, MIN, MAX) \ > T __attribute__((noinline))\ > sat_s_add_##T##_fmt_4 (T x, T y) \ > {

Re: [PATCH v1 1/2] RISC-V: Add testcases for form 3 of signed scalar SAT_ADD

LGTM 於 2024年9月20日 週五 10:19 寫道： > From: Pan Li > > This patch would like to add testcases of the signed scalar SAT_ADD > for form 3. Aka: > > Form 3: > #define DEF_SAT_S_ADD_FMT_3(T, UT, MIN, MAX) \ > T __attribute__((noinline))\ > sat_s_add_##T##_fmt

Re: [PATCH] RISC-V: Allow zero operand for DI variants of vssubu.vx

LGTM, thanks :) Bohan Lei 於 2024年9月18日 週三 05:28 寫道： > The RISC-V vector machine description relies on the helper function > `sew64_scalar_helper` to emit actual insns for the DI variants of > vssub.vx and vssubu.vx. This works with vssub.vx, but can cause > problems with vssubu.vx with the scal

Re: [PATCH] riscv: Fix duplicate assmbler label in @tlsdesc insn

LGTM, thanks :) Andreas Schwab 於 2024年9月16日 週一 10:21 寫道： > Use %= instead of maintaining a sequence number manually, so that it > doesn't result in a duplicate assembler label when the insn is duplicated. > > PR target/116693 > * config/riscv/riscv.cc (riscv_legitimize_tls_addres

Re: [PATCH] RISC-V: Lookup reversely in riscv_select_multilib_by_abi

LGTM, thanks for catching this, but commit log seems not right? should it be -print-multi-directory or -print-multi-os-directory rather than --print-multilib-os-dir? (I guess should be -print-multi-directory per your output) Anyway, you can go ahead and push that after the fix:) On Thu, Sep 5, 2

Re: [RFC PATCH] RISC-V: Add support for LP64DV

Just remember adding a system wide vector calling convention has wide compatible issues we need to worry about, like jump buf (for setjmp/longjmp) will need to keep vector status, it doesn't need to keep before since all vectors are call-clobber by default. Also that may cause performance issue fo

Re: [PATCH v4] RISC-V: Supports Profiles in '-march' option.

I don't see there is conflict if we want to support both gnu2024 and RVI profiles? also I am not sure what the usage scenarios for the gnu2024 and how we defined that? On Wed, Sep 4, 2024 at 6:49 AM Palmer Dabbelt wrote: > > On Tue, 20 Aug 2024 23:18:36 PDT (-0700), jia...@iscas.ac.cn wrote: > >

Re: [PATCH] RISC-V: Add missing mode_idx for vrol and vror

committed to trunk. > You don't need an OK of course but LGTM. > > When I found another instance of this I was thinking about having > exhaustive self tests for those attributes. Maybe a good learning > exercise? Yeah, that would be great, otherwise it's not really easy to maintain those attribu

[PATCH] RISC-V: Add missing mode_idx for vrol and vror

We add pattern for vector rotate, but seems like we forgot adding mode_idx which used in AVL propgation (riscv-avlprop.cc). gcc/ChangeLog: * config/riscv/vector.md (mode_idx): Add vrol and vror. gcctestsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/rotr.c: New. --- gcc/config/

Re: [PATCH] RISC-V: Optimize the cost of the DFmode register move for RV32.

LGTM, good catch, and I am a little suppressed that we don't handle "case REG" in riscv_rtx_costs...but adding that might disturb too much at once, so this fix is fine for now, and ...and I guess we should improve that in future. On Tue, Aug 27, 2024 at 5:19 PM Xianmiao Qu wrote: > > Currently,

Re: [PATCH] RISC-V: Expand vec abs without masking.

LGTM Robin Dapp 於 2024年8月23日 週五 00:04 寫道： > Hi, > > standard abs synthesis during expand is max (a, -a). This > expansion has the advantage of avoiding masking and is thus potentially > faster than the a < 0 ? -a : a synthesis. > > Regtested on rv64gcv_zvfh_zvbb. > > Regards > Robin > > gcc/Ch

Re: [PATCH v1 2/2] RISC-V: Add testcases for unsigned scalar .SAT_TRUNC form 3

LGTM 於 2024年8月17日 週六 19:37 寫道： > From: Pan Li > > This patch would like to add test cases for the unsigned scalar > .SAT_TRUNC form 3. Aka: > > Form 3: > #define DEF_SAT_U_TRUC_FMT_3(NT, WT) \ > NT __attribute__((noinline)) \ > sat_u_truc_##WT##_to_##NT##_fmt_3 (WT x) \ >

Re: [PATCH v1 1/2] RISC-V: Add testcases for unsigned scalar .SAT_TRUNC form 2

LGTM 於 2024年8月17日 週六 19:37 寫道： > From: Pan Li > > This patch would like to add test cases for the unsigned scalar > .SAT_TRUNC form 2. Aka: > > Form 2: > #define DEF_SAT_U_TRUC_FMT_2(NT, WT) \ > NT __attribute__((noinline)) \ > sat_u_truc_##WT##_to_##NT##_fmt_2 (WT x) \ >

Re: [PATCH] RISC-V: Fix factor in dwarf_poly_indeterminate_value [PR116305]

LGTM, thanks for fixing that :) On Wed, Aug 14, 2024 at 2:06 PM 曾治金 wrote: > > This patch is to fix the bug (BugId:116305) introduced by the commit > bd93ef for risc-v target. > > The commit bd93ef changes the chunk_num from 1 to TARGET_MIN_VLEN/128 > if TARGET_MIN_VLEN is larger than 128 in risc

Re: [PATCH] RISC-V: Add --with-cmodel configure option

compact code mode is our downstream stuffs, so...it should drop it from the patch Hau Hsu 於 2024年8月2日 週五 12:17 寫道： > Sometimes we want to use default cmodel other than medlow. Add a GCC > configure option for that. > > gcc/ChangeLog: > > * config.gcc (riscv*-*-*): Add support for --with-cmod

Re: [PATCH] RISC-V: Reject 'd' extension with ILP32E ABI

LGTM, although I thought for a few seconds whether to use sorry or error, but I think we don't really feel sorry for that case, so just error is fine :P On Wed, Jul 31, 2024 at 5:33 AM Patrick O'Neill wrote: > > Also add a testcase for -mabi=lp64d where 'd' is required. > > gcc/ChangeLog: > >

Re: [PATCH] RISC-V: Remove configure check for zabha

LGTM, thanks :) On Tue, Jul 30, 2024 at 10:53 AM Patrick O'Neill wrote: > > This patch removes the zabha configure check since it's not a breaking change > and updates the existing zaamo/zalrsc comment. > > gcc/ChangeLog: > > * common/config/riscv/riscv-common.cc > (riscv_subset

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

> > This API is intended to provide the capability to query minimal common > > available extensions on the system. > > > > Proposal in riscv-c-api-doc: > > https://github.com/riscv-non-isa/riscv-c-api-doc/pull/74 > > That's not merged, but I'm not sure what the rules are on stability for > the C

Re: [PATCH] RISC-V: Add configure check for B extention support

LGTM, although I said no binutils check for zacas and zabha, but B is a different situation since GCC will add that if zba, zbb and zbs are all present. On Thu, Jul 25, 2024 at 7:51 AM Edwin Lu wrote: > > Binutils 2.42 and before don't recognize the B extension in the march > strings even thoug

Re: [PATCH] RISC-V: xtheadmemidx: Disable pre/post-modify addressing if RVV is enabled

LGTM :) On Wed, Jul 24, 2024 at 9:31 PM Christoph Müllner wrote: > > When enabling XTheadMemIdx, we enable the pre- and post-modify > addressing modes in the RISC-V backend. > Unfortunately, the auto_inc_dec pass will then attempt to utilize > this feature regardless of the mode class (i.e. scala

Re: [PATCH] RISC-V: Disable Zba optimization pattern if XTheadMemIdx is enabled

Yeah, OK once your local test passes :) On Wed, Jul 24, 2024 at 4:38 PM Christoph Müllner wrote: > > Is it OK to backport to GCC 14 (patch applies cleanly, test is running)? > > On Wed, Jul 24, 2024 at 9:25 AM Kito Cheng wrote: > > > > LGTM :) > > > > On We

Re: [PATCH] RISC-V: Error early with V and no M extension. [PR116036]

LGTM, although I was a little late to join the meeting yesterday, but I vaguely know you guys are discussing this, that combination really does not make too much sense and also the LLVM side already does the same thing :) On Wed, Jul 24, 2024 at 8:50 PM Robin Dapp wrote: > > Hi, > > for calculati

Re: [PATCH] RISC-V: Disable Zba optimization pattern if XTheadMemIdx is enabled

LGTM :) On Wed, Jul 24, 2024 at 3:16 PM Christoph Müllner wrote: > > It is possible that the Zba optimization pattern zero_extendsidi2_bitmanip > matches for a XTheadMemIdx INSN with the effect of emitting an invalid > instruction as reported in PR116035. > > The pattern above is used to emit a z

Re: [PATCH v2] RISC-V: Add basic support for the Zacas extension

I incline do not add skip_zacas stuffs (although skip_zabha is already there but that's fine), because that's different situation compare to the zaamo/zalrsc, zaamo/zalrsc should automatically append if a extension is available, which is new behavior and new extensions. But zacas is only added whe

[PATCH v4] RISC-V: Implement __init_riscv_feature_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 v3] RISC-V: Implement __init_riscv_feature_bits, __riscv_feature_bits, and __riscv_vendor_feature_bits

thanks for catching that, seem like we only check for the linux path :) Edwin Lu 於 2024年7月23日 週二 02:45 寫道： > Hi Kito, > > > On 7/22/2024 8:19 AM, Kito Cheng wrote: > > Corresponding implementation in compiler-rt already merged in LLVM > > side, so I plan to merge this i

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

Corresponding implementation in compiler-rt already merged in LLVM side, so I plan to merge this into trunk tomorrow if no strong objections. NOTE: This has been tested with clang/llvm within our internal CI. On Mon, Jul 22, 2024 at 10:16 PM Kito Cheng wrote: > > This provides a

[PATCH v3] RISC-V: Implement __init_riscv_feature_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

[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: 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

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

[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 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

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

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

[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: 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

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: [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 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] 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 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 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 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 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 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 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 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 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 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] 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] 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: Fix unresolved mcpu-[67].c tests

LGTM, thanks :) On Fri, Jun 21, 2024 at 7:33 PM Craig Blackmore < craig.blackm...@embecosm.com> wrote: > These tests check the sched2 dump, so skip them for optimization levels > that do not enable sched2. > > gcc/testsuite/ChangeLog: > > * gcc.target/riscv/mcpu-6.c: Skip for -O0, -O1, -O

Re: [PATCH 3/3] RISC-V: Add md files for vector BFloat16

LGTM On Fri, Jun 21, 2024 at 9:56 AM Feng Wang wrote: > Accroding to the BFloat16 spec, some vector iterators and new pattern > are added in md files. > > All these changes passed the rvv test and rvv-intrinsic test for bfloat16. > > gcc/ChangeLog: > > * config/riscv/riscv.md: Add new in

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

LGTM juzhe.zh...@rivai.ai 於 2024年6月21日 週五 12:25 寫道： > LGTM > > -- > juzhe.zh...@rivai.ai > > > *From:* Feng Wang > *Date:* 2024-06-21 09:54 > *To:* gcc-patches > *CC:* kito.cheng ; juzhe.zhong > ; jinma.contrib ; Feng Wang > > *Subject:* [PATCH 1/3] RISC-V: Add vec

Re: [PATCH v4] RISC-V: Promote Zaamo/Zalrsc to a when using an old binutils

LGTM :) Patrick O'Neill 於 2024年6月19日 週三 05:40 寫道： > Binutils 2.42 and before don't support Zaamo/Zalrsc. When users specify > both Zaamo and Zalrsc, promote them to 'a' in the -march string. > > This does not affect testsuite results for users with old versions of > binutils. > Testcases that fa

Re: [RFC v3] RISC-V: Promote Zaamo/Zalrsc to a when using an old binutils

When 'a' is put into riscv_combine_info, 'a' will only be added into arch string only if zaamo *AND* zalrsc is there, so zalrsc only won't trigger that. On Tue, Jun 18, 2024 at 1:35 PM Patrick O'Neill wrote: > > > > On Mon, Jun 17, 2024 at 5:51 PM Kito

Re: [RFC v3] RISC-V: Promote Zaamo/Zalrsc to a when using an old binutils

Maybe just add 'a' to riscv_combine_info and other logic to keep the same (e.g. keep the logic for skip_zaamo_zalrsc)? On Tue, Jun 18, 2024 at 8:03 AM Patrick O'Neill wrote: > > Binutils 2.42 and before don't support Zaamo/Zalrsc. Promote Zaamo/Zalrsc to > 'a' in the -march string when assembling

Re: [PATCH] riscv: Allocate enough space to strcpy() string

Ok for gcc 14 too :) Christoph Müllner 於 2024年6月15日 週六 15:14 寫道： > > > On Sat, Jun 15, 2024, 08:25 Kito Cheng wrote: > >> Oooops, thanks for catching that! It's LGTM:) >> > > Also OK for the GCC 14 branch? > > >> Christoph Müllner 於 2024年6月15日 週

Re: [PATCH] riscv: Allocate enough space to strcpy() string

Oooops, thanks for catching that! It's LGTM:) Christoph Müllner 於 2024年6月15日 週六 04:58 寫道： > I triggered an ICE on Ubuntu 24.04 when compiling code that uses > function attributes. Looking into the sources shows that we have > a systematic issue in the attribute handling code: > * we determine th

Re: [PATCH v1] RISC-V: Bugfix vec_extract v mode iterator restriction mismatch

LGTM, thanks :) On Fri, Jun 14, 2024 at 3:02 PM wrote: > > From: Pan Li > > We have vec_extract pattern which takes ZVFHMIN as the mode > iterator of the V mode. Aka VF_ZVFHMIN iterator. But it will > expand to pred_extract_first pattern which takes the ZVFH as the mode > iterator of the V mod

Re: [PATCH 0/2] fix RISC-V zcmp popretz [PR113715]

Thanks for fixing this issue, and I am wondering doest it possible to fix that without introduce target hook? I ask that because...GCC 14 also has this bug, but I am not sure it's OK to introduce new target hook for release branch? or would you suggest we just revert patch to fix that on GCC 14? O

Re: pushed: wwwdocs: [PATCH] gcc-14/changes: Fix mislocated in RISC-V changes

Ohh, thanks for fixing that! On Wed, Jun 5, 2024 at 1:16 PM Xi Ruoyao wrote: > > --- > > Pushed as obvious. > > htdocs/gcc-14/changes.html | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html > index 6447898e..7a5eb4

Re: [PATCH v2 1/3] RISC-V: Add basic Zaamo and Zalrsc support

Hi Patrick: One dumb question around Zaamo and Zalrsc, could we still got correct atomic semantic with only Zaamo or only Zalrsc? I guess Zalrsc only probably ok, but how about Zaamo only? And another question around authorship: I notice you are listed as co-authored, and signed off by Edwin, but

Re: RISC-V: Patches need to be backport to GCC-14

Yeah, I think both should back port to GCC-14, but I would like to wait one more week like the convention within the GCC community :) On Mon, Jun 3, 2024 at 10:05 AM juzhe.zh...@rivai.ai wrote: > > Hi, I saw Robin commit these following patches: > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=978

Re: [PATCH 41/52] riscv: New hook implementation riscv_c_mode_for_floating_type

LGTM from RISC-V, thanks :) On Mon, Jun 3, 2024 at 11:08 AM Kewen Lin wrote: > > This is to remove macros {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE > defines in riscv port, and add new port specific hook > implementation riscv_c_mode_for_floating_type. > > gcc/ChangeLog: > > * config/riscv/riscv.c

Re: [PATCH v4] RISC-V: Introduce -mvector-strict-align.

I just created two PRs for adding those new options into riscv-toolchain-conventions, so that we could make sure it aligned with clang/LLVM community. https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/49 https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/50 On Wed,

Re: [PATCH v3] RISC-V: Introduce -mvector-strict-align.

> @@ -9536,6 +9549,12 @@ riscv_override_options_internal (struct gcc_options > *opts) >riscv_slow_unaligned_access_p = (cpu->tune_param->slow_unaligned_access >|| TARGET_STRICT_ALIGN); > > + /* By default, when -mno-vector-strict-align is not specified, do

Re: [PATCH V2] RISC-V: Fix missing boolean_expression in zmmul extension

Committed to trunk :) On Fri, May 24, 2024 at 7:58 PM Kito Cheng wrote: > > LGTM > > Liao Shihua 於 2024年5月24日 週五 13:05 寫道： >> >> Update v1->v2 >> Add testcase for this patch. >> >> Missing boolean_expression TARGET_ZMMUL in riscv_rtx_

Re: [PATCH V2] RISC-V: Fix missing boolean_expression in zmmul extension

LGTM Liao Shihua 於 2024年5月24日 週五 13:05 寫道： > Update v1->v2 > Add testcase for this patch. > > Missing boolean_expression TARGET_ZMMUL in riscv_rtx_costs() cause > different instructions when > multiplying an integer with a constant. ( > https://github.com/riscv-collab/riscv-gnu-toolchain/iss

Re: [PATCH] RISC-V: Fix missing boolean_expression in zmmul extension

Could you add a testcase to make sure zmmul will generate mul instruction? Liao Shihua 於 2024年5月23日 週四 18:48 寫道： > Missing boolean_expression TARGET_ZMMUL in riscv_rtx_costs() casuse > different instructions when multiplying an integer with a constant. > ( https://github.com/riscv-collab/riscv-g

Re: [PATCH] RISC-V: Modify _Bfloat16 to __bf16

LGTM, thanks for fixing this :) On Fri, May 17, 2024 at 4:05 PM Xiao Zeng wrote: > > According to the description in: > <https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/367>, > the type representation symbol of BF16 has been corrected. > > Kito Cheng pointed out

Re: [PATCH] RISC-V: testsuite: Drop march-string in cmpmemsi/cpymemsi tests

LGTM On Thu, May 16, 2024 at 5:09 PM Christoph Müllner wrote: > > The tests cmpmemsi-1.c and cpymemsi-1.c are execution ("dg-do run") > tests, which does not have any restrictions for the enabled extensions. > Further, no other listed options are required. > Let's drop the options, so that the te

Re: [NOT CODE REVIEW] [PATCH v3 1/1] [RISC-V] Add support for _Bfloat16

Hi Xiao Zeng: Just wondering why use _Bfloat16 rather than __bf16? you mention __bf16 in comment, but implementation use _Bfloat16? I would like to use __bf16 to make it consistent between LLVM and psABI if possible :)

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 @@ > /

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: 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 v1] RISC-V: Bugfix ICE for RVV intrinisc vfw on _Float16 scalar

LGTM as well :) On Sat, May 11, 2024 at 3:58 PM juzhe.zh...@rivai.ai wrote: > > LGTM from my side. Wait for kito chime in. > > > juzhe.zh...@rivai.ai > > > From: pan2.li > Date: 2024-05-11 15:54 > To: gcc-patches > CC: juzhe.zhong; kito.cheng; Pan Li > Subject: [P

[committed] RISC-V: Fix typos in code or comment [NFC]

Just found some typo when fixing bugs and then use aspell to find few more typos, this patch didn't do anything other than fix typo. gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc: Fix typos in comments. (get_all_predecessors): Ditto. (pre_vsetvl::m_unknow_info): Rename to.

Re: [PATCH][GCC 13] RISC-V: Fix vsetvli local eliminate [PR114747]

Committed to gcc 13 branch, thanks:) On Tue, May 7, 2024 at 9:20 AM juzhe.zh...@rivai.ai wrote: > > LGTM。 > > > juzhe.zh...@rivai.ai > > > From: Kito Cheng > Date: 2024-05-07 09:17 > To: gcc-patches; kito.cheng; palmer; jeffreyala

[PATCH][GCC 13] RISC-V: Fix vsetvli local eliminate [PR114747]

vsetvli local eliminate is only consider the current demand instead of full demand, and it will use that incomplete info to remove vsetvli. Give following example from PR114747: vsetvli a5,a1,e8,m4,ta,mu # 57, ratio=2, sew=8, lmul=4 vsetvli zero,a5,e16,m8,ta,ma# 58, ratio=2, sew=16, lmu

Re: [PATCH v2] RISC-V: Fix ICE for legitimize move on subreg const_poly_int [PR114885]

Hi Pan: LGTM. Hi Jakub: Is this OK for GCC 14 branch? it's fix ICE on valid code, thanks :) On Mon, Apr 29, 2024 at 3:40 PM wrote: > > From: Pan Li > > When we build with isl, there will be a ICE for graphite in both > the c/c++ and fortran. The legitimize move cannot take care of > below rt

Re: [PATCH v1] RISC-V: Fix ICE for legitimize move on subreg const_poly_move

> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc > index 0519e0679ed..bad23ea487f 100644 > --- a/gcc/config/riscv/riscv.cc > +++ b/gcc/config/riscv/riscv.cc > @@ -2786,6 +2786,44 @@ riscv_v_adjust_scalable_frame (rtx target, poly_int64 > offset, bool epilogue) >REG_NOTES (i

Re: [PATCH] RISC-V: Fix parsing of Zic* extensions

OK for trunk, and my understanding is that flag isn't really used in code gen yet, so it's not necessary to port to GCC 14 branch? On Mon, Apr 29, 2024 at 7:05 AM Christoph Müllner wrote: > > The extension parsing table entries for a range of Zic* extensions > does not match the mask definition i

Re: [PATCH] RISC-V: Add -X to link spec

LGTM :) Fangrui Song 於 2024年4月23日 週二 12:27 寫道： > From: Fangrui Song > > --discard-locals (-X) instructs the linker to remove local .L* symbols, > which occur a lot due to label differences for linker relaxation. The > arm port has a similar need and passes -X to ld. > > In contrast, the RISC-V

Re: [PATCH v1] RISC-V: Add early clobber to the dest of vwsll

LGTM, thanks :) On Thu, Apr 25, 2024 at 9:26 AM juzhe.zh...@rivai.ai wrote: > > lgtm > > > juzhe.zh...@rivai.ai > > > From: pan2.li > Date: 2024-04-25 09:25 > To: gcc-patches > CC: juzhe.zhong; kito.cheng; rdapp.gcc; Pan Li > Subject: [PATCH v1] RISC-V: Add early

Re: [PATCH v1] RISC-V: Add xfail test case for highpart register overlap of vwcvt

LGTM juzhe.zh...@rivai.ai 於 2024年4月25日 週四 09:26 寫道： > lgtm > > -- > juzhe.zh...@rivai.ai > > > *From:* pan2.li > *Date:* 2024-04-25 09:25 > *To:* gcc-patches > *CC:* juzhe.zhong ; kito.cheng > ; rdapp.gcc ; Pan Li > > *Subject:* [PATCH v1] RISC-V: Add xfail test ca

Re: [PATCH][GCC 13] RISC-V: Fix recursive vsetvli checking [PR114172]

thanks, committed :) On Wed, Apr 24, 2024 at 6:12 PM juzhe.zh...@rivai.ai wrote: > > lgtm. > > > juzhe.zh...@rivai.ai > > > From: Kito Cheng > Date: 2024-04-24 18:09 > To: gcc-patches; kito.cheng; rdapp; juzhe.zhong > CC: Kit

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

LGTM, thanks Pan, although the revert patch series look a little bit scary, but I believe it's the safest way for now since we don't really fully understand how register filters work, and it's not really good timing to figure out all the detail around that. On Wed, Apr 24, 2024 at 9:02 PM Li, Pan2

[PATCH][GCC 13] RISC-V: Fix recursive vsetvli checking [PR114172]

extract_single_source will recursive checking the sources to make sure if it's single source, however it may cause infinite recursive when the source is come from itself, so it should just skip first source to prevent that. NOTE: This logic has existing on trunk/GCC 14, but it included in a big vs

Re: [PATCH] [RISC-V] optimize Zicond conditional select cases.

It's simple enough, so LGTM for trunk :) Fei Gao 於 2024年4月15日 週一 14:38 寫道： > When one of the two input operands is 0, ADD and IOR are functionally > equivalent. > ADD is slightly preferred over IOR because ADD has a higher likelihood > of being implemented as a compressed instruction when compar

Re: [PATCH v1] RISC-V: Bugfix ICE non-vector in TARGET_FUNCTION_VALUE_REGNO_P

Does FP reg also need gurared with TARGET_HARD_FLOAT? could you try to compile that case without F? On Fri, Apr 12, 2024 at 2:19 PM Li, Pan2 wrote: > > Committed, thanks Juzhe. > > > > Pan > > > > From: juzhe.zh...@rivai.ai > Sent: Friday, April 12, 2024 2:11 PM > To: Li, Pan2 ; gcc-patches > C

Re: [PATCH] wwwdocs: gcc-14: Add RISC-V changes

Committed with fixes, thanks :) On Thu, Apr 11, 2024 at 12:18 AM Palmer Dabbelt wrote: > On Wed, 10 Apr 2024 00:58:00 PDT (-0700), kito.ch...@sifive.com wrote: > > --- > > htdocs/gcc-14/changes.html | 155 - > > 1 file changed, 154 insertions(+), 1 deletion(-

Re: [PATCH v1] RISC-V: Bugfix ICE for the vector return arg in mode switch

I was thinking we may guarded with TARGET_VECTOR and TARGET_HARD_FLOAT or checking with ABI in riscv_function_value_regno_p, however I think it's fine with current implementation (no checking) after checking all use site of `targetm.calls.function_value_regno_p`, so LGTM :) Thanks Pan for fixing t

[PATCH] wwwdocs: gcc-14: Add RISC-V changes

--- htdocs/gcc-14/changes.html | 155 - 1 file changed, 154 insertions(+), 1 deletion(-) diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 2d8968cf..6cbb2e8f 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14/changes.html @@ -7

  1   2   3   4   5   6   7   8   9   10   >