public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc(refs/vendors/redhat/heads/gcc-8-branch)] aarch64: Tweak post-RA handling of CONST_INT moves [PR98136]
Date: Fri, 14 May 2021 14:54:25 +0000 (GMT)	[thread overview]
Message-ID: <20210514145425.82AAC393F856@sourceware.org> (raw)

https://gcc.gnu.org/g:6331cd93c5054d0ac598e48b2ed05649a399ee53

commit 6331cd93c5054d0ac598e48b2ed05649a399ee53
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Mon Apr 26 09:36:47 2021 +0100

    aarch64: Tweak post-RA handling of CONST_INT moves [PR98136]
    
    This PR is a regression caused by r8-5967, where we replaced
    a call to aarch64_internal_mov_immediate in aarch64_add_offset
    with a call to aarch64_force_temporary, which in turn uses the
    normal emit_move_insn{,_1} routines.
    
    The problem is that aarch64_add_offset can be called while
    outputting a thunk, where we require all instructions to be
    valid without splitting.  However, the move expanders were
    not splitting CONST_INT moves themselves.
    
    I think the right fix is to make the move expanders work
    even in this scenario, rather than require callers to handle
    it as a special case.
    
    gcc/
            PR target/98136
            * config/aarch64/aarch64.md (mov<mode>): Pass multi-instruction
            CONST_INTs to aarch64_expand_mov_immediate when called after RA.
    
    gcc/testsuite/
            PR target/98136
            * g++.dg/pr98136.C: New test.
    
    (cherry picked from commit 48c79f054bf435051c95ee093c45a0f8c9de5b4e)

Diff:
---
 gcc/config/aarch64/aarch64.md  | 17 +++++++++++++----
 gcc/testsuite/g++.dg/pr98136.C | 26 ++++++++++++++++++++++++++
 2 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index ea1319c56a4..bfcc1a2a18b 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -986,10 +986,19 @@
     if (GET_CODE (operands[0]) == MEM && operands[1] != const0_rtx)
       operands[1] = force_reg (<MODE>mode, operands[1]);
 
-    /* FIXME: RR we still need to fix up what we are doing with
-       symbol_refs and other types of constants.  */
-    if (CONSTANT_P (operands[1])
-        && !CONST_INT_P (operands[1]))
+    /* Lower moves of symbolic constants into individual instructions.
+       Doing this now is sometimes necessary for correctness, since some
+       sequences require temporary pseudo registers.  Lowering now is also
+       often better for optimization, since more RTL passes get the
+       chance to optimize the individual instructions.
+
+       When called after RA, also split multi-instruction moves into
+       smaller pieces now, since we can't be sure that sure that there
+       will be a following split pass.  */
+    if (CONST_INT_P (operands[1])
+	? (reload_completed
+	   && !aarch64_mov_imm_operand (operands[1], <MODE>mode))
+	: CONSTANT_P (operands[1]))
      {
        aarch64_expand_mov_immediate (operands[0], operands[1]);
        DONE;
diff --git a/gcc/testsuite/g++.dg/pr98136.C b/gcc/testsuite/g++.dg/pr98136.C
new file mode 100644
index 00000000000..f3c27f6b09f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr98136.C
@@ -0,0 +1,26 @@
+// { dg-do compile { target { ilp32 || lp64 } } }
+
+struct AddIn
+{
+    virtual ~AddIn() {}
+    virtual void AddInCall()=0;
+};
+
+struct Base
+{
+    char b[32*1024*1024];   // Anything bigger than 16mb causes internal compiler error
+    virtual ~Base() {}
+};
+
+struct Deriv : public Base,
+                    public AddIn
+{
+    void AddInCall() {}
+};
+
+int main (int argc, char **argv)
+{
+    Deriv deriv;
+    deriv.AddInCall();
+    return 0;
+}


                 reply	other threads:[~2021-05-14 14:54 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20210514145425.82AAC393F856@sourceware.org \
    --to=jakub@gcc.gnu.org \
    --cc=gcc-cvs@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).