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_expand_epilogue): Use TARGE
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
On 20/03/2025 14:31, Alfie Richards wrote:
> Hello,
>
> This is a cherry pick of 20385cb92cbd4a1934661ab97a162c1e25935836 which
> didn't apply cleanly
> so needed a very minor edit to for it to apply for GCC 12 and 13.
>
> Regtested and bootstrapped for gcc-13 on aarch64-linux-gnu.
>
> This app
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
>
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 code
and the code in df-problems.cc:df_lr_bb_local_compute. Specifically, they
disagree on the treatment of partial defs. For the testcase in the PR
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
&
The PR claims that pair-fusion has invalid uses of gcc_assert (such that
the pass will misbehave with --disable-checking). As noted in the
comments, in the case of the calls to restrict_movement, the only way we
can possibly depend on the side effects is if we call it with a
non-singleton move ran
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 tried to fuse
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/118320
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
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 deallocations as ordinary register updates, and so
> might move them earlier than another stack access (through a different
> base register) th
On 29/01/2025 18:46, Richard Sandiford wrote:
> As Andrew says in the bugzilla comments, this PR is about a case where
> we tried to fuse two stores of x0, one in which x0 was defined and one
> in which it was undefined. merge_access_arrays failed on the conflict,
> but the failure wasn't caught.
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 counts of various scan-dump-times tests (causing them to FAIL).
This adds #pragma
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
> >
This patch tries to make the CFG profile consistent when adding a guard
edge to skip the epilog during peeling.
The changes can be summarized as follows:
- We avoid adding the guard edge entirely if the guard condition folds
to false, otherwise the profile will become inconsistent since
the
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/
As it stands, scale_loop_profile doesn't correctly handle loops with
multiple exits. In particular, in the case where the expected niters
exceeds iteration_bound, scale_loop_profile attempts to reduce the
number of iterations with a call to scale_loop_frequencies, which
multiplies the count of eac
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/11
-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
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/2024-October/48.html
As mentioned on IRC, it will need follow-up work to fix up latent
profile issues, but that can be done during stage 3. We wi
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
Hi Alexey,
On 12/11/2024 08:18, Alexey Merzlyakov wrote:
> gcc/ChangeLog:
>
> * simplify-rtx.cc (simplify_context::simplify_unary_operation_1):
> Fix subreg mode check during zero_extend(not) -> xor optimization.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/pr117476.c: New test.
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
Hi,
This is a backport of the PR116783 fix to GCC 14. It was pre-approved here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665097.html
The only intended non-contextual difference w.r.t. the patch on trunk is
that the test no longer needs -fno-late-combine-instructions on the 14
branc
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
On 25/10/2024 10:19, Jakub Jelinek wrote:
> Hi!
>
> We have currently 3 different definitions of gcc_assert macro, one used most
> of the time (unless --disable-checking) which evaluates the condition at
> runtime and also checks it at runtime, then one for --disable-checking GCC
> 4.5+
> which l
This is a v2 of:
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663600.html
w.r.t. v1 this just implements Richard's suggestion of using safe_push as
discussed here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665097.html
Pushed to trunk after bootstrap + regtest (all languag
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
Hi,
In r15-3585-g9759f6299d9633cabac540e5c893341c708093ac I added a test which
started failing on PowerPC. The test checks that we unroll exactly one loop
three times with the following:
// { dg-final { scan-ltrans-rtl-dump-times "Unrolled loop 3 times" 1
"loop2_unroll" } }
which passes on mos
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
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 accesses really did alias.
To avoid this sort of problem, this patch avoids
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
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, so gdbhooks.py attempts to print it but chokes on the reference.
I see the following:
#1 0x
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
> >
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 vec
with vl_ptr layout, GDB would print a diagnostic like:
gdb.error: There is no member or method named m_vecpfx.
when (e.g.) any such vec occurred in a
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
libatomic/Change
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:
> > >
When adding RTL variants of the scan-ltrans-tree* functions in:
r15-3254-g3f51f0dc88ec21c1ec79df694200f10ef85915f4
I messed up the name of the underlying scan function to invoke. The
code currently attempts to invoke functions named
scan{,-not,-dem,-dem-not} but should instead be invoking
scan-dum
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 extends the
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
tree-
On 15/08/2024 13:55, Richard Sandiford wrote:
> scanltranstree.exp defines some LTO wrappers around standard
> non-LTO scanners. Four of them are cut-&-paste variants of
> one another, so this patch generates them from a single template.
> It also does the same for scan-ltrans-tree-dump-times, so
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
(Sorry for the delay in posting the re-spin, I was away last week.)
In this version we refactor to introudce a helper class (an
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
Hi!
This is a v2 patch of:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659968.html
that addresses Jakub's feedback.
FWIW, I tried to contrive a testcase where convert_from_reference kicks
in and we get called with an ANNOTATE_EXPR in maybe_convert_cond, but to
no avail. However, I did
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
On 09/08/2024 17:08, Jakub Jelinek wrote:
> On Fri, Aug 09, 2024 at 11:01:22AM -0400, Jason Merrill wrote:
> > > The CLEANUP_POINT_EXPR gets added by the following call chain:
> > >
> > > finish_while_stmt_cond
> > > -> maybe_convert_cond
> > > -> condition_conversion
> > > -> fold_build_cle
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
Together with the preparatory compiler patches, this patch restores
unrolling in std::__find_if, but this time relying on the compiler to do
it by using:
#pragma GCC unroll 4
which should restore the majority of the regression relative to the
hand-unrolled version while still being vectorizable
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
I noticed while working on a test that uses LTO and requests a dump
file, that we are failing to cleanup ltrans dump files in the testsuite.
E.g. the test I was working on compiles with -flto
-fdump-rtl-loop2_unroll, and we end up with the following file:
./gcc/testsuite/g++/pr116140.ltrans0.ltra
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-
Hi,
This adds a new GDB parameter 'gcc-dot-cmd' which allows the user to
configure the command used to render the CFG within dot-fn.
E.g. with this patch the user can change their dot viewer like so:
(gdb) show gcc-dot-cmd
The current value of 'gcc-dot-cmd' is "dot -Tx11".
(gdb) set gcc-dot-cmd
This extends GCC's GDB hooks to attempt invoking the user-defined
command "on-gcc-hooks-load". The idea is that users can define the
command in their .gdbinit to override the default values of parameters
defined by GCC's GDB extensions.
For example, together with the previous patch, I can add the
Hi Claudio,
I've left a couple of small comments below.
On 22/07/2024 09:30, Claudio Bantaloukas wrote:
>
> Unlike most system registers, fpmr can be heavily written to in code that
> exercises the fp8 functionality. That is because every fp8 instrinsic call
> can potentially change the value of
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 wraps the fir
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
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
> > > To: gcc-patches@gcc.gnu.org
> > > Cc: nd ; rguent...@suse.de; j...@ventanamicro.com
> > > Subject:
Hi Richard,
I had a quick look through the patch and noticed a couple of minor typos.
Otherwise looks like a nice cleanup!
On 20/06/2024 14:34, Richard Sandiford wrote:
> rtl-ssa has routines for scanning forwards or backwards for something
> under the control of an exclusion set. These searches
Hi Ajit,
You need to remove the header dependencies that are no longer required
for aarch64-ldp-fusion.o in t-aarch64 (not forgetting to update the
ChangeLog). A few other minor nits below.
LGTM with those changes, but you'll need Richard S to approve.
Thanks a lot for doing this.
On 22/05/202
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
> to support multiple targets.
>
> C
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 dependent code.
>
> Target independ
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.
Hi Ajit,
Thanks a lot for working through the review feedback.
The patch LGTM with the two minor suggested changes below. I can't
approve the patch, though, so you'll need an OK from Richard S.
Also, I'm not sure if it makes sense to apply the patch in isolation, it
might make more sense to onl
Hi Ajit,
Please can you pay careful attention to the review comments?
In particular, you have ignored my comment about changing the access of
member functions in ldp_bb_info several times now (on at least three
patch reviews).
Likewise on multiple occasions you've only partially implemented a pi
Hi Ajit,
Why did you send three mails for this revision of the patch? If you're
going to send a new revision of the patch you should increment the
version number and outline the changes / reasons for the new revision.
Mostly the comments below are just style nits and things you missed from
the l
Hi Ajit,
Sorry for the long delay in reviewing this.
This is really getting there now. I've left a few more comments below.
Apart from minor style things, the main remaining issues are mostly
around comments. It's important to have good clear comments for
functions with the parameters (and ret
1 - 100 of 382 matches
Mail list logo
