public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/114674] [aarch64] ldp_fusion fails to merge 2 strs due to imprecise alignment info
Date: Tue, 07 May 2024 13:44:03 +0000	[thread overview]
Message-ID: <bug-114674-4-cid9KlyYTx@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-114674-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114674

--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Alex Coplan <acoplan@gcc.gnu.org>:

https://gcc.gnu.org/g:74690ff96b263b8609639b7fbc5d6afd3f19cb98

commit r15-282-g74690ff96b263b8609639b7fbc5d6afd3f19cb98
Author: Alex Coplan <alex.coplan@arm.com>
Date:   Wed Apr 10 16:30:36 2024 +0100

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

    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_equiv_address_nv, as this will preserve e.g. the MEM_ALIGN of the
    mem whose address we're changing.

    The PR shows that by adjusting the other mem we lose alignment
    information about the original access and therefore end up rejecting an
    otherwise viable pair when --param=aarch64-stp-policy=aligned is passed.
    This patch fixes that by using replace_equiv_address_nv instead.

    Notably this is the same approach as taken by
    aarch64_check_consecutive_mems when a change of base is required, so
    this at least makes things more consistent between the ldp fusion pass
    and the peepholes.

    gcc/ChangeLog:

            PR target/114674
            * config/aarch64/aarch64-ldp-fusion.cc (ldp_bb_info::fuse_pair):
            Use replace_equiv_address_nv on a change of base instead of
            adjust_address_nv on the other access.

    gcc/testsuite/ChangeLog:

            PR target/114674
            * gcc.target/aarch64/pr114674.c: New test.

  parent reply	other threads:[~2024-05-07 13:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-10  7:41 [Bug rtl-optimization/114674] New: " dizhao at os dot amperecomputing.com
2024-04-10  7:43 ` [Bug rtl-optimization/114674] " dizhao at os dot amperecomputing.com
2024-04-10  8:34 ` acoplan at gcc dot gnu.org
2024-04-10 13:27 ` acoplan at gcc dot gnu.org
2024-04-10 14:00 ` acoplan at gcc dot gnu.org
2024-04-11  6:40 ` dizhao at os dot amperecomputing.com
2024-05-07 13:44 ` cvs-commit at gcc dot gnu.org [this message]
2024-05-07 13:46 ` acoplan at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-114674-4-cid9KlyYTx@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).