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
Hi,
The description of the REG_NOALIAS note in reg-notes.def isn't quite
right. It describes it as being attached to call insns, but it is
instead attached to a move insn receiving the return value from a call.
This can be seen by looking at the code in calls.cc:expand_call which
attaches the not
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
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
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 +
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
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
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
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
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
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
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
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
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:
extern double c[20];
double f(double x)
{
double y = x*x;
y += c[16];
y += c[17];
y += c[18];
Hi,
This v2 fixes a significant compile-time hog in the original patch
for the pass posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633355.html
Having seen a large compile-time regression when turning on the early
ldp pass, compiling 502.gcc_r from SPEC CPU 2017, I found that
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
Hi,
This patch tweaks change_insns to also call ::remove_insn to ensure the
underlying RTL insn gets removed from the insn chain in the case of a
deletion.
This avoids leaving NOTE_INSN_DELETED around after deleting insns.
For movement, the RTL insn chain is updated earlier in change_insns with
Hi,
I'd like to submit the attached three patches from Jakub for backporting to GCC
12.
These are the backports proposed at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106878#c18 i.e.:
r13-2658-g645ef01a463f15fc230e2155719c7a12cec89acf without the gimple verifier
changes.
r13-2709-g9ac9fde961
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
On 26/10/2023 16:23, Richard Sandiford wrote:
> Victor Do Nascimento writes:
> > On 10/18/23 21:39, Richard Sandiford wrote:
> >> Victor Do Nascimento writes:
> >>> Implement the aarch64 intrinsics for reading and writing system
> >>> registers with the following signatures:
> >>>
> >>> uint32_
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
Hi Ian,
On 14/09/2020 14:12, Ian Lance Taylor via Gcc-patches wrote:
> This patch to libbacktrace adds support for MiniDebugInfo, as
> requested in PR 93608.
This appears to introduce a failure in the libbacktrace testsuite
(observed on both x86 and aarch64):
../gcc/libbacktrace/../test-driver:
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
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
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
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
Hi Segher,
On 21/09/2020 18:35, Segher Boessenkool wrote:
> Hi!
>
> So, I tested this patch. The test builds Linux for all targets, and the
> number reported here is just binary size (usually a good indicator for
> combine effectiveness). C0 is the unmodified compiler, C1 is with your
> patch.
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-tune.md: Rege
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: Regenerate.
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/aarch64-t
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/aarch64-tun
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/aarch64-tun
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-tune.md: Rege
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/arm/arm-cpus.in
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
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.
* con
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/arm/arm-tables.
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/arm/arm-tables.op
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
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/arm/arm-tables.op
Hello,
This patch fixes ICEs when compiling
gcc/testsuite/gcc.target/arm/pure-code/no-literal-pool.c with
-mfp16-format=ieee -mfloat-abi=hard -march=armv8.1-m.main+mve
-mpure-code.
The existing conditions in the movsf/movdf expanders (as well as the
no_literal_pool patterns) were too restrictive,
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 you have marked th
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/change
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
CI isn't ru
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 spac
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
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
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
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
Hi,
The ldp/stp fusion pass can change the base of an access so that the two
accesses end up using a common base register. So far we have been using
adjust_address_nv to do this, but this means that we don't preserve
other properties of the mem we're replacing. It seems better to use
replace_equ
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:
> >>
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:
> > >
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 those
buil
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
Hi,
On 04/05/2022 09:59, Martin Liška wrote:
> Supports change in libsanitizer where it newly reports:
> READ of size 4 at 0xc3d4 tags: 02/01(00) (ptr/mem) in thread T0
>
> So the 'tags' contains now 3 entries compared to 2 entries.
>
> gcc/testsuite/ChangeLog:
>
> * c-c++-common/
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 12, so this version adjusts
TX_V16QI accordingly.
Bootstrapped/regtested on aarch64-linux-gnu, the only changes in t
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
On 15/02/2024 21:24, Ajit Agarwal wrote:
> Hello Richard:
>
> As per your suggestion I have divided the patch into target independent
> and target dependent for aarch64 target. I kept aarch64-ldp-fusion same
> and did not change that.
I'm not sure this was what Richard suggested doing, though.
He
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
>
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 notes
attached
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.op
This is a v3 which addresses shortcomings of the v2 patch. v2 was
posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642448.html
The main issue in v2 is that we were using the final (transformed)
patterns in combine_reg_notes instead of the initial patterns (thanks
Richard S for
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
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 change group. This is so that we can
correctly update uses of memory when inserting a new store pair insn in
the aarch64 load
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
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 that apply_changes_to_insn needed updating to ensure
that the new defs actually got inserted into the main def chain. Thi
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 allow stores
to be re-ordered w.r.t. other stores. In the ldp fusion pass, we
Hi,
For the testcase in the PR, we try to pair insns where the first has
writeback and the second uses the updated base register. This causes us
to record a hazard against the second insn, thus narrowing the move
range away from the end of the BB.
However, it isn't meaningful to record hazards a
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
Hi Andrew,
On 16/01/2024 19:29, Andrew Pinski wrote:
> So the problem here is that aarch64_ldp_reg_operand will all subreg even
> subreg of lo_sum.
> When LRA tries to fix that up, all things break. So the fix is to change the
> check to only
> allow reg and subreg of regs.
Thanks a lot for tra
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
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
While working on PR113089, I realised we where missing code to re-parent
trailing nondebug uses of the base register in the case of cancelling
writeback in the load/store pair pass. This patch fixes that.
Bootstrapped/regtested as a series on aarch64-linux-gnu (with/without
the pass enabled), OK
As the PR shows, we were missing code to update debug uses in the
load/store pair fusion pass. This patch fixes that.
Note that this patch depends on the following patch to create new uses
in RTL-SSA, submitted as part of the fixes for PR113070:
https://gcc.gnu.org/pipermail/gcc-patches/2024-Janu
Hi,
The PR shows two different cases where try_promote_writeback produces an
RTL pattern which isn't recognized. Currently this leads to an ICE, as
we assert recog success, but I think it's better just to back out of the
changes gracefully if recog fails (as we do in the main fuse_pair case).
In
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.
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
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
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
> >
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.
Hi,
Since, to the best of my knowledge, all reported regressions related to
the ldp/stp fusion pass have now been fixed, and PGO+LTO bootstrap with
--enable-languages=all is working again with the passes enabled, this
patch turns the passes back on by default, as agreed with Jakub here:
https://g
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
Hi Ajit,
On 21/01/2024 19:57, Ajit Agarwal wrote:
>
> Hello All:
>
> New pass to replace adjacent memory addresses lxv with lxvp.
> Added common infrastructure for load store fusion for
> different targets.
Thanks for this, it would be nice to see the load/store pair pass
generalized to multipl
On 25/01/2024 11:57, Andrew Pinski wrote:
> The J constraint can invoke undefined behavior due to it taking the
> negative of the ival if ival was HWI_MIN. The fix is simple as casting
> to `unsigned HOST_WIDE_INT` before doing the negative of it. This
> does that.
Thanks for doing this.
>
> Com
Hi,
The fix for PR113089 introduced range-based for loops over the
debug_insn_uses of an RTL-SSA set_info, but in the case that we reset a
debug insn, the use would get removed from the use list, and thus we
would end up using an invalidated iterator in the next iteration of the
loop. In practice
Hi,
The PR shows us ICEing due to an unrecognizable TFmode save emitted by
aarch64_process_components. The problem is that for T{I,F,D}mode we
conservatively require mems to be in range for x-register ldp/stp. That
is because (at least for TImode) it can be allocated to both GPRs and
FPRs, and i
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
-- >8 --
Hi Marek,
On 30/01/2024 13:15, Marek Polacek wrote:
> On Thu, Jan 25, 2024 at 10:13:10PM -0500, Jason Merrill wrote:
> > On 1/25/24 20:36, Marek Polacek wrote:
> > > Better version:
> > >
> > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > >
> > > -- >8 --
> > > Real-world exp
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
> >
Hi,
In PR112906 we ICE because we try to use force_reg to reload an
auto-increment address, but force_reg can't do this.
With the aim of fixing the PR by supporting reloading arbitrary
addresses in pre-RA splitters, this patch generalizes
lra-constraints.cc:emit_inc and makes it available to the
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 f
Hi,
As it stands, GCC doesn't document any public AArch64-specific operand
modifiers for use in inline asm. This patch fixes that by documenting
an initial set of public AArch64-specific operand modifiers.
Tested with make html and checking the output looks OK in a browser.
OK for trunk?
Thank
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.html
In particular this version implements the suggested changes which
greatly simplify the double list walk.
Boot
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
In r14-6603-gfcdd2757c76bf925115b8e1ba4318d6366dd6f09 I messed up the
parentheses in aarch64_stp_reg_operand, the indentation shows the
intended nesting of the conditions.
This patch fixes that.
This fixes PR113061 which shows IRA substituting (const_int 1) into a
writeback stp pattern as a resul
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 that with
-fharden-conditionals we attempt to combine two insns with asm_operands,
both containing mem rtxes. T
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
On 19/12/2023 13:38, Richard Sandiford wrote:
> Alex Coplan writes:
> > 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 rel
This is a v2 addressing Richard's feedback, v1 was posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640957.html
Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk?
Thanks,
Alex
-- >8 --
We were missing validation of the candidate register operands in the
ldp/stp pass.
As the PR shows, there was nothing to prevent the ldp/stp pass from
trying to move throwing insns, which lead to an RTL verification
failure.
This patch fixes that.
Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk?
Thanks,
Alex
gcc/ChangeLog:
PR target/113093
* config/
1 - 100 of 383 matches
Mail list logo
