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

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 >

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

[Bug target/116111] RISC-V: 'd' extension allowed with -mabi=ilp32e

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116111 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org --- Comment #2

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.

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

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

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

[Bug target/115995] RISC-V: Can't generate portable RVV code for rv64gcv_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115995 --- Comment #3 from Kito Cheng --- We have an internal qemu patch for adding an option to trigger this damm behavior by default, and plan to upstream soon...let me ask our Qemu folk if I can get the patch out first.

[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

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

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

[gcc r14-10467] RISC-V: Bugfix vec_extract v mode iterator restriction mismatch

https://gcc.gnu.org/g:4db38759dcae7426ea5ce4432afe97bdd2d87ac8 commit r14-10467-g4db38759dcae7426ea5ce4432afe97bdd2d87ac8 Author: Pan Li Date: Fri Jun 14 14:54:22 2024 +0800 RISC-V: Bugfix vec_extract v mode iterator restriction mismatch We have vec_extract pattern which takes

[gcc r14-10473] RISC-V: Split vwadd.wx and vwsub.wx and add helpers.

https://gcc.gnu.org/g:0abce4116a5ac58fdf1b8839b7db8ce04dd8a55a commit r14-10473-g0abce4116a5ac58fdf1b8839b7db8ce04dd8a55a Author: Robin Dapp Date: Thu May 16 12:43:43 2024 +0200 RISC-V: Split vwadd.wx and vwsub.wx and add helpers. vwadd.wx and vwsub.wx have the same problem

[gcc r14-10472] RISC-V: Do not allow v0 as dest when merging [PR115068].

https://gcc.gnu.org/g:937713a5235bf9a9b8960635315882e8cee2706e commit r14-10472-g937713a5235bf9a9b8960635315882e8cee2706e Author: Robin Dapp Date: Mon May 13 13:49:57 2024 +0200 RISC-V: Do not allow v0 as dest when merging [PR115068]. This patch splits the vfw...wf pattern so we

[gcc r14-10470] RISC-V: Fix parsing of Zic* extensions

https://gcc.gnu.org/g:92003fad999edfeb98edfd6e3e5bbe1254389127 commit r14-10470-g92003fad999edfeb98edfd6e3e5bbe1254389127 Author: Christoph Müllner Date: Mon Apr 29 00:46:06 2024 +0200 RISC-V: Fix parsing of Zic* extensions The extension parsing table entries for a range of Zic*

[gcc r14-10468] RISC-V: Fix missing boolean_expression in zmmul extension

https://gcc.gnu.org/g:c38dbfc1ce7e827c4386c4b2595a5327a92b89d2 commit r14-10468-gc38dbfc1ce7e827c4386c4b2595a5327a92b89d2 Author: Liao Shihua Date: Fri May 24 13:03:57 2024 +0800 RISC-V: Fix missing boolean_expression in zmmul extension Update v1->v2 Add testcase for this

[gcc r14-10466] RISC-V: Bugfix vec_extract vls mode iterator restriction mismatch

https://gcc.gnu.org/g:87346ed74cc069d133918e28761fa8ef3c8ec874 commit r14-10466-g87346ed74cc069d133918e28761fa8ef3c8ec874 Author: Pan Li Date: Thu Jun 13 15:26:59 2024 +0800 RISC-V: Bugfix vec_extract vls mode iterator restriction mismatch We have vec_extract pattern which takes

[gcc r14-10471] RISC-V: Add -X to link spec

https://gcc.gnu.org/g:3a7e796b48b9d8e37ec142abd9c20b1847535f7e commit r14-10471-g3a7e796b48b9d8e37ec142abd9c20b1847535f7e Author: Fangrui Song Date: Fri Apr 26 18:14:33 2024 -0700 RISC-V: Add -X to link spec --discard-locals (-X) instructs the linker to remove local .L* symbols,

[gcc r14-10469] RISC-V: Bugfix ICE for RVV intrinisc vfw on _Float16 scalar

https://gcc.gnu.org/g:68ef0c321a7df5899e1fbc3e20e75cce4233d6f7 commit r14-10469-g68ef0c321a7df5899e1fbc3e20e75cce4233d6f7 Author: Pan Li Date: Sat May 11 15:25:28 2024 +0800 RISC-V: Bugfix ICE for RVV intrinisc vfw on _Float16 scalar For the vfw vx format RVV intrinsic, the

[gcc r14-10465] [PATCH] RISC-V: Fix unrecognizable pattern in riscv_expand_conditional_move()

https://gcc.gnu.org/g:c32995c4453fa4e04d27fda1597e31e6664f5eb4 commit r14-10465-gc32995c4453fa4e04d27fda1597e31e6664f5eb4 Author: Artemiy Volkov Date: Sun Jun 23 14:54:00 2024 -0600 [PATCH] RISC-V: Fix unrecognizable pattern in riscv_expand_conditional_move() Presently, the code

[gcc r14-10464] RISC-V: Use tu policy for first-element vec_set [PR115725].

https://gcc.gnu.org/g:2d7dda84730e0e364b3b1776d387c9ceb85385ea commit r14-10464-g2d7dda84730e0e364b3b1776d387c9ceb85385ea Author: Robin Dapp Date: Mon Jul 1 13:37:17 2024 +0200 RISC-V: Use tu policy for first-element vec_set [PR115725]. This patch changes the tail policy for

[gcc r14-10463] [RISC-V] add implied extension repeatly until stable

https://gcc.gnu.org/g:b218c425328cd54994f717aaaca757b852df6aa9 commit r14-10463-gb218c425328cd54994f717aaaca757b852df6aa9 Author: Fei Gao Date: Fri Jul 5 09:56:30 2024 + [RISC-V] add implied extension repeatly until stable Call handle_implied_ext repeatly until there's no

[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

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

[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

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

[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

Re: Re: [PATCH v2] RISC-V: Disable misaligned vector access in hook riscv_slow_unaligned_access[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_slow_unaligned_acc

[gcc r15-1992] RISC-V: Add SiFive extensions, xsfvcp and xsfcease

https://gcc.gnu.org/g:3ea47ea1fcab95fd1b80acc724fdbb27fc436985 commit r15-1992-g3ea47ea1fcab95fd1b80acc724fdbb27fc436985 Author: Kito Cheng Date: Tue Jul 9 15:50:57 2024 +0800 RISC-V: Add SiFive extensions, xsfvcp and xsfcease We have already upstreamed these extensions

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

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

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

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 '+'

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

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

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

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 &

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

[Bug target/115795] RISC-V: vsetvl step causes wrong codegen after fusing info

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115795 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org --- Comment #3

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

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

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 --- Comment #13 from Kito Cheng --- FYI: PR for riscv-gnu-toolchain: https://github.com/riscv-collab/riscv-gnu-toolchain/pull/1501

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 --- Comment #12 from Kito Cheng --- Qemu has provide two option to fill up all-one to agnostic policy: rvv_ta_all_1s and rvv_ma_all_1s*, I guess we could enable that by default in riscv-gnu-toolchain to discover more potential bugs. * qemu

[Bug target/115725] RISC-V: Use wrong AVL for rv64gcv_zfh_zvl512b

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115725 --- Comment #2 from Kito Cheng --- TU may not help for this case since we can't guarantee it's use v1 outside, I mean the argument is passed via a1 (pointer) rather than passed via v1.

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,

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

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

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

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 Cheng wrote: >>

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

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日 週六 04:

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

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

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?

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

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,

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

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

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

[gcc r15-845] RISC-V: Fix missing boolean_expression in zmmul extension

https://gcc.gnu.org/g:06bb125521dec5648b725ddee4345b00decfdc77 commit r15-845-g06bb125521dec5648b725ddee4345b00decfdc77 Author: Liao Shihua Date: Fri May 24 13:03:57 2024 +0800 RISC-V: Fix missing boolean_expression in zmmul extension Update v1->v2 Add testcase for this

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. ( >

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. > (

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

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

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

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

[Bug tree-optimization/115073] New: RISC-V: Gimple fold not honor C[LT]Z_DEFINED_VALUE_AT_ZERO

Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: kito at gcc dot gnu.org Target Milestone: --- Target: riscv64-unknown-linux-gnu # What's up? A loop induction variable initialized from __builtin_ctz (x

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.zh

[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

[gcc r15-356] RISC-V: Fix typos in code or comment [NFC]

https://gcc.gnu.org/g:d83070aebdb810e38f12d008e7a10acf1063f456 commit r15-356-gd83070aebdb810e38f12d008e7a10acf1063f456 Author: Kito Cheng Date: Tue May 7 10:18:58 2024 +0800 RISC-V: Fix typos in code or comment [NFC] Just found some typo when fixing bugs and then use aspell

[Bug target/114988] RISC-V: ICE in intrinsic __riscv_vfwsub_wf_f32mf2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114988 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org --- Comment #3

[Bug target/114747] [13 only] [RISC-V RVV] Wrong SEW set for mixed-size intrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114747 Kito Cheng changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution

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

[gcc r13-8701] RISC-V: Fix vsetvli local eliminate [PR114747]

https://gcc.gnu.org/g:c4c0b0be87b4e08dab0e5e62c6f38a610a7423e7 commit r13-8701-gc4c0b0be87b4e08dab0e5e62c6f38a610a7423e7 Author: Kito Cheng Date: Mon May 6 23:45:22 2024 +0800 RISC-V: Fix vsetvli local eliminate [PR114747] vsetvli local eliminate is only consider the current

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

[Bug target/113095] [13 Regression] RISC-V: movcc no longer used for coremark crc functions with -mtune=sifive-7-series

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113095 Kito Cheng changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[gcc r13-8663] [PATCH v3] RISC-V: Add split pattern to generate SFB instructions. [PR113095]

https://gcc.gnu.org/g:6335baaf31c0f1f0952d1a3f507b0e5655b1136f commit r13-8663-g6335baaf31c0f1f0952d1a3f507b0e5655b1136f Author: Monk Chiang Date: Wed Jan 24 10:19:28 2024 -0700 [PATCH v3] RISC-V: Add split pattern to generate SFB instructions. [PR113095] Since the match.pd

[Bug target/111234] [13] RISC-V: ICE in vsetvl pass

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111234 Kito Cheng changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution

[gcc r13-8659] RISC-V: Fix vsetvl pass ICE

https://gcc.gnu.org/g:129b64b0c2766d66d97be68a36f7d72685a9d29e commit r13-8659-g129b64b0c2766d66d97be68a36f7d72685a9d29e Author: Lehua Ding Date: Wed Aug 30 17:48:00 2023 +0800 RISC-V: Fix vsetvl pass ICE This patch fix pr111234 (a vsetvl pass ICE) when fuse a mask any vlmax

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

[Bug c/114885] RISC-V: ICE of unrecog insn when graphite for both the c/c++ and fortran

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114885 Kito Cheng changed: What|Removed |Added Status|UNCONFIRMED |NEW CC

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

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

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

  1   2   3   4   5   6   7   8   9   10   >