[PUSHED] MAINTAINERS: Add myself to Write After Approval

I forgot to do this yesterday, it is now done. Thank you to everyone who helped me get this far, Alex From 0e8b6f0dad11ece6c693e4765f3c58309ff8ef12 Mon Sep 17 00:00:00 2001 From: Waffl3x Date: Wed, 16 Apr 2025 07:26:50 -0600 Subject: [PATCH] MAINTAINERS: Add myself to Write After Approval

[PATCH] OpenMP: omp.h omp::allocator C++ Allocator interface

Tested on x86_64-pc-linux-gnu, this is only a library addition (and a few tests) so it shouldn't cause any major impacts. I also tested libgomp C to ensure the conditional compile was working. Okay for trunk? From 1ef3fe0a1f026689e64963ec9ab0b04b7e6b1bde Mon Sep 17 00:00:00 2001 From: waffl3x Da

[PATCH] Docs: Document omp::allocator::* and ompx::allocator::* allocators.

Here is a follow up patch for documentation of the omp.h allocators, I'm not super happy with it but I wanted to get eyes on it before I go to sleep tonight. I want the table in there somewhere but I'm not confident that where I put it was the right place.

Re: [PATCH v4] c-family: Implement __has_feature and __has_extension [PR60512]

On 27/09/2023 15:27, Alex Coplan wrote: > Hi, > > This is a v4 patch to address Jason's feedback here: > https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630911.html > > w.r.t. v3 it just removes a comment now that some uncertainty around > cxx_binary_liter

[PATCH] reg-notes.def: Fix up description of REG_NOALIAS

s the note: emit_move_insn (temp, valreg); /* The return value from a malloc-like function cannot alias anything else. */ last = get_last_insn (); add_reg_note (last, REG_NOALIAS, temp); Bootstrapped on aarch64-linux-gnu, OK for trunk? Thanks, Alex gcc/ChangeLog: * reg-note

[PATCH 00/11] aarch64: Add new load/store pair fusion pass

on aarch64-linux-gnu, OK for trunk? Thanks, Alex Alex Coplan (11): rtl-ssa: Fix bug in function_info::add_insn_after rtl-ssa: Add drop_memory_access helper rtl-ssa: Add entry point to allow re-parenting uses rtl-ssa: Support inferring uses of mem in change_insns rtl-ssa: Support for

[PATCH 01/11] rtl-ssa: Fix bug in function_info::add_insn_after

In the case that !insn->is_debug_insn () && next->is_debug_insn (), this function was missing an update of the prev pointer on the first nondebug insn following the sequence of debug insns starting at next. This can lead to corruption of the insn chain, in that we end up with: insn->next_any_in

[PATCH 02/11] rtl-ssa: Add drop_memory_access helper

Add a helper routine to access-utils.h which removes the memory access from an access_array, if it has one. Bootstrapped/regtested as a series on aarch64-linux-gnu, OK for trunk? gcc/ChangeLog: * rtl-ssa/access-utils.h (drop_memory_access): New. --- gcc/rtl-ssa/access-utils.h | 11 +

[PATCH 03/11] rtl-ssa: Add entry point to allow re-parenting uses

This is needed by the upcoming aarch64 load pair pass, as it can re-order stores (when alias analysis determines this is safe) and thus change which mem def a given use consumes (in the RTL-SSA view, there is no alias disambiguation of memory). Bootstrapped/regtested as a series on aarch64-linux-g

[PATCH 04/11] rtl-ssa: Support inferring uses of mem in change_insns

Currently, rtl_ssa::change_insns requires all new uses and defs to be specified explicitly. This turns out to be rather inconvenient for forming load pairs in the new aarch64 load pair pass, as the pass has to determine which mem def the final load pair consumes, and then obtain or create a suitab

[PATCH 05/11] rtl-ssa: Support for inserting new insns

The upcoming aarch64 load pair pass needs to form store pairs, and can re-order stores over loads when alias analysis determines this is safe. In the case that both mem defs have uses in the RTL-SSA IR, and both stores require re-ordering over their uses, we represent that as (tentative) deletion o

[PATCH 06/11] haifa-sched: Allow for NOTE_INSN_DELETED at start of epilogue

haifa-sched.cc:remove_notes asserts that it lands on a real (non-note) insn after advancing past NOTE_INSN_EPILOGUE_BEG, but with the upcoming post-RA aarch64 load pair pass enabled, we can land on NOTE_INSN_DELETED. This patch adjusts remove_notes to remove these if they occur at the start of the

[PATCH 07/11] aarch64, testsuite: Prevent stp in lr_free_1.c

The test is looking for individual stores which are able to be merged into stp instructions. The test currently passes -fno-schedule-fusion -fno-peephole2, presumably to prevent these stores from being turned into stps, but this is no longer sufficient with the new ldp/stp fusion pass. As such, w

[PATCH 08/11] aarch64, testsuite: Tweak sve/pcs/args_9.c to allow stps

With the new ldp/stp pass enabled, there is a change in the codegen for this test as follows: add x8, sp, 16 ptrue p3.h, mul3 str p3, [x8] - str x8, [sp, 8] - str x9, [sp] + stp x9, x8, [sp] ptrue p3.d, vl8 ptrue p

[PATCH 09/11] aarch64, testsuite: Fix up pr71727.c

The test is trying to check that we don't use q-register stores with -mstrict-align, so actually check specifically for that. This is a prerequisite to avoid regressing: scan-assembler-not "add\tx0, x0, :" with the upcoming ldp fusion pass, as we change where the ldps are formed such that a regi

[PATCH 10/11] aarch64: Generalise TFmode load/store pair patterns

This patch generalises the TFmode load/store pair patterns to TImode and TDmode. This brings them in line with the DXmode patterns, and uses the same technique with separate mode iterators (TX and TX2) to allow for distinct modes in each arm of the load/store pair. For example, in combination wit

[PATCH 11/11] aarch64: Add new load/store pair fusion pass.

ightly worse performance than using unify_access_modes. This needs some further investigation, but for now it seems reasonable to use the unify_access_modes strategy. Bootstrapped/regtested as a series on aarch64-linux-gnu, OK for trunk? Thanks, Alex gcc/ChangeLog: * config.gcc: Add aarch64-ldp

[PATCH v2 11/11] aarch64: Add new load/store pair fusion pass

didn't emit a tombstone insn for this bb. + if (!m_emitted_tombstone) +return; + insn_info *insn = m_bb->head_insn (); while (insn) { A v2 patch for the pass is attached. Bootstrapped/regtested as a series on aarch64-linux-gnu, OK for trunk? Thanks, Alex diff --git a/gcc/confi

Re: [PATCH 06/11] haifa-sched: Allow for NOTE_INSN_DELETED at start of epilogue

Hi Jeff, On 19/10/2023 08:54, Jeff Law wrote: > > > On 10/17/23 14:48, Alex Coplan wrote: > > haifa-sched.cc:remove_notes asserts that it lands on a real (non-note) > > insn after advancing past NOTE_INSN_EPILOGUE_BEG, but with the upcoming > > post-RA aarch64 loa

[PATCH] rtl-ssa: Don't leave NOTE_INSN_DELETED around

i.e.: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633349.html which shows that 6/11 is no longer required in combination with this patch (as expected). Thanks, Alex gcc/ChangeLog: * rtl-ssa/changes.cc (function_info::change_insns): Ensure we call ::remove_insn on deleted

Backport PR106878 fixes to GCC 12

r we could squash them into a single patch, if that's deemed preferable). I've bootstrapped and tested these on top of the GCC 12 branch on both x86_64-linux-gnu and aarch64-linux-gnu, and there were no regressions. OK for the GCC 12 branch? Thanks, Alex commit 557c126f9fbdcde256f134d4ed34f

Re: [PATCH v4] c-family: Implement __has_feature and __has_extension [PR60512]

On 11/10/2023 14:31, Alex Coplan wrote: > On 27/09/2023 15:27, Alex Coplan wrote: > > Hi, > > > > This is a v4 patch to address Jason's feedback here: > > https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630911.html > > > > w.r.t. v3 it just

Re: [PATCH V2 5/7] aarch64: Implement system register r/w arm ACLE intrinsic functions

type_node, double_type_node, > >>> NULL); > >>> aarch64_builtin_decls[AARCH64_JSCVT] > >>> @@ -2599,6 +2671,123 @@ aarch64_expand_rng_builtin (tree exp, rtx target, > >>> int fcode, int ignore) > >>> return target; > >>> } > >>> > >>> +/* Expand the read/write system register builtin EXPs. */ > >>> +rtx > >>> +aarch64_expand_rwsr_builtin (tree exp, rtx target, int fcode) > >>> +{ > >>> + tree arg0, arg1; > >>> + rtx const_str, input_val, subreg; > >>> + enum machine_mode mode; > >>> + class expand_operand ops[2]; > >>> + > >>> + arg0 = CALL_EXPR_ARG (exp, 0); > >>> + > >>> + bool write_op = (fcode == AARCH64_WSR > >>> +|| fcode == AARCH64_WSRP > >>> +|| fcode == AARCH64_WSR64 > >>> +|| fcode == AARCH64_WSRF > >>> +|| fcode == AARCH64_WSRF64); > >>> + bool read_op = (fcode == AARCH64_RSR > >>> + || fcode == AARCH64_RSRP > >>> + || fcode == AARCH64_RSR64 > >>> + || fcode == AARCH64_RSRF > >>> + || fcode == AARCH64_RSRF64); > >> > >> Instead of this, how about using: > >> > >>if (call_expr_nargs (exp) == 1) > >> > >> for the read path? > >> > > > > Personally, I don't like that. It's a `read_op' because of the fcode it > > has, the fact they share the same number of arguments is accidental. > > With this implementation, we outline very early on exactly what > > constitutes both a valid write and a valid read operation. > > I don't agree that it's accidental. :) But fair enough, I won't push it. FWIW I agree with Richard that it isn't accidental that reads have one argument and writes have two, it's an inherent property of how the operations work. I think it would be better to use call_expr_nargs (exp) == 1 as suggested above. IIUC, presumably the operation must either be a read or a write so having two separate booleans (read_op and write_op) doesn't make much sense either? > > > I'm happy to change things around if you feel strongly enough about it > > or see some material advantage to doing things your way that I've missed :). Thanks, Alex

Re: [PATCH v4] c-family: Implement __has_feature and __has_extension [PR60512]

Hi Jason, On 26/10/2023 17:06, Jason Merrill wrote: > On 10/25/23 06:28, Alex Coplan wrote: > > On 11/10/2023 14:31, Alex Coplan wrote: > > > On 27/09/2023 15:27, Alex Coplan wrote: > > > > Hi, > > > > > > > > This is a v4 patch to addr

Re: libbacktrace: Add support for MiniDebugInfo

rapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed > to mainline. > > Ian Thanks, Alex

Re: libbacktrace: Add support for MiniDebugInfo

On 16/09/2020 07:26, Ian Lance Taylor wrote: > On Wed, Sep 16, 2020, 4:03 AM Alex Coplan wrote: > > > Hi Ian, > > > > On 14/09/2020 14:12, Ian Lance Taylor via Gcc-patches wrote: > > > This patch to libbacktrace adds support for MiniDebugInfo, as > > > r

Re: [PATCH] aarch64: Add extend-as-extract-with-shift pattern [PR96998]

Hi Richard, On 10/09/2020 19:18, Richard Sandiford wrote: > Alex Coplan writes: > > Hello, > > > > Since r11-2903-g6b3034eaba83935d9f6dfb20d2efbdb34b5b00bf introduced a > > canonicalization from mult to shift on address reloads, a missing > > pattern i

Re: [PATCH] aarch64: Add extend-as-extract-with-shift pattern [PR96998]

Hi Richard, Segher, On 17/09/2020 08:10, Richard Sandiford wrote: > Alex Coplan writes: > > Hi Richard, > > > > On 10/09/2020 19:18, Richard Sandiford wrote: > >> Alex Coplan writes: > >> > Hello, > >> > > >> > Sin

Re: [PATCH] aarch64: Don't generate invalid zero/sign-extend syntax

Hi Christophe, On 08/09/2020 10:14, Christophe Lyon wrote: > On Mon, 17 Aug 2020 at 11:00, Alex Coplan wrote: > > > > gcc/ChangeLog: > > > > * config/aarch64/aarch64.md > > (*adds__): Ensure extended operand > > a

Re: [PATCH] aarch64: Add extend-as-extract-with-shift pattern [PR96998]

REG_DEAD r106:DI > Inserting insn reload before: > 817: r324:DI=sign_extract(r232:SI#0<<0x3,0x23,0) > 818: r324:DI=r324:DI+r284:DI > 819: r325:DI=r106:DI > > (and then it died). > > > Can you fix this first? There probably is something target-specific > wrong related to zero_extract. The intent is to fix this in combine here. See the earlier replies in this thread. > > > Segher Thanks, Alex

[PATCH 1/2] aarch64: Add support for Neoverse V1 CPU

This patch adds support for Arm's Neoverse V1 CPU to the AArch64 backend. Testing: * Bootstrapped and regtested on aarch64-none-linux-gnu. OK for trunk? Thanks, Alex --- gcc/ChangeLog: * config/aarch64/aarch64-cores.def: Add Neoverse V1. * config/aarch64/aarch64-tu

[PATCH 2/2] arm: Add support for Neoverse V1 CPU

This patch adds support for Arm's Neoverse V1 CPU to the AArch32 backend. Testing: * Bootstrapped and regtested on arm-none-linux-gnueabihf. OK for trunk? Thanks, Alex --- gcc/ChangeLog: * config/arm/arm-cpus.in (neoverse-v1): New. * config/arm/arm-tables.opt: Regen

[PATCH][GCC 10] aarch64: Add support for Neoverse V1 CPU

This patch backports the AArch64 support for Arm's Neoverse V1 CPU to GCC 10. Testing: * Bootstrapped and regtested on aarch64-none-linux-gnu. OK for GCC 10 branch? Thanks, Alex --- gcc/ChangeLog: * config/aarch64/aarch64-cores.def: Add Neoverse V1. * config/aarch64/aa

[PATCH][GCC 9] aarch64: Add support for Neoverse V1 CPU

This patch backports the AArch64 support for Arm's Neoverse V1 CPU to GCC 9. Testing: * Bootstrapped and regtested on aarch64-none-linux-gnu. OK for GCC 9 branch? Thanks, Alex --- gcc/ChangeLog: * config/aarch64/aarch64-cores.def: Add Neoverse V1. * config/aarch64/aa

[PATCH][GCC 8] aarch64: Add support for Neoverse V1 CPU

This patch backports the AArch64 support for Arm's Neoverse V1 CPU to GCC 8. Testing: * Bootstrapped and regtested on aarch64-none-linux-gnu. OK for GCC 8 branch? Thanks, Alex --- gcc/ChangeLog: * config/aarch64/aarch64-cores.def: Add Neoverse V1. * config/aarch64/aa

[PATCH 1/2] aarch64: Add support for Neoverse N2 CPU

This patch adds support for Arm's Neoverse N2 CPU to the AArch64 backend. Testing: * Bootstrapped and regtested on aarch64-none-linux-gnu. OK for trunk? Thanks, Alex --- gcc/ChangeLog: * config/aarch64/aarch64-cores.def: Add Neoverse N2. * config/aarch64/aarch64-tu

[PATCH 2/2] arm: Add support for Neoverse N2 CPU

This adds support for Arm's Neoverse N2 CPU to the AArch32 backend. Neoverse N2 builds AArch32 at EL0 and therefore needs support in AArch32 GCC. Testing: * Bootstrapped and regtested on arm-none-linux-gnueabihf. OK for master? Thanks, Alex --- gcc/ChangeLog: * config/ar

[PATCH] arm: Add missing Neoverse V1 feature

Hello, This simple follow-on patch adds a missing feature (FP16) to the Neoverse V1 description in AArch32 GCC. OK for master? Thanks, Alex --- gcc/ChangeLog: * config/arm/arm-cpus.in (neoverse-v1): Add FP16. diff --git a/gcc/config/arm/arm-cpus.in b/gcc/config/arm/arm-cpus.in index

[committed] aarch64: Fix ordering of aarch64-cores.def

Hi all, This patch moves the entry for Neoverse N2 (an Armv8.5-A CPU) after Saphira (an Armv8.4-A CPU) to preserve the overall ordering in the file. Committing as obvious. Thanks, Alex --- gcc/ChangeLog: * config/aarch64/aarch64-cores.def: Move neoverse-n2 after saphira

[PATCH][GCC 10] arm: Add support for Neoverse V1 CPU

Hello, This patch backports the AArch32 support for Arm's Neoverse V1 CPU to GCC 10. Testing: * Bootstrapped and regtested on arm-none-linux-gnueabihf. OK for GCC 10 branch? Thanks, Alex --- gcc/ChangeLog: * config/arm/arm-cpus.in (neoverse-v1): New. * config/ar

[PATCH][GCC 9] arm: Add support for Neoverse V1 CPU

Hello, This patch backports the AArch32 support for Arm's Neoverse V1 CPU to GCC 9. Testing: * Bootstrapped and regtested on arm-none-linux-gnueabihf. OK for GCC 9 branch? Thanks, Alex --- gcc/ChangeLog: * config/arm/arm-cpus.in (neoverse-v1): New. * config/ar

Re: [PATCH] aarch64: Add extend-as-extract-with-shift pattern [PR96998]

Hi Segher, Gentle ping. Is the combine change (a canonicalization fix, as described below) OK for trunk in light of this info? On 22/09/2020 17:08, Richard Sandiford wrote: > Segher Boessenkool writes: > > Hi Alex, > > > > On Tue, Sep 22, 2020 at 08:40:07AM +0100, Alex Cop

[PATCH][GCC 8] arm: Add support for Neoverse V1 CPU

Hello, This patch backports the AArch32 support for Arm's Neoverse V1 CPU to GCC 8. Testing: * Bootstrapped and regtested on arm-none-linux-gnueabihf. OK for GCC 8 branch? Thanks, Alex --- gcc/ChangeLog: * config/arm/arm-cpus.in (neoverse-v1): New. * config/ar

[PATCH] arm: Fix ICEs in no-literal-pool.c on MVE

rm/pure-code/no-literal-pool.c -Os scan-assembler text,"0x2006" FAIL->PASS: gcc.target/arm/pure-code/no-literal-pool.c -Os (test for excess errors) UNRESOLVED->PASS: gcc.target/arm/thumb2-slow-flash-data-1.c scan-assembler-not \\.(float|l\\?double|d?byte|short|int|long|

Re: [PATCH V3 0/2] aarch64: Place target independent and dependent changed code in one file.

On 23/02/2024 16:41, Ajit Agarwal wrote: > Hello Richard/Alex/Segher: Hi Ajit, Sorry for the delay and thanks for working on this. Generally this looks like the right sort of approach (IMO) but I've left some comments below. I'll start with a meta comment: in the subject line yo

[PATCH] wwwdocs: Add note to changes.html for __has_{feature,extension}

Hi, This adds a note to the GCC 14 release notes mentioning support for __has_{feature,extension} (PR60512). OK to commit? Thanks, Alex diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html index 9fd224c1..facead8d 100644 --- a/htdocs/gcc-14/changes.html +++ b/htdocs/gcc-14

Re: [PATCH V4 1/3] aarch64: Place target independent and dependent changed code in one file

On 05/04/2024 13:53, Ajit Agarwal wrote: > Hello Alex/Richard: > > All review comments are incorporated. Thanks, I was kind-of expecting you to also send the renaming patch as a preparatory patch as we discussed. Sorry for another meta comment, but: I think the reason that the Linaro

[PATCH][committed] aarch64: Fix whitespace in aarch64-ldp-fusion.cc:alias_walker

I spotted this whitespace error during the review of https://gcc.gnu.org/pipermail/gcc-patches/2024-April/648846.html. Pushing as obvious after testing on aarch64-linux-gnu. Thanks, Alex gcc/ChangeLog: * config/aarch64/aarch64-ldp-fusion.cc (struct alias_walker): Fix double

Re: [PATCH V4 1/3] aarch64: Place target independent and dependent changed code in one file

On 09/04/2024 17:30, Ajit Agarwal wrote: > > > On 05/04/24 10:03 pm, Alex Coplan wrote: > > On 05/04/2024 13:53, Ajit Agarwal wrote: > >> Hello Alex/Richard: > >> > >> All review comments are incorporated. > > > > Thanks, I was kind

Re: [PATCH V4 1/3] aarch64: Place target independent and dependent changed code in one file

On 09/04/2024 20:01, Ajit Agarwal wrote: > Hello Alex: > > On 09/04/24 7:29 pm, Alex Coplan wrote: > > On 09/04/2024 17:30, Ajit Agarwal wrote: > >> > >> > >> On 05/04/24 10:03 pm, Alex Coplan wrote: > >>> On 05/04/2024 13:53, Ajit Agarw

Re: [PATCH V4 1/3] aarch64: Place target independent and dependent changed code in one file

Hi Ajit, On 09/04/2024 20:59, Ajit Agarwal wrote: > Hello Alex: > > On 09/04/24 8:39 pm, Alex Coplan wrote: > > On 09/04/2024 20:01, Ajit Agarwal wrote: > >> Hello Alex: > >> > >> On 09/04/24 7:29 pm, Alex Coplan wrote: > >>> On 09/04/2024 17

Re: [PATCH V4 1/3] aarch64: Place target independent and dependent changed code in one file

Hi Ajit, On 10/04/2024 15:31, Ajit Agarwal wrote: > Hello Alex: > > On 10/04/24 1:42 pm, Alex Coplan wrote: > > Hi Ajit, > > > > On 09/04/2024 20:59, Ajit Agarwal wrote: > >> Hello Alex: > >> > >> On 09/04/24 8:39 pm, Alex Copla

[PATCH] aarch64: Preserve mem info on change of base for ldp/stp [PR114674]

. Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk when stage 1 opens for GCC 15? Thanks, Alex gcc/ChangeLog: PR target/114674 * config/aarch64/aarch64-ldp-fusion.cc (ldp_bb_info::fuse_pair): Use replace_equiv_address_nv on a change of base instead of adjust_ad

Re: [PATCH V4 1/3] aarch64: Place target independent and dependent changed code in one file

On 10/04/2024 23:48, Ajit Agarwal wrote: > Hello Alex: > > On 10/04/24 7:52 pm, Alex Coplan wrote: > > Hi Ajit, > > > > On 10/04/2024 15:31, Ajit Agarwal wrote: > >> Hello Alex: > >> > >> On 10/04/24 1:42 pm, Alex Coplan wrote: > >>

Re: [PATCH v2] c++: avoid -Wdangling-reference for std::span-like classes [PR110358]

On 31/01/2024 15:53, Marek Polacek wrote: > On Wed, Jan 31, 2024 at 07:44:41PM +0000, Alex Coplan wrote: > > Hi Marek, > > > > On 30/01/2024 13:15, Marek Polacek wrote: > > > On Thu, Jan 25, 2024 at 10:13:10PM -0500, Jason Merrill wrote: > > >

[PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658]

Bootstrapped/regtested on x86_64-apple-darwin, OK for trunk? Thanks, Alex -- >8 -- When __has_feature was introduced for GCC 14, I included the feature cxx_constexpr_string_builtins, since of the relevant string builtins that GCC implements, it seems to support constexpr evaluation of th

Re: [PATCH] c++: Don't advertise cxx_constexpr_string_builtins [PR113658]

On 02/02/2024 09:34, Marek Polacek wrote: > On Fri, Feb 02, 2024 at 10:27:23AM +0000, Alex Coplan wrote: > > Bootstrapped/regtested on x86_64-apple-darwin, OK for trunk? > > > > Thanks, > > Alex > > > > -- >8 -- > > > > When __has_fea

Re: [PATCH][PUSHED] hwasan: support new dg-output format.

ove test (large-aligned-1.c) failing on the GCC 12 branch due to the change in output format mentioned above. This patch (committed as r13-100-g3771486daa1e904ceae6f3e135b28e58af33849f) seems to apply cleanly on the GCC 12 branch too, is it OK to backport to GCC 12? Thanks, Alex >

[PATCH][GCC 12] aarch64: Avoid out-of-range shrink-wrapped saves [PR111677]

committed as r13-100-g3771486daa1e904ceae6f3e135b28e58af33849f) which should fix that (independent) issue for GCC 12: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645278.html OK for the GCC 12 branch? Thanks, Alex -- >8 -- The PR shows us ICEing due to an unrecognizable

Re: [PATCH][GCC 12] aarch64: Avoid out-of-range shrink-wrapped saves [PR111677]

On 14/02/2024 11:18, Richard Sandiford wrote: > Alex Coplan writes: > > This is a backport of the GCC 13 fix for PR111677 to the GCC 12 branch. > > The only part of the patch that isn't a straight cherry-pick is due to > > the TX iterator lacking TDmode for GCC 1

Re: [PATCH 0/1 V2] Target independent code for common infrastructure of load,store fusion for rs6000 and aarch64 target.

everything within aarch64-ldp-fusion.cc, and then > (as separate patches) move the target-independent pieces outside > config/aarch64. but this adds the target-independent parts separately instead of splitting it out within config/aarch64 (which I agree should make the review easier). Than

Re: [PATCH 0/1 V2] Target independent code for common infrastructure of load,store fusion for rs6000 and aarch64 target.

On 15/02/2024 22:38, Ajit Agarwal wrote: > Hello Alex: > > On 15/02/24 10:12 pm, Alex Coplan wrote: > > On 15/02/2024 21:24, Ajit Agarwal wrote: > >> Hello Richard: > >> > >> As per your suggestion I have divided the patch into target independent >

[PATCH v2] aarch64: Fix dwarf2cfi ICEs due to recent CFI note changes [PR113077]

This is a v2 which addresses feedback from v1, posted here: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642313.html Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk? Thanks, Alex -- >8 -- In r14-6604-gd7ee988c491cde43d04fe25f2b3dbad9d85ded45 we changed the CFI no

[PATCH] aarch64: Make ldp/stp pass off by default

As discussed on IRC, this makes the aarch64 ldp/stp pass off by default. This should stabilize the trunk and give some time to address the P1 regressions. Sorry for the breakage. Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk? Alex gcc/ChangeLog: * config/aarch64/aarch64

[PATCH v3] aarch64: Fix dwarf2cfi ICEs due to recent CFI note changes [PR113077]

abled, OK for trunk? Thanks, Alex -- >8 -- In r14-6604-gd7ee988c491cde43d04fe25f2b3dbad9d85ded45 we changed the CFI notes attached to callee saves (in aarch64_save_callee_saves). That patch changed the ldp/stp representation to use unspecs instead of PARALLEL moves. This meant that we n

[PATCH 0/4] aarch64, rtl-ssa: Fix wrong code in ldp fusion pass [PR113070]

wrong as it ends up incorrectly skipping over the stp insn when analysing subsequent load pair candidates. Bootstrapped/regtested as a series with/without the passes enabled on aarch64-linux-gnu (1/4 also tested independently and no regressions). OK for trunk? Thanks, Alex Alex Coplan (4): rtl-ssa

[PATCH 1/4] rtl-ssa: Run finalize_new_accesses forwards [PR113070]

, OK for trunk? Thanks, Alex gcc/ChangeLog: PR target/113070 * rtl-ssa/changes.cc (function_info::change_insns): Split out the call to finalize_new_accesses from the backwards placement loop, run it forwards in a separate loop. --- gcc/rtl-ssa/changes.cc | 21

[PATCH 2/4] rtl-ssa: Support for creating new uses [PR113070]

This exposes an interface for users to create new uses in RTL-SSA. This is needed for updating uses after inserting a new store pair insn in the aarch64 load/store pair fusion pass. gcc/ChangeLog: PR target/113070 * rtl-ssa/accesses.cc (function_info::create_use): New. * r

[PATCH 3/4] rtl-ssa: Ensure new defs get inserted [PR113070]

w_accesses requires it to get cleared. Bootstrapped/regtested as a series on aarch64-linux-gnu, OK for trunk? Thanks, Alex gcc/ChangeLog: PR target/113070 * rtl-ssa.h: Include hash-set.h. * rtl-ssa/changes.cc (function_info::finalize_new_accesses): Add new_sets par

[PATCH 4/4] aarch64: Fix up uses of mem following stp insert [PR113070]

trunk? Thanks, Alex gcc/ChangeLog: PR target/113070 * config/aarch64/aarch64-ldp-fusion.cc (struct stp_change_builder): New. (decide_stp_strategy): Reanme to ... (try_repurpose_store): ... this. (ldp_bb_info::fuse_pair): Refactor to use stp_ch

[PATCH] aarch64: Don't record hazards against paired insns [PR113356]

e non-call-exceptions case, either the move range includes insns[1], or we reject the pair (thus the assert tripped in the PR should always hold). Bootstrapped/regtested on aarch64-linux-gnu with/without ldp passes enabled on top of the PR113070 fixes, OK for trunk? Thanks, Alex gcc/ChangeLo

Re: [PATCH 4/4] aarch64: Fix up uses of mem following stp insert [PR113070]

On 13/01/2024 15:46, Alex Coplan wrote: > As the PR shows (specifically #c7) we are missing updating uses of mem > when inserting an stp in the aarch64 load/store pair fusion pass. This > patch fixes that. > > RTL-SSA has a simple view of memory and by default doesn't all

Re: [PATCH] aarch64: Fix aarch64_ldp_reg_operand predicate not to allow all subreg [PR113221]

{ dg-options "-fno-move-loop-invariants -funroll-all-loops" } */ Does this need to be dg-additional-options? Naively I would expect the dg-options clause to override the torture options (and potentially any options provided in RUNTESTFLAGS, e.g. to re-enable the ldp/stp pas

Re: [PATCH 1/4] rtl-ssa: Run finalize_new_accesses forwards [PR113070]

On 17/01/2024 07:42, Jeff Law wrote: > > > On 1/13/24 08:43, Alex Coplan wrote: > > The next patch in this series exposes an interface for creating new uses > > in RTL-SSA. The intent is that new user-created uses can consume new > > user-created defs in the same cha

[PATCH 1/3] rtl-ssa: Provide easier access to debug uses [PR113089]

This patch adds some accessors to set_info and use_info to make it easier to get at and iterate through uses in debug insns. It is used by the aarch64 load/store pair fusion pass in a subsequent patch to fix PR113089, i.e. to update debug uses in the pass. Bootstrapped/regtested as a series on aa

[PATCH 2/3] aarch64: Re-parent trailing nondebug base reg uses [PR113089]

for trunk? Thanks, Alex gcc/ChangeLog: PR target/113089 * config/aarch64/aarch64-ldp-fusion.cc (ldp_bb_info::fuse_pair): Update trailing nondebug uses of the base register in the case of cancelling writeback. --- gcc/config/aarch64/aarch64-ldp-fusion.cc | 24

[PATCH 3/3] aarch64: Fix up debug uses in ldp/stp pass [PR113089]

passes enabled). Bootstrapped/regtested as a series on aarch64-linux-gnu (with/without the pass enabled). OK for trunk? Thanks, Alex gcc/ChangeLog: PR target/113089 * config/aarch64/aarch64-ldp-fusion.cc (reset_debug_use): New. (fixup_debug_use): New

[PATCH] aarch64: Don't assert recog success in ldp/stp pass [PR113114]

15. Bootstrapped/regtested on aarch64-linux-gnu (with/without passes enabled), OK for trunk? Thanks, Alex gcc/ChangeLog: PR target/113114 * config/aarch64/aarch64-ldp-fusion.cc (try_promote_writeback): Don't assert recog success, just punt if the writeback pair

Re: [PATCH 2/4] rtl-ssa: Support for creating new uses [PR113070]

On 22/01/2024 13:45, Richard Sandiford wrote: > Alex Coplan writes: > > This exposes an interface for users to create new uses in RTL-SSA. > > This is needed for updating uses after inserting a new store pair insn > > in the aarch64 load/store pair fusion pass.

Re: [PATCH 3/4] rtl-ssa: Ensure new defs get inserted [PR113070]

On 22/01/2024 13:49, Richard Sandiford wrote: > Alex Coplan writes: > > In r14-5820-ga49befbd2c783e751dc2110b544fe540eb7e33eb I added support to > > RTL-SSA for inserting new insns, which included support for users > > creating new defs. > > > > However, I missed

Re: [PATCH 4/4] aarch64: Fix up uses of mem following stp insert [PR113070]

On 22/01/2024 15:59, Richard Sandiford wrote: > Alex Coplan writes: > > As the PR shows (specifically #c7) we are missing updating uses of mem > > when inserting an stp in the aarch64 load/store pair fusion pass. This > > patch fixes that. > > > > RTL-SSA h

Re: [PATCH 3/3] aarch64: Fix up debug uses in ldp/stp pass [PR113089]

On 22/01/2024 17:09, Richard Sandiford wrote: > Sorry for the earlier review comment about debug insns. I hadn't > looked far enough into the queue to see this patch. > > Alex Coplan writes: > > As the PR shows, we were missing code to update debug uses in the > >

Re: [PATCH 4/4] aarch64: Fix up uses of mem following stp insert [PR113070]

On 22/01/2024 21:50, Alex Coplan wrote: > On 22/01/2024 15:59, Richard Sandiford wrote: > > Alex Coplan writes: > > > As the PR shows (specifically #c7) we are missing updating uses of mem > > > when inserting an stp in the aarch64 load/store pair fusion pass.

[PATCH] aarch64: Re-enable ldp/stp fusion pass

://gcc.gnu.org/pipermail/gcc-patches/2024-January/642478.html Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk? Thanks, Alex gcc/ChangeLog: * config/aarch64/aarch64.opt (-mearly-ldp-fusion): Set default to 1. (-mlate-ldp-fusion): Likewise. diff --git a/gcc/config

Re: [PATCH] aarch64: Re-enable ldp/stp fusion pass

On 24/01/2024 09:15, Kyrylo Tkachov wrote: > Hi Alex, > > > -Original Message- > > From: Alex Coplan > > Sent: Wednesday, January 24, 2024 8:34 AM > > To: gcc-patches@gcc.gnu.org > > Cc: Richard Earnshaw ; Richard Sandiford > > ; Kyrylo Tkacho

Re: [PATCH V2] rs6000: New pass for replacement of adjacent loads fusion (lxv).

rs6000_gen_load_pair, but it should let fuse_pair make those changes using RTL-SSA instead. I've left some more specific (but still mostly high-level) comments below. > > For AARCH64 architectures just include "fusion-common.h" > and target dependent code can be

Re: [PATCH] aarch64: Fix undefinedness while testing the J constraint [PR100204]

quot;aarch64_uimm12_shift (-ival)"))) > + (match_test "aarch64_uimm12_shift (- (unsigned HOST_WIDE_INT) ival)"))) Sorry for the nitpick, but: I don't think we want a space after the unary - here (at least according to https://gcc.gnu.org/codingconventions.html).

[PATCH] aarch64: Ensure iterator validity when updating debug uses [PR113616]

hould be safe because there are no clobbers of mem in RTL-SSA, so all defs of memory should be set_infos. Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk? Thanks, Alex gcc/ChangeLog: PR target/113616 * config/aarch64/aarch64-ldp-fusion.cc (fixup_debug_uses_trailin

[PATCH] aarch64: Avoid out-of-range shrink-wrapped saves [PR111677]

sted on aarch64-linux-gnu, OK for trunk? Thanks, Alex gcc/ChangeLog: PR target/111677 * config/aarch64/aarch64.cc (aarch64_reg_save_mode): Use V16QImode for the full 16-byte FPR saves in the vector PCS case. gcc/testsuite/ChangeLog: PR target/111677 * gcc

[PATCH][GCC 13] aarch64: Avoid out-of-range shrink-wrapped saves [PR111677]

Bootstrapped/regtested on aarch64-linux-gnu, OK for the 13 branch after a week of the trunk fix being in? OK for the other active branches if the same changes test cleanly there? GCC 14 patch for reference: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/61.html Thanks, Alex -- &g

Re: [PATCH v2] c++: avoid -Wdangling-reference for std::span-like classes [PR110358]

hain/src/gcc/gcc/../libcpp/include -I/home/alecop01/toolchain/src/gcc/gcc/../libcody -I/home/alecop01/toolchain/src/gcc/gcc/../libdecnumber -I/home/alecop01/toolchain/src/gcc/gcc/../libdecnumber/bid -I../libdecnumber -I/home/alecop01/toolchain/src/gcc/gcc/../libbacktrace -I. -I. -I/home/alecop01/toolchain/src/gcc/gcc -I/home/alecop01/toolchain/src/gcc/gcc/. -I/home/alecop01/toolchain/src/gcc/gcc/../include -I/home/alecop01/toolchain/src/gcc/gcc/../libcpp/include -I/home/alecop01/toolchain/src/gcc/gcc/../libcody -I/home/alecop01/toolchain/src/gcc/gcc/../libdecnumber -I/home/alecop01/toolchain/src/gcc/gcc/../libdecnumber/bid -I../libdecnumber -I/home/alecop01/toolchain/src/gcc/gcc/../libbacktrace \ /home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64-early-ra.cc /home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64-early-ra.cc: In member function ‘void {anonymous}::early_ra::record_constraints(rtx_insn*)’: /home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64-early-ra.cc:1858:66: error: possibly dangling reference to a temporary [-Werror=dangling-reference] 1858 | for (auto &allocno : get_allocno_subgroup (op).allocnos ()) | ^ /home/alecop01/toolchain/src/gcc/gcc/config/aarch64/aarch64-early-ra.cc:1858:65: note: the temporary was destroyed at the end of the full expression ‘(({anonymous}::early_ra*)this)->{anonymous}::early_ra::get_allocno_subgroup(op).{anonymous}::early_ra::allocno_subgroup::allocnos()’ 1858 | for (auto &allocno : get_allocno_subgroup (op).allocnos ()) | ~~~^~ cc1plus: all warnings being treated as errors make[3]: *** [/home/alecop01/toolchain/src/gcc/gcc/config/aarch64/t-aarch64:200: aarch64-early-ra.o] Error 1 make[3]: Leaving directory '/work/builds/bstrap/gcc' make[2]: *** [Makefile:5096: all-stage2-gcc] Error 2 make[2]: Leaving directory '/work/builds/bstrap' make[1]: *** [Makefile:25405: stage2-bubble] Error 2 make[1]: Leaving directory '/work/builds/bstrap' make: *** [Makefile:1100: all] Error 2 Is the patch expected to introduce new warnings? I'll try to reduce a testcase from this where we don't see the warning before and we see the warning afterwards. Thanks, Alex > > Marek >

Re: [PATCH v2 09/11] aarch64: Rewrite non-writeback ldp/stp patterns

On 12/12/2023 15:58, Richard Sandiford wrote: > Alex Coplan writes: > > Hi, > > > > This is a v2 version which addresses feedback from Richard's review > > here: > > > > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637648.html > >

[PATCH 1/2] emit-rtl, lra: Move lra's emit_inc to emit-rtl.cc

g, we have to avoid clobbering recog_data. We do this by introducing a new RAII class for saving/restoring recog_data on the stack. Bootstrapped/regtested on aarch64-linux-gnu, bootstrapped on x86_64-linux-gnu, OK for trunk? Thanks, Alex gcc/ChangeLog: PR target/112906 * e

[PATCH 2/2] aarch64: Handle autoinc addresses in ld1rq splitter [PR112906]

This patch uses the new force_reload_address routine added by the previous patch to fix PR112906. Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk? Thanks, Alex gcc/ChangeLog: PR target/112906 * config/aarch64/aarch64-sve.md (@aarch64_vec_duplicate_vq_le): Use

[PATCH] doc: Document AArch64-specific asm operand modifiers

trunk? Thanks, Alex gcc/ChangeLog: * doc/extend.texi: Document AArch64 Operand Modifiers. diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index e8b5e771f7a..6ade36759ee 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -11723,6 +11723,31 @@ operand as if it were a memory refe

[PATCH v4 10/11] aarch64: Add new load/store pair fusion pass

walk. Bootstrapped/regtested as a series on aarch64-linux-gnu, OK for trunk? Thanks, Alex -- >8 -- This adds a new aarch64-specific RTL-SSA pass dedicated to forming load and store pairs (LDPs and STPs). As a motivating example for the kind of thing this improves, take the following testcase:

Re: [PATCH v4 10/11] aarch64: Add new load/store pair fusion pass

On 15/12/2023 15:34, Richard Sandiford wrote: > Alex Coplan writes: > > This is a v6 of the aarch64 load/store pair fusion pass, which > > addresses the feedback from Richard's last review here: > > > > https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640539

[PATCH] aarch64: Fix parens in aarch64_stp_reg_operand [PR113061]

result (and LRA failing to reload the constant). Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk? Thanks, Alex gcc/ChangeLog: PR target/113061 * config/aarch64/predicates.md (aarch64_stp_reg_operand): Fix parentheses to match intent. gcc/testsuite/ChangeLog

[PATCH] aarch64: Validate register operands early in ldp fusion pass [PR113062]

. This then trips the assert: gcc_assert (change->new_uses.is_valid ()); in the stp case as we aren't expecting to have (distinct) uses of mem in the candidate stores. Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk? Thanks, Alex gcc/ChangeLog: PR target/113062

Re: [PATCH] aarch64: Validate register operands early in ldp fusion pass [PR113062]

On 19/12/2023 10:15, Richard Sandiford wrote: > Alex Coplan writes: > > We were missing validation of the candidate register operands in the > > ldp/stp pass. I was relying on recog rejecting such cases when we > > formed the final pair insn, but the testcase shows t

  1   2   3   4   5   6   >