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
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.
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
Ping^8 for patches 2-4:
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672677.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672678.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672679.html
On 21/03/2025 10:04, Alex Coplan wrote:
> Ping^7
>
> On 06/0
Ping^7
On 06/03/2025 10:48, Alex Coplan wrote:
> Ping^6
>
> On 19/02/2025 12:15, Alex Coplan wrote:
> > Ping^5 for patches 2-4:
> > https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672677.html
> > https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672678.h
On 21/03/2025 14:06, Matthew Malcomson wrote:
> On 3/20/25 15:03, Alex Coplan wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On 20/03/2025 14:31, Alfie Richards wrote:
> > > Hello,
> > >
> > > This is a c
On 20/03/2025 14:31, Alfie Richards wrote:
> From: Andrew Carlotti
>
> gcc/ChangeLog:
>
I think you need to add:
PR target/119372
here, so that the backport commits get tracked in bugzilla.
Thanks,
Alex
> * config/aarch64/aarch64.cc
> (aarch64_exp
On 09/02/2024 15:32, Alex Coplan wrote:
> 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' c
ax them
(r13-100-g3771486daa1e904ceae6f3e135b28e58af33849). I think that patch
needs backporting to the GCC 12 branch, which I requested here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645278.html but
that backport request was never ACKed. I still think we should backport
it.
Alex
&g
On 11/03/2025 17:39, Richard Sandiford wrote:
> Alex Coplan writes:
> > Hi,
> >
> > The PR shows us spinning in dce.cc:fast_dce at the start of combine.
> > This spinning appears to be because of a disagreement between the fast_dce
>
ce
for this testcase.
Bootstrapped/regtested on aarch64-linux-gnu, arm-linux-gnueabihf, and
x86_64-linux-gnu: no regressions. I also checked that this is netural
for SPEC CPU 2017 on Graviton 3. OK for trunk? If so, what about
backports?
Thanks,
Alex
gcc/ChangeLog:
PR rtl-optimizat
Ping^6
On 19/02/2025 12:15, Alex Coplan wrote:
> Ping^5 for patches 2-4:
> https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672677.html
> https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672678.html
> https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672679.html
&
having the calls wrapped in
asserts is problematic here.
Tested on aarch64-linux-gnu, pushed to trunk.
Alex
gcc/ChangeLog:
PR rtl-optimization/114492
* pair-fusion.cc (pair_fusion_bb_info::fuse_pair): Check for singleton
move range before calling restrict_movement
This is a backport of Richard's fix for PR118320 to GCC 14 (squashed
together with my follow-up tweak of the dump message). Pushed to
releases/gcc-14 after testing on aarch64-linux-gnu.
Thanks,
Alex
-- >8 --
As Andrew says in the bugzilla comments, this PR is about a case where
we
On 17/02/2025 14:28, Alex Coplan wrote:
> Hi,
>
> After the recent alignment peeling enhancements in the vectorizer we
> started vectorizing the "checking" loops (that check for the right
> result) in gcc.target/powerpc/vsx-vectorize-*.c, thus skewing the
> expected
Ping^5 for patches 2-4:
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672677.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672678.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672679.html
On 12/02/2025 11:20, Alex Coplan wrote:
> Ping
>
> On 03/02/2
As discussed in
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675978.html
this tweaks the dump messasge added with the fix for PR118320 since it doesn't
just apply to load pairs.
Tested on aarch64-linux-gnu, pushed to trunk.
Alex
gcc/ChangeLog:
PR rtl-optimization/1
On 17/02/2025 16:15, Richard Sandiford wrote:
> Alex Coplan writes:
> > Hi Richard,
> >
> > On 29/01/2025 16:44, Richard Sandiford wrote:
> >> The PR showed two issues with pair-fusion. The first is that the pass
> >> treated stack pointer deallocatio
t;uid ());
> - rtx_insn *rti = change->insn ()->rtl ();
> - validate_change (rti, &PATTERN (rti), gen_tombstone (), true);
> - validate_change (rti, ®_NOTES (rti), NULL_RTX, true);
> - change->new_uses = use_array (nullptr, 0);
> +
{
> + if (dump_file)
> + fprintf (dump_file,
> + " load pair: i%d and i%d use different definiitions of"
... how do we know that this is a load pair here? Could this not in
theory trigger for stores too?
Thanks,
Alex
> + " th
ds #pragma GCC novector above the relevant loops to prevent them
from being vectorized, thereby fixing the test failures.
Tested with RUNTESTFLAGS="powerpc.exp=vsx-vectorize-*.c" on
powerpc64le-linux-gnu (cfarm29): no FAILs observed wtih the patch
applied. OK for trunk?
Thanks,
On 05/02/2025 08:05, Tamar Christina wrote:
>
>
> > -Original Message-
> > From: Jan Hubicka
> > Sent: Tuesday, February 4, 2025 4:25 PM
> > To: Alex Coplan
> > Cc: gcc-patches@gcc.gnu.org; Richard Biener ; Tamar
> > Christina
> > Su
Ping
On 03/02/2025 14:46, Tamar Christina wrote:
> Ping
>
> > -Original Message-
> > From: Tamar Christina
> > Sent: Friday, January 24, 2025 9:18 AM
> > To: Alex Coplan ; gcc-patches@gcc.gnu.org
> > Cc: Richard Biener ; Jan Hubicka
> >
for trunk?
Thanks,
Alex
gcc/ChangeLog:
PR tree-optimization/117790
* tree-vect-loop-manip.cc (vect_do_peeling): Attempt to maintain
consistency of the CFG profile when adding an epilog skip edge.
gcc/testsuite/ChangeLog:
PR tree-optimization/117790
* g
This adjusts scale_profile_for_vect_loop to DTRT for loops with multiple exits,
namely using scale_loop_profile_hold_exit_counts instead and scaling the
expected niters by 1 / VF.
Tested as a series on aarch64-linux-gnu, arm-linux-gnueabihf, and
x86_64-linux-gnu. OK for trunk?
Thanks,
Alex
gcc
-linux-gnu, and arm-linux-gnueabihf. OK for trunk?
Thanks,
Alex
gcc/ChangeLog:
PR tree-optimization/117790
* cfgloopmanip.cc (can_flow_scale_loop_freqs_p): New.
(flow_scale_loop_freqs): New.
(scale_loop_freqs_with_exit_counts): New.
(scale_loop_freqs_h
This adds missing code to correctly set the counts of the exit blocks we
create when building the CFG for a vectorized early break loop.
Tested as a series on aarch64-linux-gnu, arm-linux-gnueabihf, and
x86_64-linux-gnu. OK for trunk?
Thanks,
Alex
gcc/ChangeLog:
PR tree-optimization
-gnu, arm-linux-gnueabihf, and
x86_64-linux-gnu.
Alex Coplan (4):
vect: Set counts of early break exit blocks correctly [PR117790]
cfgloopmanip: Add infrastructure for scaling of multi-exit loops [PR117790]
vect: Ensure profile consistency when adding epilog guard [PR117790]
vect: Fix
On 29/09/2024 09:35, Jeff Law wrote:
>
>
> On 9/23/24 4:33 AM, Alex Coplan wrote:
> > On 30/08/2024 18:11, Alex Coplan wrote:
> > > Hi,
> > >
> > > vec.h has this method:
> > >
> > >template
> > >inlin
On 21/11/2024 10:02, Richard Biener wrote:
> On Fri, 15 Nov 2024, Alex Coplan wrote:
>
> > Hi,
> >
> > This is a v2 which hopefully addresses the feedback for v1 of the 1/5
> > patch, originally posted here:
> > https://gcc.gnu.org/pipermail/gcc-patches/
On 19/11/2024 20:12, Richard Sandiford wrote:
> Alex Coplan writes:
> > On 19/11/2024 17:02, Richard Sandiford wrote:
> >> Sorry for the slow review. Finally catching up on backlog.
> >>
> >> Richard Biener writes:
> >> > On Mon, 28 Oct 2024, Ale
On 19/11/2024 17:02, Richard Sandiford wrote:
> Sorry for the slow review. Finally catching up on backlog.
>
> Richard Biener writes:
> > On Mon, 28 Oct 2024, Alex Coplan wrote:
> >
> >> This allows us to vectorize more loops with early exits by forcing
> >
On 29/10/2024 13:41, Richard Biener wrote:
> On Mon, 28 Oct 2024, Alex Coplan wrote:
>
> > From: Tamar Christina
> >
> > The alignment peeling changes exposed a latent missing dominator update
> > with early break vectorization, specifically when inserting the v
will also need
a simple (hopefully obvious, even) follow-up patch to fix expectations
for various tests (since we now vectorize loops which we previously
couldn't).
OK for trunk?
Thanks,
Alex
-- >8 --
This allows us to vectorize more loops with early exits by forcing
peeling for alignment
On 29/10/2024 13:45, Richard Biener wrote:
> On Tue, 29 Oct 2024, Richard Biener wrote:
>
> > On Mon, 28 Oct 2024, Alex Coplan wrote:
> >
> > > Currently we only cost gconds for the vector loop while we omit costing
> > > them when analyzing the scalar loop
On 12/11/2024 10:56, Jeff Law wrote:
>
>
> On 11/12/24 4:46 AM, Alex Coplan wrote:
> > Hi Alexey,
> >
> > On 12/11/2024 08:18, Alexey Merzlyakov wrote:
> > > gcc/ChangeLog:
> > >
> > > * simplify-rtx.cc (simplify_context::simplify_un
/gcc.dg/pr117476.c
I think it might be better to put the test in gcc.c-torture/execute,
then it will automatically get run with the various torture options
and you should be able to drop both the dejagnu directives.
Thanks,
Alex
> @@ -0,0 +1,12 @@
> +/* PR rtl-optimization/117476 */
> +/*
Hi Ajit,
Sorry for not reviewing this sooner. For a while I thought this patch
was with Richard S to look at the rtl-ssa changes, but we've now agreed
that I should take a look at it.
I noticed that this breaks the build on aarch64. I suspect you got an
email from the Linaro CI about this? You
branch (I verified that it failed there without the change to
aarch64-ldp-fusion.cc).
Bootstrapped/regtested on aarch64-linux-gnu (all languages), no
regressions. Pushed to the 14 branch.
Thanks,
Alex
---
As the PR shows, pair fusion was tricking memory_modified_in_insn_p into
returning false when
On 29/10/2024 15:53, Alex Coplan wrote:
> On 29/10/2024 13:39, Richard Biener wrote:
> > On Mon, 28 Oct 2024, Alex Coplan wrote:
> >
> > > This allows us to vectorize more loops with early exits by forcing
> > > peeling for alignment to make sure that we're
On 29/10/2024 13:39, Richard Biener wrote:
> On Mon, 28 Oct 2024, Alex Coplan wrote:
>
> > This allows us to vectorize more loops with early exits by forcing
> > peeling for alignment to make sure that we're guaranteed to be able to
> > safely read an entire vector
This allows us to vectorize more loops with early exits by forcing
peeling for alignment to make sure that we're guaranteed to be able to
safely read an entire vector iteration without crossing a page boundary.
To make this work for VLA architectures we have to allow compile-time
non-constant targ
Currently we only cost gconds for the vector loop while we omit costing
them when analyzing the scalar loop; this unfairly penalizes the vector
loop in the case of loops with early exits.
This (together with the previous patches) enables us to vectorize
std::find with 64-bit element sizes.
gcc/Ch
This fixes a latent wrong code issue whereby vect_do_peeling determined
the wrong condition for inserting the vector skip guard. Specifically
in the case where the loop niters are unknown at compile time we used to
check:
!LOOP_REQUIRES_VERSIONING (loop_vinfo)
but LOOP_REQUIRES_VERSIONING is t
For loops with LOOP_VINFO_EARLY_BREAKS_VECT_PEELED we should always
enter the scalar epilogue, so avoid emitting a guard on entry to the
epilogue.
gcc/ChangeLog:
* tree-vect-loop-manip.cc (vect_do_peeling): Avoid emitting an
epilogue guard for inverted early-exit loops.
---
gcc/t
-Authored-By: Alex Coplan
---
.../g++.dg/vect/vect-early-break_6.cc | 25 +++
gcc/tree-vect-loop-manip.cc | 24 ++
2 files changed, 49 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/vect/vect-early-break_6.cc
diff --git a/gcc/testsuite/g
le exits (provided we want to hold the counts along exit
edges fixed). I have a patch that addresses this, but it probably makes
most sense to post it once all the profile issues are fixed.
I would appreciate any feedback on the patches at this stage.
Thanks,
Alex
Alex Coplan (4):
vect: Force al
t;caller = caller;
> --- gcc/pair-fusion.cc.jj 2024-10-22 17:09:09.372091098 +0200
> +++ gcc/pair-fusion.cc2024-10-24 11:13:07.023744574 +0200
> @@ -1962,7 +1962,10 @@ pair_fusion_bb_info::fuse_pair (bool loa
>
>auto ignore = ignore_changing_insns (changes);
>fo
(all languages) on aarch64-linux-gnu.
I'll work on a backport to 14 if there's no fallout after a week or so.
Thanks,
Alex
-- >8 --
As the PR shows, pair-fusion was tricking memory_modified_in_insn_p into
returning false when a common base register (in this case, x1) was
modified betwe
On 18/10/2024 17:45, Richard Sandiford wrote:
> Alex Coplan writes:
> > On 11/10/2024 14:30, Richard Biener wrote:
> >> On Fri, 11 Oct 2024, Richard Sandiford wrote:
> >>
> >> > Alex Coplan writes:
> >> > > Hi,
>
On 11/10/2024 14:30, Richard Biener wrote:
> On Fri, 11 Oct 2024, Richard Sandiford wrote:
>
> > Alex Coplan writes:
> > > Hi,
> > >
> > > As the PR shows, pair-fusion was tricking memory_modified_in_insn_p into
> > > returning false wh
Of course I forgot to actually attach the patch, now attached :)
On 18/10/2024 11:09, Alex Coplan wrote:
> Pushed to trunk.
>
> ChangeLog:
>
> * MAINTAINERS (CPU Port Maintainers): Add myself as aarch64 ldp/stp
> maintainer.
> (Various Maintainers): Add
Pushed to trunk.
ChangeLog:
* MAINTAINERS (CPU Port Maintainers): Add myself as aarch64 ldp/stp
maintainer.
(Various Maintainers): Add myself as pair fusion maintainer.
On 23/09/2024 11:31, Alex Coplan wrote:
> Hi,
>
> As the PR shows, pair-fusion was tricking memory_modified_in_insn_p into
> returning false when a common base register (in this case, x1) was
> modified between the mem and the store insn. This lead to wrong code as
> the a
ore explicitly tries to block the unrolling in main with an
appropriate #pragma.
I've checked that the test now passes on power (on cfarm29) and aarch64. I also
checked that reverting the lto-streamer-{in,out}.cc changes still causes the
test to fail (on aarch64).
OK for trunk?
Thanks,
Alex
On 30/08/2024 18:11, Alex Coplan wrote:
> Hi,
>
> vec.h has this method:
>
> template
> inline T *
> vec_safe_push (vec *&v, const T &obj CXX_MEM_STAT_INFO)
>
> where v is a reference to a pointer to vec. This matches the regex for
> VecPrinter, s
bootstrap and LTO+PGO bootstrap). OK for trunk?
Thanks,
Alex
gcc/ChangeLog:
PR rtl-optimization/116783
* pair-fusion.cc (def_walker::cand_addr_uses): New.
(def_walker::def_walker): Add parameter for candidate address
uses.
(def_walker::alias_conflict_p): Declare
On 10/09/2024 10:29, Jason Merrill wrote:
> On 9/10/24 6:10 AM, Alex Coplan wrote:
> > On 27/08/2024 10:55, Alex Coplan wrote:
> > > Hi,
> > >
> > > This is a v3 that hopefully addresses the feedback from both Jason and
> > > Jakub. v2 was posted
On 27/08/2024 10:55, Alex Coplan wrote:
> Hi,
>
> This is a v3 that hopefully addresses the feedback from both Jason and
> Jakub. v2 was posted here:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660191.html
Gentle ping on this C++ patch:
https://gcc.gnu.org/pipermail/g
matching a plain vec<...> struct and fix the member
functions to handle those properly.
Any thoughts on that, Dave? Is the current patch OK as an intermediate
step (manually tested by verifying both a vec*& and vec* print OK)?
Thanks,
Alex
gcc/ChangeLog:
* gdbhook
On 30/08/2024 10:12, David Malcolm wrote:
> On Fri, 2024-08-30 at 12:08 +0100, Alex Coplan wrote:
> > Hi,
> >
> > As it stands, the pretty printing of GCC's vecs by gdbhooks.py only
> > handles vectors with vl_embed layout. As such, when encountering a
> >
in a backtrace. This patch extends
VecPrinter.children to also handle vl_ptr vectors.
Manually tested by verifying that vl_embed vectors still print correctly
and empty vl_ptr vectors no longer trigger errors.
OK for trunk?
Thanks,
Alex
diff --git a/gcc/gdbhooks.py b/gcc/gdbhooks.py
Hi,
Since r15-3254-g3f51f0dc88ec21c1ec79df694200f10ef85915f4
added scan-ltrans-rtl* variants to scanltranstree.exp, it no longer
makes sense to have "tree" in the name. This renames the file
accordingly and updates users.
Tested on aarch64-linux-gnu, OK for trunk?
Thanks,
Alex
On 28/08/2024 18:34, Andrew Pinski wrote:
> On Wed, Aug 28, 2024 at 4:05 AM Alex Coplan wrote:
> >
> > On 28/08/2024 11:53, Richard Sandiford wrote:
> > > Alex Coplan writes:
> > > > Hi,
> > > >
> > > > This is a v2 of:
> > >
unctions, and I only spot-checked a test using one of those functions.
Apologies for the breakage.
Tested on aarch64. No regressions, and verified that the ERROR in
gcc.dg/ipa/ipa-icf-38.c goes away. Pushing to trunk as obvious.
Alex
gcc/testsuite/ChangeLog:
PR testsuite/11652
On 28/08/2024 11:53, Richard Sandiford wrote:
> Alex Coplan writes:
> > Hi,
> >
> > This is a v2 of:
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659966.html
> > which is rebased on top of Richard S's patch to reduce the cut-and-paste in
> >
Hi,
This is a v2 of:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659966.html
which is rebased on top of Richard S's patch to reduce the cut-and-paste in
scanltranstree.exp (thanks again for doing that).
Tested on aarch64-linux-gnu, OK for trunk?
Thanks,
Alex
-- >8 --
This
This is a v2 of:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659969.html
this version just streams the flag as requested.
Bootstrapped/tested as a series on aarch64-linux-gnu (both with and
without LTO), OK for trunk?
Thanks,
Alex
-- >8 --
When #pragma GCC unroll is processed in
t
linux-gnu?
Thanks for doing this. I had the feeling when trying to add the RTL
variants of the scanners that the code needed refactoring, but my Tcl
skills really weren't up to the job. I learned a lot about Tcl by
trying to make sense of this patch.
I'll try adding the RTL varian
assumptions about the specific changes made
in maybe_convert_cond.
Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk?
Thanks,
Alex
-- >8 --
For the testcase added with this patch, we would end up losing the:
#pragma GCC unroll 4
and emitting "warning: ignoring loop annotation
On 16/08/2024 12:47, Jakub Jelinek wrote:
> On Fri, Aug 16, 2024 at 11:38:03AM +0100, Alex Coplan wrote:
> > Looking at the calls to build3 (ANNOTATE_EXPR, ...) in cp/semantics.cc,
> > it looks like the other two operands of ANNOTATE_EXPRs are only ever
> > INTEGER_C
On 15/08/2024 16:55, Jason Merrill wrote:
> On 8/12/24 1:55 PM, Alex Coplan wrote:
> > Hi!
> >
> > This is a v2 patch of:
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659968.html
> > that addresses Jakub's feedback.
> >
&g
I'm happy to be persuaded to do otherwise
by C++ maintainers :)
Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk?
Thanks,
Alex
-- >8 --
For the testcase added with this patch, we would end up losing the:
#pragma GCC unroll 4
and emitting "warning: ignoring loop annotatio
On 09/08/2024 17:56, Jakub Jelinek wrote:
> On Fri, Aug 09, 2024 at 04:46:55PM +0100, Alex Coplan wrote:
> > On 09/08/2024 17:34, Jakub Jelinek wrote:
> > > On Fri, Aug 09, 2024 at 04:21:14PM +0100, Alex Coplan wrote:
> > > > Hmm, good spot, I didn't realis
On 09/08/2024 17:34, Jakub Jelinek wrote:
> On Fri, Aug 09, 2024 at 04:21:14PM +0100, Alex Coplan wrote:
> > Hmm, good spot, I didn't realise that convert_from_reference could
> > change the type of the condition like this.
> >
> > In that case I suppose the on
realise that convert_from_reference could
change the type of the condition like this.
In that case I suppose the only thing to do is to construct a stack of
ANNOTATE_EXPRs on the way down and re-build the expressions (taking the
type of the inner expression, starting with the cond) on the way back
up.
I'll try something along those lines, then (unless there are further
comments suggesting otherwise!)
Thanks,
Alex
>
> Jakub
>
On 09/08/2024 13:12, Richard Biener wrote:
>
>
> > Am 09.08.2024 um 11:30 schrieb Alex Coplan :
> >
> > When #pragma GCC unroll is processed in
> > tree-cfg.cc:replace_loop_annotate_in_block, we set both the loop->unroll
> > field (which is currently s
When #pragma GCC unroll is processed in
tree-cfg.cc:replace_loop_annotate_in_block, we set both the loop->unroll
field (which is currently streamed out and back in during LTO) but also
the cfun->has_unroll flag.
cfun->has_unroll, however, is not currently streamed during LTO, so this
patch attempt
vectorizable with WIP alignment
peeling enhancements.
On Neoverse V1 with LTO, this reduces the regression in xalancbmk (from
SPEC CPU 2017) from 5.8% to 1.7% (restoring ~71% of the lost
performance).
Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk?
Thanks,
Alex
libstdc++-v3/ChangeLog
For the testcase added with this patch, we would end up losing the:
#pragma GCC unroll 4
and emitting "warning: ignoring loop annotation". That warning comes
from tree-cfg.cc:replace_loop_annotate, and means that we failed to
process the ANNOTATE_EXPR in tree-cfg.cc:replace_loop_annotate_in_bl
cted for cleaning up such
dumpfiles to also match dumpfiles with the above form.
Running the testsuite before/after this patch shows the number of files in
gcc/testsuite (in the build dir) with "ltrans" in the name goes from 1416 to 62
on aarch64.
No regressions on aarch64-linux-gnu, OK
This extends the scan-ltrans-tree* helpers to create RTL variants. This
is needed to check the behaviour of an RTL pass under LTO.
In particular it's used by a later patch in the series to check that
RTL unrolling is applied under LTO.
Tested as a series on aarch64-linux-gnu, OK for trunk?
gcc/
71.11%|
+---+---+---+
Bootstrapped/regtested as a series on aarch64-linux-gnu, no regressions.
Alex Coplan (5):
cp: Ensure ANNOTATE_EXPRs remain outermost expressions in conditions
[PR116140]
testsuite: Add scan-ltrans-rtl for use in dg-
.gdbinit.
Manually tested by debugging an x86 -> aarch64 cross, changing the
parameter, and invoking dot-fn.
OK to install?
Thanks,
Alex
gcc/ChangeLog:
* gdbhooks.py (GCCDotCmd): New.
(gcc_dot_cmd): New. Use it ...
(DotFn.invoke): ... here.
iff --git a/gcc/gd
ny GDB experts if there's a better way of managing configuration
like this.
Tested by invoking dot-fn with/without the above fragment in my .gdbinit
and observing the change in dot renderer.
OK to install?
Thanks,
Alex
gcc/ChangeLog:
* gdbhooks.py: Add attempted call to "on-g
_gp, nosimd ] fmov\t%s0, %w1
> [w, w; neon_dup , simd ] dup\t%0, %1.[0]
> [w, w; neon_dup , nosimd ] fmov\t%s0, %s1
> + [Umv, r ; mrs, * ] msr\t%0, %x1
> + [r, Umv ; mrs, * ] mrs\t%x0, %
This is a v2 patch which implements richi's feedback.
OK if it survives bootstrap on aarch64?
Thanks,
Alex
-- >8 --
This adds debug functions to dump the dominator tree in dot format.
There are two overloads: one which takes a FILE * and another which
takes a const char *fname and w
On 05/07/2024 09:59, Richard Biener wrote:
> On Fri, 5 Jul 2024, Alex Coplan wrote:
>
> > Hi,
> >
> > This adds a debug function to dump the dominator tree in dot/graphviz
> > format. The idea is that the function can be called in GDB, the output
> > c
Hi,
This adds a debug function to dump the dominator tree in dot/graphviz
format. The idea is that the function can be called in GDB, the output
copy/pasted into a .dot file and then rendered using graphviz.
Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk?
Thanks,
Alex
gcc/ChangeLog
On 02/07/2024 13:41, Richard Biener wrote:
> On Tue, 2 Jul 2024, Alex Coplan wrote:
>
> > On 02/07/2024 10:46, Alex Coplan wrote:
> > > On 02/07/2024 10:01, Richard Biener wrote:
> > > > On Mon, 1 Jul 2024, Tamar Christina wrote:
> > > >
> >
On 02/07/2024 10:46, Alex Coplan wrote:
> On 02/07/2024 10:01, Richard Biener wrote:
> > On Mon, 1 Jul 2024, Tamar Christina wrote:
> >
> > > > -Original Message-
> > > > From: Tamar Christina
> > > > Sent: Monday, July 1, 2024 9:14 PM
if (maybe_eq (div, 0))
> > > + {
> > > + *mult = 1;
> > > + return true;
> > > + }
> > > +
> >
> > Note, I also tested known_eq here, and also no regression on what I can
> > test.
> > I picked maybe_eq since that's wh
HANGE and I are placed in a valid
> order.
> + // Use IGNORE to guide this process, where IGNORE is an object that
> + // provides the same interface as ignore_nothing.
> + //
> + // That is, when determining whether REGNO is live, ignore accesses made
> + // by
22/05/2024 00:16, Ajit Agarwal wrote:
> Hello Alex/Richard:
>
> All comments are addressed.
>
> Move pair fusion pass from aarch64-ldp-fusion.cc to middle-end
> to support multiple targets.
>
> Common infrastructure of load store pair fusion is divided into
> target indep
Hi Ajit,
I've left some more comments below. It's getting there now, thanks for
your patience.
On 21/05/2024 20:32, Ajit Agarwal wrote:
> Hello Alex/Richard:
>
> All comments are addressed.
>
> Move pair fusion pass from aarch64-ldp-fusion.cc to middle-end
>
On 20/05/2024 21:50, Ajit Agarwal wrote:
> Hello Alex/Richard:
>
> Move pair fusion pass from aarch64-ldp-fusion.cc to middle-end
> to support multiple targets.
>
> Common infrastructure of load store pair fusion is divided into
> target independent and target depend
On 21/05/2024 16:02, Ajit Agarwal wrote:
> Hello Alex:
>
> On 21/05/24 1:16 am, Alex Coplan wrote:
> > On 20/05/2024 18:44, Alex Coplan wrote:
> >> Hi Ajit,
> >>
> >> On 20/05/2024 21:50, Ajit Agarwal wrote:
> >>> Hello Alex/Richard:
> >
On 20/05/2024 18:44, Alex Coplan wrote:
> Hi Ajit,
>
> On 20/05/2024 21:50, Ajit Agarwal wrote:
> > Hello Alex/Richard:
> >
> > Move pair fusion pass from aarch64-ldp-fusion.cc to middle-end
> > to support multiple targets.
> >
> > Common infrastruct
Hi Ajit,
On 17/05/2024 18:05, Ajit Agarwal wrote:
> Hello Alex:
>
> On 16/05/24 10:21 pm, Alex Coplan wrote:
> > Hi Ajit,
> >
> > Thanks a lot for working through the review feedback.
> >
>
> Thanks a lot for reviewing the code and approving the patch.
to a .cc file in the
middle-end.
I'll let Richard S make the final judgement on that. I don't really
mind either way.
On 15/05/2024 15:06, Ajit Agarwal wrote:
> Hello Alex/Richard:
>
> All review comments are addressed.
>
> Common infrastructure of load store pair fu
1 - 100 of 507 matches
Mail list logo
