Re: [PATCH] rs6000: Enable overlapped by-pieces operations

Hi, on 2024/5/8 14:47, HAO CHEN GUI wrote: > Hi, > This patch enables overlapped by-piece operations. On rs6000, default > move/set/clear ratio is 2. So the overlap is only enabled with compare > by-pieces. Thanks for enabling this, did you evaluate if it can help some benchmark? > >

Re: [PATCH 2/4] fortran: Teach get_real_kind_from_node for Power 128 fp modes [PR112993]g

Hi, on 2024/5/9 06:01, Steve Kargl wrote: > On Wed, May 08, 2024 at 01:27:53PM +0800, Kewen.Lin wrote: >> >> Previously effective target fortran_real_c_float128 never >> passes on Power regardless of the default 128 long double >> is ibmlongdouble or ieeelongdouble. It's due to that TF >> mode

Re: [PATCH] [ranger] Force buffer alignment in Value_Range [PR114912]

Pushed to trunk to unblock sparc. On Fri, May 3, 2024 at 4:24 PM Aldy Hernandez wrote: > > Ahh, that is indeed cleaner, and there's no longer a need to assert > the sizeof of individual ranges. > > It looks like a default constructor is needed for the buffer now, but > only for the default

[COMMITTED] [prange] Reword dispatch error message [PR114985]

After reading the ICE for the PR, it's obvious the error message is rather cryptic. This makes it less so. gcc/ChangeLog: * range-op.cc (range_op_handler::discriminator_fail): Reword error message. --- gcc/range-op.cc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

Re: [PATCH] i386: Fix some intrinsics without alignment requirements.

On Wed, May 8, 2024 at 10:13 AM Hu, Lin1 wrote: > > Hi all, > > This patch aims to fix some intrinsics without alignment requirement, but > raised runtime error's problem. > > Bootstrapped and tested on x86_64-linux-gnu, OK for trunk? Ok. > > BRs, > Lin > > gcc/ChangeLog: > > PR

RE: [pushed][PR114810][LRA]: Recognize alternatives with lack of available registers for insn and demote them.

CC more RISC-V port people for awareness. Pan From: Li, Pan2 Sent: Thursday, May 9, 2024 11:25 AM To: Vladimir Makarov ; gcc-patches@gcc.gnu.org Subject: RE: [pushed][PR114810][LRA]: Recognize alternatives with lack of available registers for insn and demote them. Hi Vladimir, Looks this

RE: [pushed][PR114810][LRA]: Recognize alternatives with lack of available registers for insn and demote them.

Hi Vladimir, Looks this patch results in some ICE in the rvv.exp of RISC-V backend, feel free to ping me if more information is needed for reproducing. = Summary of gcc testsuite = | # of unexpected case / # of unique unexpected case

[PATCH v1] RISC-V: Make full-vec-move1.c test robust for optimization

From: Pan Li During investigate the support of early break autovec, we notice the test full-vec-move1.c will be optimized to 'return 0;' in main function body. Because somehow the value of V type is compiler time constant, and then the second loop will be considered as assert (true). Thus,

Re: Re: [PATCH 2/4] df: Add DF_LIVE_SUBREG problem

Thanks Dim. We noticed there is regression in aarch64 CI. We will fix it with following your comments and regression in aarch64 CI. juzhe.zh...@rivai.ai From: Dimitar Dimitrov Date: 2024-05-08 23:57 To: 陈硕 CC: 丁乐华; gcc-patches; 钟居哲; 夏晋; vmakarov; richard.sandiford Subject: Re: [PATCH 2/4]

Re: [PATCH 1/2] RISC-V: Add tests for cpymemsi expansion

On 5/7/24 11:52 PM, Christoph Müllner wrote: cpymemsi expansion was available for RISC-V since the initial port. However, there are not tests to detect regression. This patch adds such tests. Three of the tests target the expansion requirements (known length and alignment). One test reuses

Re: [PATCH gcc-13-backport] RISCV: Add -m(no)-omit-leaf-frame-pointer support.

On 5/8/24 11:32 AM, Palmer Dabbelt wrote: From: Yanzhang Wang gcc/ChangeLog: * config/riscv/riscv.cc (riscv_save_reg_p): Save ra for leaf when enabling -mno-omit-leaf-frame-pointer (riscv_option_override): Override omit-frame-pointer.

Re: Re: [PATCH 4/4] lra: Apply DF_LIVE_SUBREG data

Thanks Vlad. I noticed there is devel/subreg-coalesce branch. We are working on supporting subreg coalesce in IRA/LRA base on the latest version of subreg DF patch. And we will send the followup patches. Thanks. juzhe.zh...@rivai.ai From: Vladimir Makarov Date: 2024-05-09 00:29 To: Lehua

Re: [PATCH 2/4] fortran: Teach get_real_kind_from_node for Power 128 fp modes [PR112993]g

On Wed, May 08, 2024 at 01:27:53PM +0800, Kewen.Lin wrote: > > Previously effective target fortran_real_c_float128 never > passes on Power regardless of the default 128 long double > is ibmlongdouble or ieeelongdouble. It's due to that TF > mode is always used for kind 16 real, which has

Re: [Patch, fortran] PR84006 [11/12/13/14/15 Regression] ICE in storage_size() with CLASS entity

Hi Paul, this looks mostly good, but the new testcase transfer_class_4.f90 does exhibit a problem with your patch. Run it with valgrind, or with -fcheck=bounds, or with -fsanitize=address, or add the following around the final transfer: print *, storage_size (star_a), storage_size (chr_a),

Re: [PATCH] [RFC] Add function filtering to gcov

> > > > For JSON output I suppose there's a way to "grep" without the line oriented > > issue? I suppose we could make the JSON more hierarchical by adding > > an outer function object? > > Absolutely, yes, this is much less useful for JSON. The filtering works, > which may be occasionally

[committed] [RISC-V] Provide splitting guidance to combine to faciliate shNadd.uw generation

This fixes a minor code quality issue I found while comparing GCC and LLVM. Essentially we want to do a bit of re-association to generate shNadd.uw instructions. Combine does the right thing and finds all the necessary instructions, reassociates the operands, combines constants, etc. Where

Re: [PATCH v1 1/1] RISC-V: Nan-box the result of movbf on soft-bf16

On 5/7/24 6:38 PM, Xiao Zeng wrote: 1 This patch implements the Nan-box of bf16. 2 Please refer to the Nan-box implementation of hf16 in: 3 The discussion about Nan-box can be found on the website:

Re: [PATCH] [RFC] Add function filtering to gcov

On 5/8/24 15:29, Richard Biener wrote: On Fri, Mar 29, 2024 at 8:02 PM Jørgen Kvalsvik wrote: This is a prototype for --include/--exclude flags, and I would like a review of both the approach and architecture, and the implementation, plus feedback on the feature itself. I did not update the

Re: Ping [PATCH/RFC] target, hooks: Allow a target to trap on unreachable [PR109267].

On Wed, May 8, 2024 at 12:37 PM Iain Sandoe wrote: > > Hi Folks, > > I’d like to land a viable solution to this issue if possible, (it is a show- > stopper for the aarch64-darwin development branch). > > > On 9 Apr 2024, at 14:55, Iain Sandoe wrote: > > > > So far, tested lightly on

Ping [PATCH/RFC] target, hooks: Allow a target to trap on unreachable [PR109267].

Hi Folks, I’d like to land a viable solution to this issue if possible, (it is a show- stopper for the aarch64-darwin development branch). > On 9 Apr 2024, at 14:55, Iain Sandoe wrote: > > So far, tested lightly on aarch64-darwin; if this is acceptable then > it will be possible to back out of

Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.

> On May 7, 2024, at 17:52, Kees Cook wrote: > > On Tue, May 07, 2024 at 06:34:19PM +, Qing Zhao wrote: >> On May 7, 2024, at 13:57, Sebastian Huber >> wrote: >>> On 07.05.24 16:26, Qing Zhao wrote: Hi, Sebastian, Thanks for your explanation. Our goal is to deprecate the

Re: [PATCH] c++: nested aggregate/alias CTAD fixes

On Wed, 8 May 2024, Patrick Palka wrote: > Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look > OK for trunk and perhaps 14? > > -- >8 -- > > During maybe_aggr_guide with a nested class template and paren init, > like with list init we need to consider the generic template type

[PATCH] c++: nested aggregate/alias CTAD fixes

Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look OK for trunk and perhaps 14? -- >8 -- During maybe_aggr_guide with a nested class template and paren init, like with list init we need to consider the generic template type rather than the partially instantiated type since only

[PATCH gcc-13-backport] RISCV: Add -m(no)-omit-leaf-frame-pointer support.

From: Yanzhang Wang gcc/ChangeLog: * config/riscv/riscv.cc (riscv_save_reg_p): Save ra for leaf when enabling -mno-omit-leaf-frame-pointer (riscv_option_override): Override omit-frame-pointer. (riscv_frame_pointer_required): Save s0 for non-leaf function

Re: [COMMITTED] warn-access: Fix handling of unnamed types [PR109804]

On Thu, Feb 22, 2024 at 9:28 AM Andrew Pinski wrote: > > This looks like an oversight of handling DEMANGLE_COMPONENT_UNNAMED_TYPE. > DEMANGLE_COMPONENT_UNNAMED_TYPE only has the u.s_number.number set while > the code expected newc.u.s_binary.left would be valid. > So this treats

[patch,avr,applied] PR114981: Implement __powidf2

This adds __powidf2 as a wrapper in LibF7. Johann -- avr: target/114981 - Support __builtin_powi[l] / __powidf2. This supports __powidf2 by means of a double wrapper for already existing f7_powi (renamed to __f7_powi by f7-renames.h). It tweaks the implementation so that it does not perform

[pushed][PR114810][LRA]: Recognize alternatives with lack of available registers for insn and demote them.

The following patch is a fix for PR114810 from LRA side. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810 The patch was successfully bootstrapped and tested on x86_64, aarch64, ppc64le. commit dc859c1fcb6f3ad95022fb078c040907ef361e4c Author: Vladimir N. Makarov Date: Wed May 8 10:39:04

Re: [PATCH 4/4] lra: Apply DF_LIVE_SUBREG data

On 5/7/24 23:01, Lehua Ding wrote: Hi Vladimir, I'll send V3 patchs based on these comments. Note that these four patches only support subreg liveness tracking and apply to IRA and LRA pass. Therefore, no performance changes are expected before we support subreg coalesce. There will be new

Re: [COMMITTED/13] Fix PR 111331: wrong code for `a > 28 ? MIN : 29`

On Sun, Oct 1, 2023 at 1:23 PM Andrew Pinski wrote: > > From: Andrew Pinski > > The problem here is after r6-7425-ga9fee7cdc3c62d0e51730, > the comparison to see if the transformation could be done was using the > wrong value. Instead of see if the inner was LE (for MIN and GE for MAX) > the

Re: [COMMITTED] Fold: Fix up merge_truthop_with_opposite_arm for NaNs [PR95351]

On Mon, Mar 11, 2024 at 11:41 PM Andrew Pinski (QUIC) wrote: > > > -Original Message- > > From: Andrew Pinski (QUIC) > > Sent: Sunday, March 10, 2024 7:58 PM > > To: gcc-patches@gcc.gnu.org > > Cc: Andrew Pinski (QUIC) > > Subject: [COMMITTED] Fold: Fix up

Re: [PATCH 1/2] Fix PR 110066: crash with -pg -static on riscv

On Sat, Jul 22, 2023 at 8:36 PM Kito Cheng via Gcc-patches wrote: > > OK for trunk, thanks:) I have now backported it to 13 branch. Thanks, Andrew > > Andrew Pinski via Gcc-patches 於 2023年7月23日 週日 > 09:07 寫道： > > > The problem -fasynchronous-unwind-tables is on by default for riscv linux > >

Re: [PATCH 2/4] df: Add DF_LIVE_SUBREG problem

On Wed, May 08, 2024 at 11:34:48AM +0800, 陈硕 wrote: > Hi Dimitar > > > I send a patch just now, modifies accordingly > > > some comments: > > > Nit: Should have two spaces after the dot, per GNU coding style. > I'd suggest > to run the contrib/check_GNU_style.py script on your patches. > Do

Products

Hello, We would like to purchase your product. Would you mind sharing your catalog with us? Thank you! Justin

[Patch, fortran] PR84006 [11/12/13/14/15 Regression] ICE in storage_size() with CLASS entity

This fix is straightforward and described by the ChangeLog. Jose Rui Faustino de Sousa posted the same fix for the ICE on the fortran list slightly more than three years ago. Thinking that he had commit rights, I deferred but, regrettably, the patch was never applied. The attached patch also fixes

Re: [PATCH] testsuite, rs6000: Remove some checks with aix[456]

On Wed, May 8, 2024 at 2:36 AM Kewen.Lin wrote: > Hi, > > Since r12-75-g0745b6fa66c69c aix6 support had been dropped, > so we don't need to check for aix[456].* when testing, this > patch is to remove such checks. > > Regtested on powerpc64-linux-gnu P8/P9 and > powerpc64le-linux-gnu P9 and P10.

Re: [PATCH 3/4] ranger: Revert the workaround introduced in PR112788 [PR112993]

I'll defer to the PPC maintainers, but LGTM. The less special casing, the better. Aldy On Wed, May 8, 2024, 07:33 Kewen.Lin wrote: > Hi, > > This reverts commit r14-6478-gfda8e2f8292a90 "range: > Workaround different type precision between _Float128 and > long double [PR112788]" as the fixes

Re: [PATCH v2 4/4] RISC-V: Cover sign-extensions in lshr3_zero_extend_4

On Wed, May 8, 2024 at 3:48 PM Jeff Law wrote: > > > > On 5/8/24 1:36 AM, Christoph Müllner wrote: > > The lshr3_zero_extend_4 pattern targets bit extraction > > with zero-extension. This pattern represents the canonical form > > of zero-extensions of a logical right shift. > > > > The same

Re: [PATCH v2 4/4] RISC-V: Cover sign-extensions in lshr3_zero_extend_4

On 5/8/24 1:36 AM, Christoph Müllner wrote: The lshr3_zero_extend_4 pattern targets bit extraction with zero-extension. This pattern represents the canonical form of zero-extensions of a logical right shift. The same optimization can be applied to sign-extensions. Given the two optimizations

Re: [PATCH v2 3/4] RISC-V: Add zero_extract support for rv64gc

On 5/8/24 1:36 AM, Christoph Müllner wrote: The combiner attempts to optimize a zero-extension of a logical right shift using zero_extract. We already utilize this optimization for those cases that result in a single instructions. Let's add a insn_and_split pattern that also matches the

Re: [PATCH v2 2/4] RISC-V: Cover sign-extensions in lshrsi3_zero_extend_2

On 5/8/24 1:36 AM, Christoph Müllner wrote: The pattern lshrsi3_zero_extend_2 extracts the MSB bits of the lower 32-bit word and zero-extends it back to DImode. This is realized using srliw, which operates on 32-bit registers. The same optimziation can be applied to sign-extensions when

Re: [PATCH v2 1/4] RISC-V: Add test for sraiw-31 special case

On 5/8/24 1:36 AM, Christoph Müllner wrote: We already optimize a sign-extension of a right-shift by 31 in si3_extend. Let's add a test for that (similar to zero-extend-1.c). gcc/testsuite/ChangeLog: * gcc.target/riscv/sign-extend-1.c: New test. OK jeff

Re: [PATCH] [RFC] Add function filtering to gcov

On Fri, Mar 29, 2024 at 8:02 PM Jørgen Kvalsvik wrote: > > This is a prototype for --include/--exclude flags, and I would like a > review of both the approach and architecture, and the implementation, > plus feedback on the feature itself. I did not update the manuals or > carefully extend

Re: [PATCH] tree-ssa-sink: Improve code sinking pass

On Wed, Mar 13, 2024 at 2:56 PM Ajit Agarwal wrote: > > Hello Richard: > > Currently, code sinking will sink code at the use points with loop having same > nesting depth. The following patch improves code sinking by placing the sunk > code in begining of the block after the labels. > > For

[pushed] wwwdocs: gcc-12: 512-bit instead of 512 bit

Same as for GCC 13, as I just noticed. Pushed. Gerald --- htdocs/gcc-12/changes.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html index b4e29d72..8a0347e3 100644 --- a/htdocs/gcc-12/changes.html +++

[pushed] wwwdocs: gcc-13: 512-bit instead of 512 bit

A detail I missed last year. My bad. Fixed thusly and pushed. Gerald --- htdocs/gcc-13/changes.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html index 15a309d6..e324b782 100644 --- a/htdocs/gcc-13/changes.html +++

Re: [PATCH, aarch64] v2: Preparatory patch to place target independent and,dependent changed code in one file

Hi Ajit, Sorry for the long delay in reviewing this. This is really getting there now. I've left a few more comments below. Apart from minor style things, the main remaining issues are mostly around comments. It's important to have good clear comments for functions with the parameters (and

Re: [PATCH 3/4] gcc/c-family/c-opts: fix quoting for `-fdeps-format=` error message

On Tue, May 07, 2024 at 21:15:09 +, Joseph Myers wrote: > That can't be right. The GCC %q is a modifier that needs to have an > actual format specifier it modifies (so %qs - which produces the same > output as %<%s%> - but not %q by itself). Yes, I got CI results of failure and noticed

[PATCH] MIPS: Support constraint 'w' for MSA instruction

Support syntax like: asm volatile ("fmadd.d %w0, %w1, %w2" : "+w"(a): "w"(b), "w"(c)); gcc * config/mips/constraints.md: Add new constraint 'w'. gcc/testsuite * gcc.target/mips/msa-inline-asm.c: New test. --- gcc/config/mips/constraints.md | 3 +++

Re: [PATCH][risc-v] libstdc++: Preserve signbit of nan when converting float to double [PR113578]

On Wed, 8 May 2024 at 11:33, Andrew Waterman wrote: > > On Tue, May 7, 2024 at 9:46 AM Jonathan Wakely wrote: > > > > On Tue, 7 May 2024 at 17:39, Jonathan Wakely wrote: > > > > > > On Tue, 7 May 2024 at 17:33, Jeff Law wrote: > > > > > > > > > > > > > > > > On 5/7/24 9:36 AM, Andreas Schwab

Re: [PATCH][risc-v] libstdc++: Preserve signbit of nan when converting float to double [PR113578]

On Tue, May 7, 2024 at 9:46 AM Jonathan Wakely wrote: > > On Tue, 7 May 2024 at 17:39, Jonathan Wakely wrote: > > > > On Tue, 7 May 2024 at 17:33, Jeff Law wrote: > > > > > > > > > > > > On 5/7/24 9:36 AM, Andreas Schwab wrote: > > > > On Mai 07 2024, Jonathan Wakely wrote: > > > > > > > >>

[patch,avr] PR114981: Implement __builtin_powif in assembly

__builtin_powif is currently implemented in C, and this patch implements it (__powisf2) in assembly. Ok for master? Johann -- AVR: target/114981 - Tweak __powisf2 Implement __powisf2 in assembly. PR target/114981 libgcc/ * config/avr/t-avr (LIB2FUNCS_EXCLUDE): Add _powisf2.

[PATCH] Fix SLP reduction initial value for pointer reductions

For pointer reductions we need to convert the initial value to the vector component integer type. Re-bootstrap and regtest running on x86_64-unknown-linux-gnu. I've ran into this latent bug on the force-slp branch. Richard. * tree-vect-loop.cc (get_initial_defs_for_reduction): Convert

[PATCH] Fix non-grouped SLP load/store accounting in alignment peeling

When we have a non-grouped access we bogously multiply by zero. This shows most with single-lane SLP but also happens with the multi-lane splat case. Re-bootstrap & regtest running on x86_64-unknown-linux-gnu. I've ran into this latent bug on the force-slp branch. Richard. *

Re: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128

on 2024/4/30 07:11, Alexandre Oliva wrote: > On Apr 29, 2024, "Kewen.Lin" wrote: > >> Thanks for catching this and sorry >> that I didn't check it before suggesting it, I think we can aggressively >> drop this effective target instead to avoid any possible confusion. > > The 128-bit ones,

Re: [PATCH] rs6000: Adjust -fpatchable-function-entry* support for dual entry [PR112980]

Hi Richi, >> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi >> index c584664e168..58e48f7dc55 100644 >> --- a/gcc/doc/invoke.texi >> +++ b/gcc/doc/invoke.texi >> @@ -18363,11 +18363,11 @@ If @code{N=0}, no pad location is recorded. >> The NOP instructions are inserted at---and maybe

Re: [PATCH] tree-ssa-loop-prefetch.cc: Honour -fno-unroll-loops

On Wed, May 8, 2024 at 9:56 AM Stefan Schulze Frielinghaus wrote: > > On s390 the following tests fail > > FAIL: gcc.dg/vect/pr109011-1.c -flto -ffat-lto-objects scan-tree-dump-times > optimized " = .CLZ (vect" 1 > FAIL: gcc.dg/vect/pr109011-1.c -flto -ffat-lto-objects scan-tree-dump-times

[PATCH] Fix and speedup IDF pruning by dominator

When insert_updated_phi_nodes_for tries to skip pruning the IDF to blocks dominated by the nearest common dominator of the set of definition blocks it compares against ENTRY_BLOCK but that's never going to be the common dominator. In fact if it ever were the code fails to copy IDF to PRUNED_IDF,

Re: [PATCH] reassoc: Fix up optimize_range_tests_to_bit_test [PR114965]

On Wed, 8 May 2024, Jakub Jelinek wrote: > Hi! > > The optimize_range_tests_to_bit_test optimization normally emits a range > test first: > if (entry_test_needed) > { > tem = build_range_check (loc, optype, unshare_expr (exp), >

[PATCH] s390: Implement TARGET_NOCE_CONVERSION_PROFITABLE_P [PR109549]

Consider a NOCE conversion as profitable if there is at least one conditional move. gcc/ChangeLog: * config/s390/s390.cc (TARGET_NOCE_CONVERSION_PROFITABLE_P): Define. (s390_noce_conversion_profitable_p): Implement. gcc/testsuite/ChangeLog: *

Re: [PATCH] rs6000: Adjust -fpatchable-function-entry* support for dual entry [PR112980]

On Wed, May 8, 2024 at 7:50 AM Kewen.Lin wrote: > > Hi, > > As the discussion in PR112980, although the current > implementation for -fpatchable-function-entry* conforms > with the documentation (making N NOPs be consecutive), > it's inefficient for both kernel and userspace livepatching > (see

[PATCH] reassoc: Fix up optimize_range_tests_to_bit_test [PR114965]

Hi! The optimize_range_tests_to_bit_test optimization normally emits a range test first: if (entry_test_needed) { tem = build_range_check (loc, optype, unshare_expr (exp), false, lowi, high); if (tem ==

[PATCH] tree-ssa-loop-prefetch.cc: Honour -fno-unroll-loops

On s390 the following tests fail FAIL: gcc.dg/vect/pr109011-1.c -flto -ffat-lto-objects scan-tree-dump-times optimized " = .CLZ (vect" 1 FAIL: gcc.dg/vect/pr109011-1.c -flto -ffat-lto-objects scan-tree-dump-times optimized " = .POPCOUNT (vect" 1 FAIL: gcc.dg/vect/pr109011-1.c

Re: [PATCH] match: `a CMP nonnegative ? a : ABS` simplified to just `ABS` [PR112392]

On Wed, May 8, 2024 at 5:25 AM Andrew Pinski wrote: > > We can optimize `a == nonnegative ? a : ABS`, `a > nonnegative ? a : > ABS` > and `a >= nonnegative ? a : ABS` into `ABS`. This allows removal of > some extra comparison and extra conditional moves in some cases. > I don't remember where I

Re: [PATCH] RISC-V: Add zero_extract support for rv64gc

On Mon, May 6, 2024 at 11:43 PM Vineet Gupta wrote: > > > > On 5/6/24 13:40, Christoph Müllner wrote: > > The combiner attempts to optimize a zero-extension of a logical right shift > > using zero_extract. We already utilize this optimization for those cases > > that result in a single

Re: [PATCH] RISC-V: Add zero_extract support for rv64gc

On Mon, May 6, 2024 at 11:24 PM Jeff Law wrote: > > > > On 5/6/24 2:40 PM, Christoph Müllner wrote: > > The combiner attempts to optimize a zero-extension of a logical right shift > > using zero_extract. We already utilize this optimization for those cases > > that result in a single

Re: [PATCH] MATCH: Add some more value_replacement simplifications (a != 0 ? expr : 0) to match

On Tue, May 7, 2024 at 10:56 PM Andrew Pinski wrote: > > On Tue, May 7, 2024 at 1:45 PM Jeff Law wrote: > > > > > > > > On 4/30/24 9:21 PM, Andrew Pinski wrote: > > > This adds a few more of what is currently done in phiopt's > > > value_replacement > > > to match. I noticed this when I was

Re: [PATCH 2/4] fortran: Teach get_real_kind_from_node for Power 128 fp modes [PR112993]

Hello, Le 08/05/2024 à 07:27, Kewen.Lin a écrit : Hi, Previously effective target fortran_real_c_float128 never passes on Power regardless of the default 128 long double is ibmlongdouble or ieeelongdouble. It's due to that TF mode is always used for kind 16 real, which has precision 127,

[PATCH v2 3/4] RISC-V: Add zero_extract support for rv64gc

The combiner attempts to optimize a zero-extension of a logical right shift using zero_extract. We already utilize this optimization for those cases that result in a single instructions. Let's add a insn_and_split pattern that also matches the generic case, where we can emit an optimized sequence

[PATCH v2 4/4] RISC-V: Cover sign-extensions in lshr3_zero_extend_4

The lshr3_zero_extend_4 pattern targets bit extraction with zero-extension. This pattern represents the canonical form of zero-extensions of a logical right shift. The same optimization can be applied to sign-extensions. Given the two optimizations are so similar, this patch converts the existing

[PATCH v2 2/4] RISC-V: Cover sign-extensions in lshrsi3_zero_extend_2

The pattern lshrsi3_zero_extend_2 extracts the MSB bits of the lower 32-bit word and zero-extends it back to DImode. This is realized using srliw, which operates on 32-bit registers. The same optimziation can be applied to sign-extensions when emitting a sraiw instead of the srliw. Given these

[PATCH v2 1/4] RISC-V: Add test for sraiw-31 special case

We already optimize a sign-extension of a right-shift by 31 in si3_extend. Let's add a test for that (similar to zero-extend-1.c). gcc/testsuite/ChangeLog: * gcc.target/riscv/sign-extend-1.c: New test. Signed-off-by: Christoph Müllner ---

Re: [V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.

On Tue, 7 May 2024, Kees Cook wrote: > On Tue, May 07, 2024 at 06:34:19PM +, Qing Zhao wrote: > > On May 7, 2024, at 13:57, Sebastian Huber > > wrote: > > > On 07.05.24 16:26, Qing Zhao wrote: > > > > Hi, Sebastian, > > > > Thanks for your explanation. > > > > Our goal is to deprecate the

Re: [PATCH] PR middle-end/111701: signbit(x*x) vs -fsignaling-nans

On Tue, May 7, 2024 at 10:44 PM Joseph Myers wrote: > > On Fri, 3 May 2024, Richard Biener wrote: > > > So what I do not necessarily agree with is that we need to preserve > > the multiplication with -fsignaling-nans. Do we consider a program doing > > > > handler() { exit(0); } > > > > x =

[PATCH] testsuite, rs6000: Remove powerpcspe test cases and checks

Hi, Since r9-4728 the powerpcspe support had been removed, this follow-up patch is to remove the remaining pieces in testsuite. Regtested on powerpc64-linux-gnu P8/P9 and powerpc64le-linux-gnu P9 and P10. I'm going to push this soon if no objections. BR, Kewen - gcc/testsuite/ChangeLog:

[PATCH] rs6000: Enable overlapped by-pieces operations

Hi, This patch enables overlapped by-piece operations. On rs6000, default move/set/clear ratio is 2. So the overlap is only enabled with compare by-pieces. Bootstrapped and tested on powerpc64-linux BE and LE with no regressions. Is it OK for the trunk? Thanks Gui Haochen ChangeLog rs6000:

Re: [PATCH] x86:Add 3-instruction subroutine vector shift for V16QI in ix86_expand_vec_perm_const_1 [PR107563]

On Wed, May 8, 2024 at 4:44 AM Levy Hsu wrote: > > PR target/107563 > > gcc/ChangeLog: > > * config/i386/i386-expand.cc (expand_vec_perm_psrlw_psllw_por): New > subroutine. > (ix86_expand_vec_perm_const_1): New Entry. > > gcc/testsuite/ChangeLog: > > *

[PATCH] testsuite, rs6000: Remove powerpc_popcntb_ok

Hi, There are three uses of effective target powerpc_popcntb_ok, they are all for compiling, but powerpc_popcntb_ok checks for executable generation, which is too heavy. This patch is to remove powerpc_popcntb_ok and adjust its three uses accordingly. Regtested on powerpc64-linux-gnu P8/P9 and

[PATCH 1/2] testsuite, rs6000: Make powerpc_vsx consider current_compiler_flags [PR114842]

Hi, As noted in PR114842, most of the test cases which require effective target check powerpc_vsx_ok actually care about if VSX feature is enabled, and they should adopt effective target powerpc_vsx instead. By considering we already have a number of test cases having explicit -mvsx in

[PATCH] testsuite, rs6000: Remove effective target powerpc_405_nocache

Hi, With the introduction of -mdejagnu-cpu=, when the test case is specifying -mdejagnu-cpu=405, it would override the other possibly given -mcpu=, so it would compile for PowerPC 405 for sure. This patch is to remove the effective target powerpc_405_nocache and update all its uses. Regtested

[PATCH] libgcc, rs6000: Remove powerpcspe related code

Hi, Since r9-4728 the powerpcspe support had been removed, this follow-up patch is to remove the remaining pieces in libgcc. Bootstrapped and regtested on powerpc64-linux-gnu P8/P9 and powerpc64le-linux-gnu P9 and P10. I'm going to push this soon if no objections. BR, Kewen -

[PATCH] rs6000: Add assert !TARGET_VSX if !TARGET_ALTIVEC and strip a useless check

Hi, In function rs6000_option_override_internal, we have the checks and adjustments like: if (TARGET_P8_VECTOR && !TARGET_ALTIVEC) rs6000_isa_flags &= ~OPTION_MASK_P8_VECTOR; if (TARGET_P8_VECTOR && !TARGET_VSX) rs6000_isa_flags &= ~OPTION_MASK_P8_VECTOR; But in fact some previous

[PATCH] testsuite, rs6000: Remove all linux*paired* checks and cases

Hi, Since r9-115-g559289370f76bf the support of paired single had been dropped, but we still have some test checks and cases for that, this patch is to get rid of them. Regtested on powerpc64-linux-gnu P8/P9 and powerpc64le-linux-gnu P9 and P10. I'm going to push this soon if no objections.

[PATCH] testsuite, rs6000: Remove some checks with aix[456]

Hi, Since r12-75-g0745b6fa66c69c aix6 support had been dropped, so we don't need to check for aix[456].* when testing, this patch is to remove such checks. Regtested on powerpc64-linux-gnu P8/P9 and powerpc64le-linux-gnu P9 and P10. I'm going to push this soon if no objections. BR, Kewen -

[PATCH] testsuite: Fix typo in torture/vector-{1,2}.c

Hi, When making some clean up patches, I happened to find test cases vector-{1,2}.c are having typo "powerpc64--*-*" in target selector, which should be powerpc64-*-*. The reason why we didn't catch before is that all our testing machines support VMX insns, so it passes always. But it would

[PATCH] rs6000: Drop useless vector_{load,store}_ defines

Hi, When I was working on a patch to get rid of TFmode, I noticed that define_expands vector_load_ and vector_store_ are useless. This patch is to clean up both. Bootstrapped and regtested on powerpc64-linux-gnu P8/P9 and powerpc64le-linux-gnu P9 and P10. I'm going to push this soon if no

[PATCH] rs6000: Remove useless entries in rreg

Hi, When I was working on a trial patch to get rid of TFmode, I noticed that mode attribute rreg only gets used for mode iterator SFDF, it means that only SF and DF key-value pairs are useful, the other are useless, so this patch is to clean up them. Bootstrapped and regtested on

[PATCH] rs6000: Remove useless operands[3]

Hi, As shown, three uses of operands[3] are totally useless, so this patch is to remove them to avoid any confusion. Bootstrapped and regtested on powerpc64-linux-gnu P8/P9 and powerpc64le-linux-gnu P9 and P10. I'm going to push this soon if no objections. BR, Kewen - gcc/ChangeLog:

[PATCH] rs6000: Clean up TF and TD check with FLOAT128_2REG_P

Hi, Commit r6-2116-g2c83faf86827bf did some clean up on TFmode and TFmode check with FLOAT128_2REG_P, but it missed to update an assertion, this patch is to make it align. btw, it's noticed when I'm making a patch to get rid of TFmode. Bootstrapped and regtested on powerpc64-linux-gnu P8/P9 and

[COMMITTED] Enable prange support.

This throws the switch on prange. After this patch, it is no longer valid to store a pointer in an irange (or vice versa). Instead, they must go in prange, which is faster and more memory efficient. I will push this now, so I have time to do any follow-up bugfixing before going on paternity