public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Wilco Dijkstra <wilco@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc r12-1014] AArch64: Cleanup aarch64_classify_symbol
Date: Mon, 24 May 2021 14:00:57 +0000 (GMT)	[thread overview]
Message-ID: <20210524140057.AC883385802D@sourceware.org> (raw)

https://gcc.gnu.org/g:fb0746f3a6b7fd0223efa71d0dc3fc02166e338b

commit r12-1014-gfb0746f3a6b7fd0223efa71d0dc3fc02166e338b
Author: Wilco Dijkstra <wdijkstr@arm.com>
Date:   Mon May 24 14:23:50 2021 +0100

    AArch64: Cleanup aarch64_classify_symbol
    
    Use a GOT indirection for extern weak symbols instead of a literal - this is
    the same as PIC/PIE and mirrors LLVM behaviour.  Ensure PIC/PIE use the same
    offset limits for symbols that don't use the GOT.
    
    Passes bootstrap and regress.
    
    ChangeLog:
    2021-04-27  Wilco Dijkstra  <wdijkstr@arm.com>
    
            * config/aarch64/aarch64.c (aarch64_classify_symbol): Use GOT for
            extern weak symbols.  Limit symbol offsets for non-GOT symbols with
            PIC/PIE.

Diff:
---
 gcc/config/aarch64/aarch64.c | 37 ++++++++++++++++---------------------
 1 file changed, 16 insertions(+), 21 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index c1e451ec8dc..e9f961d41fa 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -17902,7 +17902,14 @@ aarch64_classify_symbol (rtx x, HOST_WIDE_INT offset)
 
       switch (aarch64_cmodel)
 	{
+	case AARCH64_CMODEL_TINY_PIC:
 	case AARCH64_CMODEL_TINY:
+	  /* With -fPIC non-local symbols use the GOT.  For orthogonality
+	     always use the GOT for extern weak symbols.  */
+	  if ((flag_pic || SYMBOL_REF_WEAK (x))
+	      && !aarch64_symbol_binds_local_p (x))
+	    return SYMBOL_TINY_GOT;
+
 	  /* When we retrieve symbol + offset address, we have to make sure
 	     the offset does not cause overflow of the final address.  But
 	     we have no way of knowing the address of symbol at compile time
@@ -17910,42 +17917,30 @@ aarch64_classify_symbol (rtx x, HOST_WIDE_INT offset)
 	     symbol + offset is outside the addressible range of +/-1MB in the
 	     TINY code model.  So we limit the maximum offset to +/-64KB and
 	     assume the offset to the symbol is not larger than +/-(1MB - 64KB).
-	     If offset_within_block_p is true we allow larger offsets.
-	     Furthermore force to memory if the symbol is a weak reference to
-	     something that doesn't resolve to a symbol in this module.  */
-
-	  if (SYMBOL_REF_WEAK (x) && !aarch64_symbol_binds_local_p (x))
-	    return SYMBOL_FORCE_TO_MEM;
+	     If offset_within_block_p is true we allow larger offsets.  */
 	  if (!(IN_RANGE (offset, -0x10000, 0x10000)
 		|| offset_within_block_p (x, offset)))
 	    return SYMBOL_FORCE_TO_MEM;
 
 	  return SYMBOL_TINY_ABSOLUTE;
 
+
+	case AARCH64_CMODEL_SMALL_SPIC:
+	case AARCH64_CMODEL_SMALL_PIC:
 	case AARCH64_CMODEL_SMALL:
+	  if ((flag_pic || SYMBOL_REF_WEAK (x))
+	      && !aarch64_symbol_binds_local_p (x))
+	    return aarch64_cmodel == AARCH64_CMODEL_SMALL_SPIC
+		    ? SYMBOL_SMALL_GOT_28K : SYMBOL_SMALL_GOT_4G;
+
 	  /* Same reasoning as the tiny code model, but the offset cap here is
 	     1MB, allowing +/-3.9GB for the offset to the symbol.  */
-
-	  if (SYMBOL_REF_WEAK (x) && !aarch64_symbol_binds_local_p (x))
-	    return SYMBOL_FORCE_TO_MEM;
 	  if (!(IN_RANGE (offset, -0x100000, 0x100000)
 		|| offset_within_block_p (x, offset)))
 	    return SYMBOL_FORCE_TO_MEM;
 
 	  return SYMBOL_SMALL_ABSOLUTE;
 
-	case AARCH64_CMODEL_TINY_PIC:
-	  if (!aarch64_symbol_binds_local_p (x))
-	    return SYMBOL_TINY_GOT;
-	  return SYMBOL_TINY_ABSOLUTE;
-
-	case AARCH64_CMODEL_SMALL_SPIC:
-	case AARCH64_CMODEL_SMALL_PIC:
-	  if (!aarch64_symbol_binds_local_p (x))
-	    return (aarch64_cmodel == AARCH64_CMODEL_SMALL_SPIC
-		    ?  SYMBOL_SMALL_GOT_28K : SYMBOL_SMALL_GOT_4G);
-	  return SYMBOL_SMALL_ABSOLUTE;
-
 	case AARCH64_CMODEL_LARGE:
 	  /* This is alright even in PIC code as the constant
 	     pool reference is always PC relative and within


                 reply	other threads:[~2021-05-24 14:00 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=20210524140057.AC883385802D@sourceware.org \
    --to=wilco@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).