As the PR shows, the fix in
r14-6916-g057dc349021660c40699fb5c98fd9cac8e168653 was not complete.
That fix was enough to stop us trying to move throwing accesses above
nondebug insns, but due to this code in try_fuse_pair:
// Placement strategy: push loads down and pull stores up, this should
/
Hi,
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 needed to attach CFI notes to all frame-related p
Hi,
This is a v2 of:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637612.html
v1 was approved as-is, but this version pulls out the test into a helper
function which is used by later patches in the series.
Bootstrapped/regtested as a series on aarch64-linux-gnu, OK for trunk?
Thanks
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
I'll reply inline to address specific comments.
Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk?
Thanks,
Alex
-- >8 --
This patch overha
Thanks for the review, I've posted a v2 here which addresses this feedback:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639361.html
On 21/11/2023 16:04, Richard Sandiford wrote:
> Alex Coplan writes:
> > This patch overhauls the load/store pair patterns with two main go
Hi,
This is a v2 patch which implements the requested changes from the
previous review here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637642.html
the patch was pre-approved with those changes, but this patch
additionally makes use of the new aarch64_const_zero_rtx_p predicate in
a
Hi,
This is a v4 of the aarch64 load/store pair fusion pass.
This addresses feedback from the review of v3 here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637756.html
I've attached the incremental change in reply to the review above.
Bootstrapped/regtested as a series on aarch64-l
Hi,
This is a v3 patch which is rebased on top of the SME changes.
Otherwise it is the same as v2, posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639367.html
Bootstrapped/regtested as a series on aarch64-linux-gnu, OK for trunk?
Thanks,
Alex
-- >8 --
Thus far the writeba
Hi,
This is a v3, rebased on top of the SME changes. v2 is here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639361.html
Bootstrapped/regtested as a series on aarch64-linux-gnu, OK for trunk?
Thanks,
Alex
-- >8 --
This patch overhauls the load/store pair patterns with two main goa
Hi,
This is a v5 of the aarch64 load/store pair fusion pass,
rebased on top of the SME changes. v4 is here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639404.html
There are no changes to the pass itself since v4, this is just a rebase.
Bootstrapped/regtested as a series on aarch64-l
.
Thanks,
Alex
Alex Coplan (11):
rtl-ssa: Support for inserting new insns
rtl-ssa: Add some helpers for removing accesses
aarch64, testsuite: Fix up auto-init-padding tests
aarch64, testsuite: Allow ldp/stp on SVE regs with -msve-vector-bits=128
aarch64, testsuite: Fix up pr103147-10
N.B. this is just a rebased (but otherwise unchanged) version of the
same patch already posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633348.html
this is the only unreviewed dependency from the previous series, so it
seemed easier just to re-post it (not least to appease the
This adds some helpers to access-utils.h for removing accesses from an
access_array. This is needed by the upcoming aarch64 load/store pair
fusion pass.
Bootstrapped/regtested as a series on aarch64-linux-gnu, OK for trunk?
gcc/ChangeLog:
* rtl-ssa/access-utils.h (filter_accesses): New.
The tests currently depending on memcpy lowering forming stps at -O0,
but we no longer want to form stps during memcpy lowering, but instead
in the load/store pair fusion pass.
This patch therefore tweaks affected tests to enable optimizations
(-O1), and adjusts the tests to avoid parts of the str
Later patches in the series allow ldp and stp to use SVE modes if
-msve-vector-bits=128 is provided. This patch therefore adjusts tests
that pass -msve-vector-bits=128 to allow ldp/stp to save/restore SVE
registers.
OK for trunk?
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/pcs/sta
For the ret function, allow the loads to be emitted in either order in
the codegen. The order gets inverted with the new load/store pair pass.
OK for trunk?
gcc/testsuite/ChangeLog:
* g++.target/aarch64/pr103147-10.C (ret): Allow loads in either order.
* gcc.target/aarch64/pr103
This adjusts aarch64_print_operand to recognize zero rtxes in modes other than
VOIDmode. This allows us to use xzr/wzr for zero vectors, for example.
Bootstrapped/regtested as a series on aarch64-linux-gnu, OK for trunk?
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_print_operand)
Later patches allow using SVE modes in ldp/stp with -msve-vector-bits=128,
so we need to make sure that we don't use SVE addressing modes when
printing the address for the ldp/stp.
This patch does that.
Bootstrapped/regtested as a series on aarch64-linux-gnu, OK for trunk?
gcc/ChangeLog:
Thus far the writeback forms of ldp/stp have been exclusively used in
prologue and epilogue code for saving/restoring of registers to/from the
stack.
As such, forms of ldp/stp that weren't needed for prologue/epilogue code
weren't supported by the aarch64 backend. This patch generalizes the
load/
This patch overhauls the load/store pair patterns with two main goals:
1. Fixing a correctness issue (the current patterns are not RA-friendly).
2. Allowing more flexibility in which operand modes are supported, and which
combinations of modes are allowed in the two arms of the load/store pair,
This is a v3 of the aarch64 load/store pair fusion pass.
v2 was posted here:
- https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633601.html
The main changes since v2 are as follows:
We now handle writeback opportunities as well. E.g. for this testcase:
void foo (long *p, long *q, long x,
This patch adjusts the mem{cpy,set} expansion in the aarch64 backend to use
individual loads/stores instead of ldp/stp at expand time. The idea is to rely
on the ldp fusion pass to fuse the accesses together later in the RTL pipeline.
The earlier parts of the RTL pipeline should be able to do a b
Hi,
This is a v5 patch to address Marek's feedback here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635157.html
I also implemented Jason's suggestion to use constexpr for the tables
from this review:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634484.html
I'll attach the
On 03/11/2023 12:19, Marek Polacek wrote:
> On Wed, Sep 27, 2023 at 03:27:30PM +0100, 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
> >
>
On 21/11/2023 11:51, Richard Sandiford wrote:
> Alex Coplan writes:
> > N.B. this is just a rebased (but otherwise unchanged) version of the
> > same patch already posted here:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633348.html
> >
Hi,
This is a v2, original patch is here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637606.html
This addresses review feedback and:
- Fixes a bug in the previous version in
function_info::finalize_new_accesses; we should now correctly handle
the case where properties.refs ()
On 21/11/2023 16:49, Richard Sandiford wrote:
> Richard Sandiford writes:
> > Alex Coplan writes:
> >> This adds some helpers to access-utils.h for removing accesses from an
> >> access_array. This is needed by the upcoming aarch64 load/store pair
> >>
On 23/11/2023 12:41, Marek Polacek wrote:
> On Mon, Nov 20, 2023 at 05:29:58PM -0500, Jason Merrill wrote:
> > On 11/17/23 09:50, Alex Coplan wrote:
> > > Hi,
> > >
> > > This is a v5 patch to address Marek's feedback here:
> > > https://gcc.gnu.o
On 28/11/2023 09:22, Jakub Jelinek wrote:
> On Mon, Nov 27, 2023 at 10:58:04AM +0000, Alex Coplan wrote:
> > Many thanks both for the reviews, this is now pushed (with Jason's
> > above changes implemented) as g:06280a906cb3dc80cf5e07cf3335b758848d488d.
>
> The new
On 28/11/2023 17:03, Thomas Schwinge wrote:
> Hi!
>
> On 2023-11-17T14:50:45+0000, Alex Coplan wrote:
> > --- a/gcc/cp/cp-objcp-common.cc
> > +++ b/gcc/cp/cp-objcp-common.cc
>
> > +/* Table of features for __has_{feature,extension}. */
> > +
&
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_literals has been resolved, and updates the documentation as
suggested to point to the Clan
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:
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 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:
> > > >
> >
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 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
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
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,
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,
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.
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
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 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
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
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
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-
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/
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
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
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
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
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
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 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: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
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 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
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
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 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
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-
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
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
> >
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 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:
> > >
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
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 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 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,
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 is a v2 because I accidentally sent a WIP version of the patch last
time round which used replace_equiv_address instead of
replace_equiv_address_nv; that caused some ICEs (pointed out by the
Linaro CI) since pair addressing modes aren't a subset of the addresses
that are accepted by memory_ope
On 12/04/2024 20:02, Ajit Agarwal wrote:
> Hello Alex:
>
> On 11/04/24 7:55 pm, Alex Coplan wrote:
> > On 10/04/2024 23:48, Ajit Agarwal wrote:
> >> Hello Alex:
> >>
> >> On 10/04/24 7:52 pm, Alex Coplan wrote:
> >>> Hi Ajit,
> >>>
On 04/04/2024 11:00, Alex Coplan wrote:
> Hi,
>
> This adds a note to the GCC 14 release notes mentioning support for
> __has_{feature,extension} (PR60512).
>
> OK to commit?
Ping. Is this changes.html patch OK? I guess it needs a review from C++
maintainers since it adds
On 17/04/2024 11:41, Marek Polacek wrote:
> On Mon, Apr 15, 2024 at 11:13:27AM +0100, Alex Coplan wrote:
> > On 04/04/2024 11:00, Alex Coplan wrote:
> > > Hi,
> > >
> > > This adds a note to the GCC 14 release notes mentioning support for
> > > __has_{
On 26/04/2024 09:14, Marek Polacek wrote:
> On Fri, Apr 26, 2024 at 11:12:54AM +0100, Alex Coplan wrote:
> > On 17/04/2024 11:41, Marek Polacek wrote:
> > > On Mon, Apr 15, 2024 at 11:13:27AM +0100, Alex Coplan wrote:
> > > > On 04/04/2024 11:00, A
Hi,
The PR shows that when cfgrtl.cc:duplicate_insn_chain attempts to
update the MR_DEPENDENCE_CLIQUE information for a MEM_EXPR we can end up
accidentally dropping (e.g.) an ARRAY_REF from the MEM_EXPR and end up
replacing it with the underlying MEM_REF. This leads to an
inconsistency in the MEM
On 22/04/2024 13:01, Ajit Agarwal wrote:
> Hello Alex:
>
> On 14/04/24 10:29 pm, Ajit Agarwal wrote:
> > Hello Alex:
> >
> > On 12/04/24 11:02 pm, Ajit Agarwal wrote:
> >> Hello Alex:
> >>
> >> On 12/04/24 8:15 pm, Alex Coplan wrote:
>
This fixes a typo in combine_reg_notes in the load/store pair fusion
pass. As it stands, the calls to filter_notes store any
REG_FRAME_RELATED_EXPR to fr_expr with the following association:
- i2 -> fr_expr[0]
- i1 -> fr_expr[1]
but then the checks inside the following if statement expect the
On 12/04/2024 12:13, Richard Sandiford wrote:
> Alex Coplan writes:
> > This is a v2 because I accidentally sent a WIP version of the patch last
> > time round which used replace_equiv_address instead of
> > replace_equiv_address_nv; that caused some ICEs (pointed out by the
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
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,
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
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,
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 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
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
Hello,
Given the following C function:
double *f(double *p, unsigned x)
{
return p + x;
}
prior to this patch, GCC at -O2 would generate:
f:
add x0, x0, x1, uxtw 3
ret
but this add instruction uses architecturally-invalid syntax: the width
of the third operand conflicts
Ping^2.
> -Original Message-
> From: Gcc-patches On Behalf Of Alex
> Coplan
> Sent: 03 August 2020 16:02
> To: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH] driver: Fix several memory leaks
>
> Ping.
>
> > -Original Message-
> > From: Jit
Hi Richard,
> -Original Message-
> From: Richard Sandiford
> Sent: 18 August 2020 09:35
> To: Alex Coplan
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw ;
> Marcus Shawcroft ; Kyrylo Tkachov
>
> Subject: Re: [PATCH] aarch64: Don't generate invalid zero/s
Hello,
Inside a (mem) RTX, it is canonical to write multiplications by powers
of two using a (mult) [0]. For example, given the following C function:
long f(long *p, long x)
{
return p[x];
}
AArch64 GCC generates the following RTL insn (in final):
(set (reg/i:DI 0 x0)
(mem:DI (plus:DI
Thanks for the review, both.
On 26/08/2020 09:19, Vladimir Makarov wrote:
>
> On 2020-08-26 5:06 a.m., Richard Sandiford wrote:
> > Alex Coplan writes:
> >
> > Minor nit, should be formatted as:
> >
> > static rtx
> > canonicalize_reload_addr (rtx
This simple patch rewords a comment in cfgloop.h to improve the
grammar and readability.
OK for master?
Thanks,
Alex
---
gcc/ChangeLog:
* cfgloop.h (nb_iter_bound): Reword comment describing is_exit.
diff --git a/gcc/cfgloop.h b/gcc/cfgloop.h
index 18b404e292f..be978288aab 100644
---
Hello,
Following on from the earlier patch to fix up the syntax for
add/sub/adds/subs and friends with a sign/zero-extended operand [0],
this patch removes the "mult" variants of these patterns which are
all redundant.
This patch removes the following patterns from the AArch64 backend:
*adds_mu
Re: [PATCH] lra: Canonicalize mult to shift in address reloads
Hi Christophe,
On 28/08/2020 10:16, Christophe Lyon wrote:
> Hi Alex,
>
>
> On Wed, 26 Aug 2020 at 17:15, Alex Coplan wrote:
> >
> > Thanks for the review, both.
> >
> > On 26/08/2020 09:19, Vl
On 28/08/2020 11:00, Richard Sandiford wrote:
> Alex Coplan writes:
> > Hello,
> >
> > Following on from the earlier patch to fix up the syntax for
> > add/sub/adds/subs and friends with a sign/zero-extended operand [0],
> > this patch removes the "mult
Hi Christophe,
> -Original Message-
> From: Christophe Lyon
> Sent: 08 September 2020 09:15
> To: Alex Coplan
> Cc: gcc Patches ; Richard Earnshaw
> ; Marcus Shawcroft
> Subject: Re: [PATCH] aarch64: Don't generate invalid zero/sign-extend
>
Hello,
This patch adds support for Armv8-R AArch64 to GCC. It adds the -march
value armv8-r and sets the ACLE feature macro __ARM_ARCH_PROFILE
correctly when -march is set to armv8-r.
Testing:
* Bootstrapped and regtested on aarch64-none-linux-gnu.
* New unit test to check ACLE macro.
OK for m
This patch adds support for Arm's Cortex-R82 CPU to GCC. For more
information about this CPU, see [0].
Testing:
* Bootstrapped and regtested on aarch64-none-linux-gnu, no regressions.
[0] : https://developer.arm.com/ip-products/processors/cortex-r/cortex-r82
OK for trunk?
---
gcc/ChangeLog:
Hello,
Since r11-2903-g6b3034eaba83935d9f6dfb20d2efbdb34b5b00bf introduced a
canonicalization from mult to shift on address reloads, a missing
pattern in the AArch64 backend was exposed.
In particular, we were missing the ashift variant of
*add__multp2 (this mult variant is redundant and was
remo
,
Alex
---
gcc/ChangeLog:
2020-07-09 Alex Coplan
* gcc.c (set_static_spec): New.
(set_static_spec_owned): New.
(set_static_spec_shared): New.
(driver::maybe_putenv_COLLECT_LTO_WRAPPER): Use
set_static_spec_owned() to take ownership of lto_wrapper_file
101 - 200 of 398 matches
Mail list logo
