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

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

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

[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

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

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

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

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

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

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

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

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

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

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

Fwd: [PATCH] Prevent crash when expand movstr fail when movstr pattern is defined

nd_insn instead of expand_insn, check it done or not and just return NULL_RTX for generate a libcall if fail to expand movstr. 2014-01-11 Kito Cheng * gcc/builtins.c (expand_movstr): Check movstr expand done or fail. diff --git a/gcc/builtins.c b/gcc/builtins.c index e3c32a9..fca51a1 1

[PATCH] PR target/96759 - Handle global variable assignment from misaligned structure/PARALLEL return values.

In g:70cdb21e579191fe9f0f1d45e328908e59c0179e, DECL/global variable has handled misaligned stores, but it didn't handle PARALLEL values, and I refer the other part of this function, I found the PARALLEL need handled by emit_group_* functions, so I add a check, and using emit_group_store if storing

Re: [PATCH] PR target/96759 - Handle global variable assignment from misaligned structure/PARALLEL return values.

Hi Richard: Thanks for your review :) > riscv doesn't seem to have movmisalign and I don't see why movmisalign > should not support a TImode parallel RHS so at least you should > put this check after the icode != CODE_FOR_nothing check? RISC-V has an option `-mno-strict-align` to enable mis-alig

[PATCH] RISC-V: Using fmv.x.w/fmv.w.x rather than fmv.x.s/fmv.s.x

- fmv.x.s/fmv.s.x renamed to fmv.x.w/fmv.w.x in the latest RISC-V ISA manual. - Tested rv32gc/rv64gc on bare-metal with qemu. ChangeLog gcc/ Kito Cheng * config/riscv/riscv.c (riscv_output_move) Using fmv.x.w/fmv.w.x rather than fmv.x.s/fmv.s.x. --- gcc/config/riscv

Re: [PATCH] RISC-V: Using fmv.x.w/fmv.w.x rather than fmv.x.s/fmv.s.x

Committed. Hi Jim: Thanks for your review and reply, I'll commit directly for such simple patch in future :) On Wed, Feb 19, 2020 at 7:33 AM Jim Wilson wrote: > > On Mon, Feb 17, 2020 at 9:57 PM Kito Cheng wrote: > > * config/riscv/riscv.c (riscv_output_move) Usin

[PATCH] RISC-V: Adjust floating point code gen for LTGT compare

, like GE/GT/LE/LT. - So we expand (LTGT a b) to ((LT a b) | (GT a b)) for fit the document. - Tested rv64gc/rv32gc bare-metal/linux on qemu and rv64gc on HiFive unleashed board with linux. ChangeLog gcc/ Kito Cheng * config/riscv/riscv.c (riscv_emit_float_compare): Change the code

[PATCH v2] RISC-V: Adjust floating point code gen for LTGT compare

, like GE/GT/LE/LT. - So we expand (LTGT a b) to ((LT a b) | (GT a b)) for fit the document. - Tested rv64gc/rv32gc bare-metal/linux on qemu and rv64gc on HiFive unleashed board with linux. ChangeLog gcc/ Kito Cheng * config/riscv/riscv.c (riscv_emit_float_compare): Change the code

Re: [PATCH v2] RISC-V: Adjust floating point code gen for LTGT compare

Thanks, committed :) On Sat, Feb 22, 2020 at 6:10 AM Jim Wilson wrote: > > On Fri, Feb 21, 2020 at 1:04 AM Kito Cheng wrote: > > * config/riscv/riscv.c (riscv_emit_float_compare): Change the code > > gen > > for LTGT. > > (riscv_rtx_cost

[PATCH] re PR tree-optimization/90883 (Generated code is worse if returned struct is unnamed)

After add --param max-inline-insns-size=1 all target will remove the redundant store at dse1, except some targets like AArch64 and MIPS will expand the struct initialization into loop due to CLEAR_RATIO. Tested on cross compiler of riscv32, riscv64, x86, x86_64, mips, mips64, aarch64, nds32 and ar

[PATCH] PR target/93995 ICE in patch_jump_insn, at cfgrtl.c:1290 on riscv64-linux-gnu

Last code gen change of LTGT didn't consider the situation of cbranch with LTGT, branch only support few compare codes. gcc/ChangeLog * config/riscv/riscv.c (riscv_emit_float_compare): Using NE to compare the result of IOR. gcc/testsuite/ChangeLog * gcc.dg/pr93995.c: New

Re: [PATCH] PR target/93995 ICE in patch_jump_insn, at cfgrtl.c:1290 on riscv64-linux-gnu

Committed, thanks :) On Wed, Mar 4, 2020 at 6:23 AM Jim Wilson wrote: > > On Tue, Mar 3, 2020 at 12:03 AM Kito Cheng wrote: > > gcc/ChangeLog > > * config/riscv/riscv.c (riscv_emit_float_compare): Using NE to > > compare > > the result of IOR. &

Re: [PATCH] re PR tree-optimization/90883 (Generated code is worse if returned struct is unnamed)

Committed, thanks :) On Thu, Mar 5, 2020 at 11:42 PM Jeff Law wrote: > On Tue, 2020-03-03 at 15:34 +0800, Kito Cheng wrote: > > After add --param max-inline-insns-size=1 all target will remove the > > redundant store at dse1, except some targets like AArch64 and MIPS will > &

[committed] RISC-V: Fix testsuite regression due to recent IRA changes.

/gcc/testsuite/ChangeLog @@ -1,3 +1,7 @@ +2020-03-06 Kito Cheng + + * gcc.target/riscv/pr93304.c: Update expected output and comment. + 2020-03-06 Delia Burduv * gcc.target/aarch64/advsimd-intrinsics/bfcvt-compile.c: New test. diff --git a/gcc/testsuite/gcc.target/riscv/pr93304

[committed] RISC-V: Fix testsuite regression due to recent IRA changes.

After IRA changes, atomic version will use one more register, but non-atomic still use 2 registers, however this testcase isn't testing for atomic feature, so I decide change the testcase to always use COUNT++ to test. ChangeLog gcc/testsuite/ Kito Cheng * gcc.target/riscv/inte

[PATCH] RISC-V: Disable remove unneeded save-restore call optimization if there are any arguments on stack.

- This optimization will adjust stack, but it not check/update other stack pointer use-site, the example is when the arguments put on stack, the offset become wrong after optimization. - However adjust stack frame usage after register allocation could be error prone, so we decide to tur

[PATCH] RISC-V: Implment __builtin_thread_pointer

RISC-V has a dedicate register for thread pointer which is specified in psABI doc, so we could support __builtin_thread_pointer in straightforward way. Note: clang/llvm was supported __builtin_thread_pointer for RISC-V port recently. - https://reviews.llvm.org/rGaabc24acf0d5f8677bd22fe9c108581e07c

[committed] testsuite: Add signal checking for signal related testcase in analyzer.

- Verifed on RISC-V and x86. gcc/testsuite/ChangeLog: * gcc.dg/analyzer/signal-1.c: Add dg-require-effective-target signal. * gcc.dg/analyzer/signal-2.c: Ditto. * gcc.dg/analyzer/signal-3.c: Ditto. * gcc.dg/analyzer/signal-4a.c: Ditto. * gcc.dg/ana

[PATCH] testsuite: Improve signal supporting detection

gcc/testsuite/ChangeLog: * lib/target-supports.exp (check_effective_target_signal): Check signal supporting by checking signal.h, signal and raise is available. --- gcc/testsuite/lib/target-supports.exp | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/

[PATCH] PR target/96260 - KASAN should work even back-end not porting anything.

- Most KASAN function don't need any porting anything in back-end except asan stack protection. - However kernel will given shadow offset when enable asan stack protection, so eveything in KASAN can work if shadow offset is given. - Verified with x86 and risc-v. - Verified with RISC-V

[PATCH] Fix alignment for local variable [PR90811]

- The alignment for local variable was adjust during estimate_stack_frame_size, however it seems wrong spot to adjust that. - So we must adjust at some point, and here is already a pass to adjust alignment, which is ipa-increase-alignment, used for tree vectorization. - We move out the p

Re: [PATCH] Fix alignment for local variable [PR90811]

nt belong tree-vectorizer.c, which is weird place to adjust local variable alignment, so I moved out into a new file, so do you think just create a stand alone simple pass for doing that is better than this way? Thanks :) On Fri, Mar 27, 2020 at 8:33 PM Richard Biener wrote: > > On Fri, Mar 27,

[PATCH 1/2] Move out increase_alignment into ipa-increase-alignment.cc

- This patch is prepare for add more logic into increase_alignment pass, which is not related to vectorization. gcc/ChangeLog * Makefile.in (OBJS): Add ipa-increase-alignment.o. * tree-vectorizer.c (get_vec_alignment_for_type): Moved to ipa-increase-alignment.cc.

[PATCH 2/2] Fix alignment for local variable [PR90811]

- The alignment for local variable was adjust during estimate_stack_frame_size, however it seems wrong spot to adjust that, expand phase will adjust that but it little too late to some gimple optimization, which rely on certain target hooks need to check alignment, forwprop is an example

Re: [PATCH 2/2] Fix alignment for local variable [PR90811]

IGN? On Mon, Mar 30, 2020 at 5:15 PM Jakub Jelinek wrote: > > On Mon, Mar 30, 2020 at 11:09:40AM +0200, Richard Biener wrote: > > On Fri, Mar 27, 2020 at 7:27 PM Jakub Jelinek wrote: > > > > > > On Sat, Mar 28, 2020 at 02:06:56AM +0800, Kito Cheng wrote: > >

Re: [PATCH 2/2] Fix alignment for local variable [PR90811]

(pass_remove_cgraph_callee_edges); Thanks :) On Sat, Mar 28, 2020 at 2:27 AM Jakub Jelinek wrote: > > On Sat, Mar 28, 2020 at 02:06:56AM +0800, Kito Cheng wrote: > > PR target/90811 > > * ipa-increase-alignment.cc (increase_alignme

Re: [PATCH 2/2] Fix alignment for local variable [PR90811]

Hi Andrew: > > + FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (node) > > +{ > > + function *fun = node->get_fun (); > > + FOR_EACH_LOCAL_DECL (fun, i, var) > > + { > > + align = LOCAL_DECL_ALIGNMENT (var); > > + > > + SET_DECL_ALIGN (var, align); > > > I think this is wr

[PATCH] Respect user align for local variable

gcc/ChangeLog * cfgexpand.c (align_local_variable): Check DECL_USER_ALIGN. --- gcc/cfgexpand.c | 20 +--- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c index a7ec77d5c85..19a020b4b97 100644 --- a/gcc/cfgexpand.c +++ b/gcc/

Re: [PATCH] Respect user align for local variable

20 at 06:31:27PM +0800, Kito Cheng wrote: > > gcc/ChangeLog > > > > * cfgexpand.c (align_local_variable): Check DECL_USER_ALIGN. > > Why? LOCAL_DECL_ALIGNMENT surely shouldn't decrease alignment of decls > with DECL_USER_ALIGN vars (but do you have evidence

[PATCH v3] Fix alignment for local variable [PR90811]

- The alignment for local variable was adjust during estimate_stack_frame_size, however it seems wrong spot to adjust that, expand phase will adjust that but it little too late to some gimple optimization, which rely on certain target hooks need to check alignment, forwprop is an example

[PATCH 1/2] RISC-V: Update march parser

- The arch string rule has changed in latest spec, it introduced new multi-letter extension prefix with 'h' and 'z', and drop `sx`. also adjust parsing order for 's' and 'x'. gcc/ChangeLog * riscv-common.c (parse_sv_or_non_std_ext): Rename to parse_multiletter_ext.

[PATCH 2/2] RISC-V: Handle implied extension for -march parser.

- Implied rule are introduced into latest RISC-V isa spec. - Only implemented D implied F-extension. Zicsr and Zifence are not implement yet, so the rule not included in this patch. gcc/ChangeLog * common/config/riscv/riscv-common.c (riscv_implied_info_t): New. (riscv_imp

Re: [PATCH 2/2] RISC-V: Handle implied extension for -march parser.

Hi Jim: > When I try this patch, I see an error: > > rohan:2132$ ./xgcc -B./ -O -march=rv64imafdc -mabi=lp64d tmp.c > /tmp/ccULN36f.s: Assembler messages: > /tmp/ccULN36f.s:3: Fatal error: > -march=rv64i2p0_m2p0_a2p0_f2p0_f2p0_d2p0_c2p0: ISA string is not in > canonical order. `f' > rohan:2133$ >

Re: [PATCH v3] Fix alignment for local variable [PR90811]

ping On Tue, Mar 31, 2020 at 4:33 PM Kito Cheng wrote: > > - The alignment for local variable was adjust during > estimate_stack_frame_size, >however it seems wrong spot to adjust that, expand phase will adjust that >but it little too late to some gimple optimization

Re: [PATCH v3] Fix alignment for local variable [PR90811]

Hi Richard: > Please skip vars with DECL_USER_ALIGN. I was consider to skip DECL_USER_ALIGN, but Jakub think it shouldn't skip in other patch review[1] (related to this patch), because it's minimum alignment not restricted alignment[2] [1] https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542

[PATCH v2 2/2] RISC-V: Handle implied extension for -march parser.

- Implied rule are introduced into latest RISC-V ISA spec. - Only implemented D implied F-extension. Zicsr and Zifence are not implement yet, so the rule not included in this patch. - Pass preprocessed arch string to arch. - Verified with binutils 2.30 and 2.34. gcc/ChangeLog

[PATCH v2 1/2] RISC-V: Update march parser

- The arch string rule has changed in latest spec, it introduced new multi-letter extension prefix with 'h' and 'z', and drop `sx`. also adjust parsing order for 's' and 'x'. gcc/ChangeLog * riscv-common.c (parse_sv_or_non_std_ext): Rename to parse_multiletter_ext.

Re: [PATCH v2 2/2] RISC-V: Handle implied extension for -march parser.

On Sat, Apr 11, 2020 at 1:48 AM Jim Wilson wrote: > > On Fri, Apr 10, 2020 at 2:20 AM Kito Cheng wrote: > > - Implied rule are introduced into latest RISC-V ISA spec. > > - Only implemented D implied F-extension. Zicsr and Zifence are not > > implement yet, so

[PATCH v4] Fix alignment for local variable [PR90811]

- The alignment for local variable was adjust during estimate_stack_frame_size, however it seems wrong spot to adjust that, expand phase will adjust that but it little too late to some gimple optimization, which rely on certain target hooks need to check alignment, forwprop is an example

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