[PATCH] [i386]Add combine splitter to transform vashr/vlshr/vashl_optab to ashr/lshr/ashl_optab for const vector duplicate operand.

Hi, This patch add combine splitter to transform vashr/vlshr/vashl_optab to ashr/lshr/ashl_optab for const vector duplicate operand. Regtested on x86_64-pc-linux-gnu. Ok for trunk? BRs, Haochen gcc/ChangeLog: PR target/101796 * config/i386/predicates.md (const_vector_operand):

Re: [PATCH v8 2/2] Don't move cold code out of loop by checking bb count

On 2021/12/7 20:17, Richard Biener wrote: >>> + class loop *coldest_loop = coldest_outermost_loop[loop->num]; >>> + if (loop_depth (coldest_loop) < loop_depth (outermost_loop)) >>> +{ >>> + class loop *hotter_loop = hotter_than_inner_loop[loop->num]; >>> + if (!hotter_loop >>> +

Re: [PR103024,PR103530] support throwing compares and non-boolean types in harden-compares

On December 8, 2021 2:57:15 AM GMT+01:00, Alexandre Oliva via Gcc-patches wrote: > >This patch adjusts the harden-compares pass to cope with compares that >must end basic blocks, and to accept non-boolean integral types whose >conversion to boolean may have been discarded. > >(Andrew, thanks for

[PATCH 3/3] Fix loop split incorrect count and probability

In tree-ssa-loop-split.c, split_loop and split_loop_on_cond does two kind of split. split_loop only works for single loop and insert edge at exit when split, while split_loop_on_cond is not limited to single loop and insert edge at latch when split. Both split behavior should consider loop count a

[PATCH 2/3] Fix incorrect loop exit edge probability [PR103270]

r12-4526 cancelled jump thread path rotates loop. It exposes a issue in profile-estimate when predict_extra_loop_exits, outer loop's exit edge is marked as inner loop's extra loop exit and set with incorrect prediction, then a hot inner loop will become cold loop finally through optimizations, this

[PATCH 1/3] loop-invariant: Don't move cold bb instructions to preheader in RTL

gcc/ChangeLog: * loop-invariant.c (find_invariants_bb): Check profile count before motion. (find_invariants_body): Add argument. --- gcc/loop-invariant.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/gcc/loop-invariant.c b/gcc/loop-invarian

[PATCH 0/3] Dependency patches for hoist LIM code to cold loop

This patchset is a recollect of previously sent patches. Thanks Richard that The "Don't move cold code out of loop by checking bb count" is approved[1], but there are still 3 prerequesite patches to supplement or avoid regression. 1) Patch [1/3] is the RTL part of not hoisting LIM code out of col

[PR103302] skip multi-word pre-move clobber during lra

If we emit clobbers before multi-word moves during lra, we get confused if a copy ends up with input or output replaced with each other: the clobber then kills the previous set, and it gets deleted. This patch avoids emitting such clobbers when lra_in_progress. Regstrapped on x86_64-linux-gnu.

Re: [PATCH] [i386]Add combine splitter to transform vpcmpeqd/vpxor/vblendvps to vblendvps for ~op0

On Wed, Dec 8, 2021 at 11:13 AM Jiang, Haochen via Gcc-patches wrote: > > Hi Uros, > > I have fixed that in this patch attached for checking in. Is that ok for > trunk? > Uros already said it's ok with that change, let me check in the patch for you. > Regtested on x86_64-pc-linux-gnu. > > Thx, >

RE: [PATCH] [i386]Add combine splitter to transform vpcmpeqd/vpxor/vblendvps to vblendvps for ~op0

Hi Uros, I have fixed that in this patch attached for checking in. Is that ok for trunk? Regtested on x86_64-pc-linux-gnu. Thx, Haochen -Original Message- From: Uros Bizjak Sent: Wednesday, December 8, 2021 12:14 AM To: Jiang, Haochen Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao Subjec

[PR103097] tolerate reg-stack cross-block malformed asms

The testcase shows malformed asms in one block confuse reg-stack logic in another block. Moving the resetting of any_malformed_asm to the end of the pass enables it to take effect throughout the affected function. Regstrapped on x86_64-linux-gnu. Ok to install? for gcc/ChangeLog PR

[PR103024,PR103530] support throwing compares and non-boolean types in harden-compares

This patch adjusts the harden-compares pass to cope with compares that must end basic blocks, and to accept non-boolean integral types whose conversion to boolean may have been discarded. (Andrew, thanks for the tip on how the discarding comes about, it's saved me some head-scratching and invest

Re: [PATCH] libstdc++: Allow std::condition_variable waits to be cancelled [PR103382]

On Tue, 7 Dec 2021 at 21:52, Florian Weimer wrote: > > * Jonathan Wakely: > > > On Tue, 7 Dec 2021, 21:20 Florian Weimer via Libstdc++, > > > > wrote: > > > > * Jonathan Wakely via Libstdc: > > > > > If necessary we could keep the terminate-on-cancellation behaviour as > > > _ZNSt18condition_v

[PATCH v3] c++: Handle auto(x) in parameter-declaration-clause [PR103401]

On Mon, Dec 06, 2021 at 04:44:06PM -0500, Jason Merrill wrote: > Please also make this change to cp_parser_sizeof_operand, and add tests > involving sizeof/alignof in array bounds. OK with that change. Turns out we reject sizeof(auto(4)) because cp_parser_type_id_1 errors "invalid use of auto".

Re: [PATCH] PR fortran/103610 - ICE in gfc_convert_mpz_to_signed, at fortran/simplify.c:193

Hi Harald, when simplifying SHAPE(), we rely on spec_dimen_size returning non-negative dimensions. That actually did not happen in all cases, as the testcase by Gerhard shows. (The testcase is rather fallout from the wrong simplification). The solution is trivial: simply check the dimensions

[PATCH] PR fortran/103610 - ICE in gfc_convert_mpz_to_signed, at fortran/simplify.c:193

Dear all, when simplifying SHAPE(), we rely on spec_dimen_size returning non-negative dimensions. That actually did not happen in all cases, as the testcase by Gerhard shows. (The testcase is rather fallout from the wrong simplification). The solution is trivial: simply check the dimensions aga

Re: [PATCH] PR fortran/103607 - [9/10/11/12 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2927

On 07/12/2021 21:43, Harald Anlauf via Fortran wrote: I haven't figured out yet how to kill or fix the array decl in that case. As long as an error is reported, and the compiler doesn’t crash after it, I’m not sure there is something more to fix. Nevertheless it makes sense to catch situat

Re: [PATCH] libstdc++: Allow std::condition_variable waits to be cancelled [PR103382]

* Jonathan Wakely: > On Tue, 7 Dec 2021, 21:20 Florian Weimer via Libstdc++, > > wrote: > > * Jonathan Wakely via Libstdc: > > > If necessary we could keep the terminate-on-cancellation behaviour as > > _ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@GLIBCXX_3.4.11 > > and export t

Re: [PATCH] libstdc++: Allow std::condition_variable waits to be cancelled [PR103382]

On Tue, 7 Dec 2021, 21:20 Florian Weimer via Libstdc++, < libstd...@gcc.gnu.org> wrote: > * Jonathan Wakely via Libstdc: > > > If necessary we could keep the terminate-on-cancellation behaviour as > > _ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@GLIBCXX_3.4.11 > > and export the new b

Re: [PATCH] rs6000: Fix check_effective_target_rop_ok [PR103556, PR103586]

On 12/7/21 12:20 PM, Peter Bergner wrote: > proc check_effective_target_rop_ok { } { > -return [check_effective_target_power10_ok] > - && [check_effective_target_powerpc_elfv2] > +return [expr { [check_effective_target_power10_ok] > +&& [check_effective_target_power

Re: [PATCH] libstdc++: Allow std::condition_variable waits to be cancelled [PR103382]

* Jonathan Wakely via Libstdc: > If necessary we could keep the terminate-on-cancellation behaviour as > _ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@GLIBCXX_3.4.11 > and export the new behaviour as @@GLIBCXX_3.4.30, although this patch > doesn't do that. Note that if this fix escape

[pushed] c++: Fix decltype-bitfield1.C on i?86

This test was failing on i?86 because of: warning: width of 'A::l' exceeds its type so change the type to 'long long' and make the test run only on arches where sizeof(long long) == 8 to avoid failing like this again. Tested x86_64-pc-linux-gnu, applying to trunk. gcc/testsuite/ChangeLog:

[PATCH] libstdc++: Allow std::condition_variable waits to be cancelled [PR103382]

Tested x86_64-linux. As noted below, I don't think using symbol versioning to preserve the old behaviour is necessary here. Does anybody want to convince me otherwise? std::condition_variable::wait(unique_lock&) is incorrectly marked noexcept, which means that the __forced_unwind exception used b

Re: [PATCH] PR fortran/103418 - random_number() does not accept pointer, intent(in) array argument

Hi Mikael, Am 07.12.21 um 21:17 schrieb Mikael Morin: Hello, On 05/12/2021 22:55, Harald Anlauf via Fortran wrote: Dear all, the check of dummy arguments with pointer attribute and INTENT(IN) was broken in the case the argument was passed to an intrinsic. We therefore rejected valid code as e

[PATCH] PR fortran/103607 - [9/10/11/12 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2927

Dear all, frontend-passes.c(do_subscript) does a check on array subscripts which failed for the testcase in the PR where the array spec was foul: the upper bound finally resolves to a REAL instead of an INTEGER. (There is another related testcase by Gerhard). I haven't figured out yet how to kil

[PATCH][GCC11] PR tree-optimization/103603 - Directly resolve range_of_stmt dependencies. (Port of PR 103231/103464)

The following patch is a slight rework of the 2 patches which flatten rangers call stack.  It needed some tweaking since some of the routines have changed name or been adjusted. This has been bootstrapped on x86_64-pc-linux-gnu with no regressions.  OK for gcc-11 release branch? Andrew comm

Re: [PATCH] PR fortran/103418 - random_number() does not accept pointer, intent(in) array argument

Hello, On 05/12/2021 22:55, Harald Anlauf via Fortran wrote: Dear all, the check of dummy arguments with pointer attribute and INTENT(IN) was broken in the case the argument was passed to an intrinsic. We therefore rejected valid code as e.g. given in the PR. The patch relaxes the excessive ch

Re: [PATCH] libiberty rust-demangle, ignore .suffix

Hi Eddy, On Fri, 2021-12-03 at 01:14 +0200, Eduard-Mihai Burtescu wrote: > On Fri, Dec 3, 2021, at 00:07, Mark Wielaard wrote: > > On Thu, Dec 02, 2021 at 07:35:17PM +0200, Eduard-Mihai Burtescu > > wrote: > > > That also means that for consistency, suffixes like these should > > > be > > > handle

Ping: [PATCH, rs6000 V2] rotate and mask constants [PR94393]

Ping. On 11/22/21 1:38 PM, Pat Haugen via Gcc-patches wrote: > Updated version of the patch. Changes made from original are updated > commentary to hopefully aid readability, no functional changes. > > > Implement more two insn constants. rotate_and_mask_constant covers > 64-bit constants that

[r12-5823 Regression] FAIL: g++.dg/cpp0x/decltype-bitfield1.C -std=c++2a (test for excess errors) on Linux/x86_64

On Linux/x86_64, 3a2257e6b3fa288d6c50831987949b9ff7dfb865 is the first bad commit commit 3a2257e6b3fa288d6c50831987949b9ff7dfb865 Author: Marek Polacek Date: Sat Dec 4 12:07:41 2021 -0500 c++: Fix for decltype and bit-fields [PR95009] caused FAIL: g++.dg/cpp0x/decltype-bitfield1.C -std=

Re: [PATCH] Fix C++/93809 and C++/83469: typenames and unions

On Tue, Dec 07, 2021 at 09:59:42AM -0800, apinski--- via Gcc-patches wrote: > From: Andrew Pinski > > There are a few issues here with typenames and unions (and even struct > keywords with unions). First in cp_parser_check_class_key, > we need to allow typenames to name union types and union key

[PATCH] rs6000: Fix check_effective_target_rop_ok [PR103556, PR103586]

The new rop_ok effective target test doesn't correctly compute its expression result. Solution is to wrap the test within a expr {} statement. This has been verified to work on both powerpc64le-linux and powerpc64-linux. The original test case accidentally worked on LE, but failed on BE. Now we

[PATCH] Fix C++/93809 and C++/83469: typenames and unions

From: Andrew Pinski There are a few issues here with typenames and unions (and even struct keywords with unions). First in cp_parser_check_class_key, we need to allow typenames to name union types and union key to be able to use with typenames. The next issue is we need to record if we had a uni

Re: [PATCH] [i386]Add combine splitter to transform vpcmpeqd/vpxor/vblendvps to vblendvps for ~op0

On Tue, Dec 7, 2021 at 3:10 AM Haochen Jiang via Gcc-patches wrote: > > This patch adds combine splitter to transform vpcmpeqd/vpxor/vblendvps to > vblendvps for ~op0. > > OK for trunk? > > BRs, > Haochen > > gcc/ChangeLog: > > PR target/100738 > * config/i386/sse.md > (*_blendv_

Re: [PATCH] alias: Optimise call_may_clobber_ref_p

> > Yeah, the fast summary array lookup itself seems fine. What slowed > this down for me was instead: > > /* A single function body may be represented by multiple symbols with > different visibility. For example, if FUNC is an interposable alias, > we don't want to return anything,

[Patch]Enable -Wuninitialized + -ftrivial-auto-var-init for address taken variables

Hi, This patch is to resolve the following two issues in the current implemenation of -ftrivial-auto-var-init: 1. The 3rd parameter of function .DEFERRED_INIT is IS_VLA currently, which is not needed at all; 2. The address taken variable is replaced with a temporary variable during gimplifi

Re: [vect] Re-analyze all modes for epilogues

On 07/12/2021 11:45, Richard Biener wrote: Can you check whether, give we know the main VF, the epilogue analysis does not start with am autodetected vector mode that needs a too large VF? Hmm struggling to see how we could check this here. AFAIU before we analyze the loop for a given vector

Limit inlining functions called once

Hi, as dicussed in PR ipa/103454 there are several benchmarks that regresses for -finline-functions-called once. Runtmes: - tramp3d with -Ofast. 31% - exchange2 with -Ofast 11-21% - roms O2 9%-10% - tonto 2.5-3.5% with LTO Build times: - specfp2006 41% (mostly wrf that builds 71% faster) - sp

Re: [Patch 8/8, Arm, GCC] Introduce multilibs for PACBTI target feature. [Was RE: [Patch 7/7, Arm, GCC] Introduce multilibs for PACBTI target feature.]

On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote: -Original Message- From: Gcc-patches On Behalf Of Tejas Belagod via Gcc-patches Sent: Friday, October 8, 2021 1:19 PM To: gcc-patches@gcc.gnu.org Subject: [Patch 7/7, Arm, GCC] Introduce multilibs for PACBTI target feature.

Re: [PATCH] pch: Add support for relocation of the PCH data [PR71934]

On Tue, Dec 07, 2021 at 10:55:07AM +0100, Jakub Jelinek via Gcc-patches wrote: > So, this patch instead builds a relocation table (sorted list of addresses > in the blob which needs relocation) at PCH save time, stores it in a very > compact form into the gch file and upon restore, adjusts pointers

Re: [Patch 7/8, Arm, GCC] Emit build attributes for PACBTI target feature. [ Was RE: [Patch 6/7, Arm, GCC] Emit build attributes for PACBTI target feature.]

On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote: -Original Message- From: Gcc-patches On Behalf Of Tejas Belagod via Gcc-patches Sent: Friday, October 8, 2021 1:19 PM To: gcc-patches@gcc.gnu.org Subject: [Patch 6/7, Arm, GCC] Emit build attributes for PACBTI target feature

Re: [Patch 6/8, Arm. GCC] Add pointer authentication for stack-unwinding runtime. [Was RE: [Patch 5/7, Arm. GCC] Add pointer authentication for stack-unwinding runtime.]

On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote: -Original Message- From: Gcc-patches On Behalf Of Tejas Belagod via Gcc-patches Sent: Friday, October 8, 2021 1:18 PM To: gcc-patches@gcc.gnu.org Subject: [Patch 5/7, Arm. GCC] Add pointer authentication for stack- unwinding

Re: [Patch 5/8, Arm, GCC] Implement target feature macros for PACBTI. [Was RE: [Patch 4/7, Arm. GCC] Implement target feature macros for PACBTI.]

On 28/10/2021 12:43, Tejas Belagod via Gcc-patches wrote: -Original Message- From: Richard Earnshaw Sent: Monday, October 11, 2021 2:58 PM To: Tejas Belagod ; gcc-patches@gcc.gnu.org Subject: Re: [Patch 4/7, Arm. GCC] Implement target feature macros for PACBTI. On 08/10/2021 13:18

[PATCH] testsuite: Use attribute "noipa" in sibcall tests

...instead of attribute "noinline". For cris-elf, testsuite/gcc.dg/sibcall-3.c and sibcall-4.c "XPASS", without sibcalls being implemented. On inspection, recurser_void2 is set to be an assembly-level alias for recurser_void1 as in ".set _recurser_void2,_recurser_void1" for both these cases. IOW

Re: [PATCH 2/2] Use dominators to reduce ranger cache-flling.

On 12/7/21 02:12, Richard Biener wrote: On Mon, Dec 6, 2021 at 7:39 PM Andrew MacLeod wrote: On Well, its only does the fill now when there is range info located on an outgoing edge of the dominator. Its still used, just on a much smaller portion of the graph. We could do even better if we kn

Re: [Patch 4/8, Arm. GCC] Add testsuite library support for PACBTI target. [Was RE: [Patch 3/7, Arm, GCC] Add testsuite library support for PACBTI target.]

On 28/10/2021 12:42, Tejas Belagod via Gcc-patches wrote: -Original Message- From: Richard Earnshaw Sent: Monday, October 11, 2021 2:38 PM To: Tejas Belagod ; gcc-patches@gcc.gnu.org Subject: Re: [Patch 3/7, Arm, GCC] Add testsuite library support for PACBTI target. On 11/10/2021

[patch, Fortran] Make REAL(KIND=16) detection more robust

Hi, Right now, the logic in libgfortran for the detection of REAL(KIND=16) is in kinds-override.h: /* What are the C types corresponding to the real(kind=10) and real(kind=16) types? We currently rely on the following assumptions: -- if real(kind=10) exists, i.e. if HAVE_GFC_REAL_10 is d

Re: [SVE] PR96463 - Optimise svld1rq from vectors

Prathamesh Kulkarni writes: > On Thu, 2 Dec 2021 at 23:11, Richard Sandiford > wrote: >> >> Prathamesh Kulkarni writes: >> > Hi Richard, >> > I have attached a WIP untested patch for PR96463. >> > IIUC, the PR suggests to transform >> > lhs = svld1rq ({-1, -1, ...}, &v[0]) >> > into: >> > lhs =

Re: [vect] Re-analyze all modes for epilogues

On Tue, 7 Dec 2021, Richard Sandiford wrote: > Richard Biener writes: > > On Tue, 7 Dec 2021, Andre Vieira (lists) wrote: > > > >> Hi, > >> > >> Rebased on top of the epilogue mode patch. > >> > >> OK for trunk? > > > > @@ -7242,7 +7315,8 @@ vectorizable_reduction (loop_vec_info loop_vinfo, > >

Re: [vect] Re-analyze all modes for epilogues

Richard Biener writes: > On Tue, 7 Dec 2021, Andre Vieira (lists) wrote: > >> Hi, >> >> Rebased on top of the epilogue mode patch. >> >> OK for trunk? > > @@ -7242,7 +7315,8 @@ vectorizable_reduction (loop_vec_info loop_vinfo, > participating. */ >if (ncopies > 1 >&& (STMT_VINFO

Re: [PATCH] x86: Check FUNCTION_DECL before calling cgraph_node::get

On Tue, Dec 7, 2021 at 2:15 PM H.J. Lu wrote: > > gcc/ > > PR target/103594 > * config/i386/i386.c (ix86_call_use_plt_p): Check FUNCTION_DECL > before calling cgraph_node::get. > > gcc/testsuite/ > > PR target/103594 > * gcc.dg/pr103594.c: New test. OK. Th

[PATCH] x86: Check FUNCTION_DECL before calling cgraph_node::get

gcc/ PR target/103594 * config/i386/i386.c (ix86_call_use_plt_p): Check FUNCTION_DECL before calling cgraph_node::get. gcc/testsuite/ PR target/103594 * gcc.dg/pr103594.c: New test. --- gcc/config/i386/i386.c | 3 ++- gcc/testsuite/gcc.dg/pr1035

[PATCH] tree-optimization/103596 - fix missed propagation into switches

may_propagate_copy unnecessarily restricts propagating non-abnormals into places that currently contain an abnormal SSA name but are not the PHI argument for an abnormal edge. This causes VN to not elide a CFG path that it assumes is elided, resulting in released SSA names in the IL. The fix is t

Re: [PATCH] PR fortran/103591 - ICE in gfc_compare_string, at fortran/arith.c:1119

On 06/12/2021 23:19, Harald Anlauf via Fortran wrote: Dear all, we didn't check the type of the upper bound in a case range. Bummer. Simply add a corresponding check. Regtested on x86_64-pc-linux-gnu. OK for mainline? OK, Thanks.

Re: [PATCH] PR fortran/103588 - ICE: Simplification error in gfc_ref_dimen_size, at fortran/array.c:2407

Hello, On 06/12/2021 23:39, Harald Anlauf via Fortran wrote: diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c index 5762c8d92d4..5f9ed17f919 100644 --- a/gcc/fortran/array.c +++ b/gcc/fortran/array.c @@ -2403,11 +2403,9 @@ gfc_ref_dimen_size (gfc_array_ref *ar, int dimen, mpz_t *result, m

Re: [PATCH] Fix --help -Q output

On Thu, Dec 2, 2021 at 4:55 PM Martin Liška wrote: > > On 12/2/21 15:22, Martin Liška wrote: > > On 12/2/21 15:11, Richard Biener wrote: > >> the ?:s look odd to me, the above is equivalent to v > 0 ? 1 : 0, no? > >> Did you mean to make v > 0 v != 0? > > > > Yeah, it's typo, should be 'v != 0 ?

Re: [PATCH] gcc: vxworks: fix providing stdint.h header

> On 6 Dec 2021, at 04:05, Alexandre Oliva wrote: > > On Dec 3, 2021, Olivier Hainque wrote: > >> Alex, how does that look to you? > > LGTM, thanks, Great, thanks. I'll commit shortly and will soon start proposing the batch of other changes I have been mentioning. Some of this might not

Re: [PATCH v8 2/2] Don't move cold code out of loop by checking bb count

On Mon, Dec 6, 2021 at 6:26 AM Xionghu Luo wrote: > > > > On 2021/12/6 13:09, Xionghu Luo via Gcc-patches wrote: > > > > > > On 2021/12/1 18:09, Richard Biener wrote: > >> On Wed, Nov 10, 2021 at 4:08 AM Xionghu Luo wrote: > >>> > >>> > >>> > >>> On 2021/11/4 21:00, Richard Biener wrote: > O

Re: [PATCH] alias: Optimise call_may_clobber_ref_p

Thanks for the info. Jan Hubicka writes: >> On Mon, Dec 6, 2021 at 4:03 PM Richard Biener >> wrote: >> > >> > On Mon, Dec 6, 2021 at 11:10 AM Richard Sandiford >> > wrote: >> > > >> > > Richard Biener writes: >> > > > On Sun, Dec 5, 2021 at 10:59 PM Richard Sandiford via Gcc-patches >> > > >

Re: [vect] Re-analyze all modes for epilogues

On Tue, 7 Dec 2021, Andre Vieira (lists) wrote: > Hi, > > I've split this particular part off, since it's not only relevant to > unrolling. The new test shows how this is useful for existing (non-unrolling) > cases. I also had to fix the costing function, the main_vf / epilogue_vf > calculations

Re: [PATCH] vect: Add bias parameter for partial vectorization

Hi Kewen, Richard, thanks for the comments, I addressed them in the attached v4. Bootstrap and regtest are good as before. Regards Robindiff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md index bf033e31c1c..dc2756f83e9 100644 --- a/gcc/config/rs6000/vsx.md +++ b/gcc/config/rs6000/v

Re: [PR103149] introduce asmnesia internal function

On Fri, 3 Dec 2021, Alexandre Oliva wrote: > On Dec 2, 2021, Richard Biener wrote: > > > While adding ASMNESIA looks OK at this point, I'm not sure about the > > asm handling stuff. You mention 'reload' above, do you mean LRA? > > I meant the allocation was first visible in -fdump-rtl-reload.

Re: [vect] Re-analyze all modes for epilogues

On Tue, 7 Dec 2021, Andre Vieira (lists) wrote: > Hi, > > Rebased on top of the epilogue mode patch. > > OK for trunk? @@ -7242,7 +7315,8 @@ vectorizable_reduction (loop_vec_info loop_vinfo, participating. */ if (ncopies > 1 && (STMT_VINFO_RELEVANT (stmt_info) <= vect_used_only_l

Re: [SVE] PR96463 - Optimise svld1rq from vectors

On Thu, 2 Dec 2021 at 23:11, Richard Sandiford wrote: > > Prathamesh Kulkarni writes: > > Hi Richard, > > I have attached a WIP untested patch for PR96463. > > IIUC, the PR suggests to transform > > lhs = svld1rq ({-1, -1, ...}, &v[0]) > > into: > > lhs = vec_perm_expr > > if v is vector of 4 ele

Re: [PATCH] Fix hash_map::traverse overload

On Tue, Dec 7, 2021 at 12:10 PM Matthias Kretz wrote: > > On Tuesday, 7 December 2021 08:43:56 CET Richard Biener wrote: > > On Mon, Dec 6, 2021 at 11:47 AM Matthias Kretz wrote: > > > While reading the hash_map code I noticed this inconsistency. Bootstrapped > > > and regtested on x86_64. OK for

Re: [vect] Re-analyze all modes for epilogues

Hi, Rebased on top of the epilogue mode patch. OK for trunk? gcc/ChangeLog:     * tree-vect-loop.c (vect_estimate_min_profitable_iters): Pass new argument     suggested_unroll_factor.     (vect_analyze_loop_costing): Likewise.     (_loop_vec_info::_loop_vec_info): Initialize

Re: [AArch64] Enable generation of FRINTNZ instructions

ping On 25/11/2021 13:53, Andre Vieira (lists) via Gcc-patches wrote: On 22/11/2021 11:41, Richard Biener wrote: On 18/11/2021 11:05, Richard Biener wrote: This is a good shout and made me think about something I hadn't before... I thought I could handle the vector forms later, but the prob

[vect] Re-analyze all modes for epilogues

Hi, I've split this particular part off, since it's not only relevant to unrolling. The new test shows how this is useful for existing (non-unrolling) cases. I also had to fix the costing function, the main_vf / epilogue_vf calculations for old and new didn't take into consideration that the

Re: [PATCH] Fix hash_map::traverse overload

On Tuesday, 7 December 2021 08:43:56 CET Richard Biener wrote: > On Mon, Dec 6, 2021 at 11:47 AM Matthias Kretz wrote: > > While reading the hash_map code I noticed this inconsistency. Bootstrapped > > and regtested on x86_64. OK for trunk? > > I've inspected two users of said overload and they r

Re: [PATCH] Fix hash_map::traverse overload

On Tue, Dec 7, 2021 at 9:38 AM Matthias Kretz wrote: > > On Tuesday, 7 December 2021 08:47:56 CET Richard Biener wrote: > > On Tue, Dec 7, 2021 at 8:43 AM Richard Biener > > wrote: > > > > > > > > > > > On Mon, Dec 6, 2021 at 11:47 AM Matthias Kretz wrote: > > > > > > > > > > > > > > > While rea

[PATCH] pch: Add support for relocation of the PCH data [PR71934]

Hi! The following patch adds support for relocation of the PCH blob on PCH restore if we don't manage to get the preferred map slot for it. The GTY stuff knows where all the pointers are, after all it relocates it once during PCH save from the addresses where it was initially allocated to addresse

Re: [PATCH] Fix hash_map::traverse overload

On Tuesday, 7 December 2021 08:47:56 CET Richard Biener wrote: > On Tue, Dec 7, 2021 at 8:43 AM Richard Biener > wrote: > > > > > > > On Mon, Dec 6, 2021 at 11:47 AM Matthias Kretz wrote: > > > > > > > > > > > While reading the hash_map code I noticed this inconsistency. > > > Bootstrapped and

[PATCH] Modify combine pattern by a pseudo AND with its nonzero bits [PR93453]

Hi, This patch modifies the combine pattern with a helper - change_pseudo_and_mask when recog fails. The helper converts a single pseudo to the pseudo AND with a mask if the outer operator is IOR/XOR/PLUS and the inner operator is ASHIFT/LSHIFTRT/AND. The conversion helps on shift + ior patter

Re: [PATCH] alias: Optimise call_may_clobber_ref_p

> > Notice the ??? comment. The code does not set clobbers here because it > > assumes that tree-ssa-alias will do the right thing. > > So one may make builtins handling first, PTA next and only if both say > > "may alias" continue. Other option is to extend the code here to add > > propert clobbe

Re: [patch] lto: Don't run ipa-comdats pass during LTO

> The attached patch fixes an ICE in lto1 at lto-partition.c:215 that > was reported by a customer. Unfortunately I have no test case for > this; the customer's application is a big C++ shared library with lots > of dependencies and proprietary code under NDA. I did try reducing it > with cvise b