public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
* [gcc r14-2910] IBM Z: Handle unaligned symbols
@ 2023-08-01 19:11 Andreas Krebbel
  0 siblings, 0 replies; only message in thread
From: Andreas Krebbel @ 2023-08-01 19:11 UTC (permalink / raw)
  To: gcc-cvs

https://gcc.gnu.org/g:6cb2f2c7f36c999590a949f663d6057cbc67271f

commit r14-2910-g6cb2f2c7f36c999590a949f663d6057cbc67271f
Author: Andreas Krebbel <krebbel@linux.ibm.com>
Date:   Tue Aug 1 21:01:19 2023 +0200

    IBM Z: Handle unaligned symbols
    
    The IBM Z ELF ABI mandates every symbol to reside on a 2 byte boundary
    in order to be able to use the larl instruction. However, in some
    situations it is difficult to enforce this, e.g. for common linker
    scripts as used in the Linux kernel. This patch introduces the
    -munaligned-symbols option. When that option is used, external symbols
    without an explicit alignment are considered unaligned and its address
    will be pushed into GOT or the literal pool.
    
    If the symbol in the final linker step turns out end up on a 2 byte
    boundary the linker is able to take this back and replace the indirect
    reference with larl again. This should minimize the effect to symbols
    which are actually unaligned in the end.
    
    gcc/ChangeLog:
    
            * config/s390/s390.cc (s390_encode_section_info): Assume external
            symbols without explicit alignment to be unaligned if
            -munaligned-symbols has been specified.
            * config/s390/s390.opt (-munaligned-symbols): New option.
    
    gcc/testsuite/ChangeLog:
    
            * gcc.target/s390/aligned-1.c: New test.
            * gcc.target/s390/unaligned-1.c: New test.

Diff:
---
 gcc/config/s390/s390.cc                     |  9 +++++++--
 gcc/config/s390/s390.opt                    |  7 +++++++
 gcc/testsuite/gcc.target/s390/aligned-1.c   | 20 ++++++++++++++++++++
 gcc/testsuite/gcc.target/s390/unaligned-1.c | 20 ++++++++++++++++++++
 4 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
index 13970edcb5e..89474fd487a 100644
--- a/gcc/config/s390/s390.cc
+++ b/gcc/config/s390/s390.cc
@@ -13709,8 +13709,13 @@ s390_encode_section_info (tree decl, rtx rtl, int first)
 	 a larl/load-relative instruction.  We only handle the cases
 	 that can go wrong (i.e. no FUNC_DECLs).
 	 All symbols without an explicit alignment are assumed to be 2
-	 byte aligned as mandated by our ABI.  */
-      if (DECL_USER_ALIGN (decl) && DECL_ALIGN (decl) % 16)
+	 byte aligned as mandated by our ABI.  This behavior can be
+	 overridden for external symbols with the -munaligned-symbols
+	 switch.  */
+      if (DECL_ALIGN (decl) % 16
+	  && (DECL_USER_ALIGN (decl)
+	      || (!SYMBOL_REF_LOCAL_P (XEXP (rtl, 0))
+		  && s390_unaligned_symbols_p)))
 	SYMBOL_FLAG_SET_NOTALIGN2 (XEXP (rtl, 0));
       else if (DECL_ALIGN (decl) % 32)
 	SYMBOL_FLAG_SET_NOTALIGN4 (XEXP (rtl, 0));
diff --git a/gcc/config/s390/s390.opt b/gcc/config/s390/s390.opt
index 344aa551f44..496572046f7 100644
--- a/gcc/config/s390/s390.opt
+++ b/gcc/config/s390/s390.opt
@@ -329,3 +329,10 @@ Target Undocumented Var(unroll_only_small_loops) Init(0) Save
 mpreserve-args
 Target Var(s390_preserve_args_p) Init(0)
 Store all argument registers on the stack.
+
+munaligned-symbols
+Target Var(s390_unaligned_symbols_p) Init(0)
+Assume external symbols to be potentially unaligned.  By default all
+symbols without explicit alignment are assumed to reside on a 2 byte
+boundary as mandated by the IBM Z ABI.
+
diff --git a/gcc/testsuite/gcc.target/s390/aligned-1.c b/gcc/testsuite/gcc.target/s390/aligned-1.c
new file mode 100644
index 00000000000..2dc99cf66bd
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/aligned-1.c
@@ -0,0 +1,20 @@
+/* Even symbols without explicite alignment are assumed to reside on a
+   2 byte boundary, as mandated by the IBM Z ELF ABI, and therefore
+   can be accessed using the larl instruction.  */
+
+/* { dg-do compile } */
+/* { dg-options "-O3 -march=z900 -fno-section-anchors" } */
+
+extern unsigned char extern_implicitly_aligned;
+extern unsigned char extern_explicitly_aligned __attribute__((aligned(2)));
+unsigned char aligned;
+
+unsigned char
+foo ()
+{
+  return extern_implicitly_aligned + extern_explicitly_aligned + aligned;
+}
+
+/* { dg-final { scan-assembler-times "larl\t%r\[0-9\]*,extern_implicitly_aligned\n" 1 } } */
+/* { dg-final { scan-assembler-times "larl\t%r\[0-9\]*,extern_explicitly_aligned\n" 1 } } */
+/* { dg-final { scan-assembler-times "larl\t%r\[0-9\]*,aligned\n" 1 } } */
diff --git a/gcc/testsuite/gcc.target/s390/unaligned-1.c b/gcc/testsuite/gcc.target/s390/unaligned-1.c
new file mode 100644
index 00000000000..421330aded1
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/unaligned-1.c
@@ -0,0 +1,20 @@
+/* With the -munaligned-symbols option all external symbols without
+   explicite alignment are assumed to be potentially unaligned and
+   therefore cannot be accessed with larl.  */
+
+/* { dg-do compile } */
+/* { dg-options "-O3 -march=z900 -fno-section-anchors -munaligned-symbols" } */
+
+extern unsigned char extern_unaligned;
+extern unsigned char extern_explicitly_aligned __attribute__((aligned(2)));
+unsigned char aligned;
+
+unsigned char
+foo ()
+{
+  return extern_unaligned + extern_explicitly_aligned + aligned;
+}
+
+/* { dg-final { scan-assembler-times "larl\t%r\[0-9\]*,extern_unaligned\n" 0 } } */
+/* { dg-final { scan-assembler-times "larl\t%r\[0-9\]*,extern_explicitly_aligned\n" 1 } } */
+/* { dg-final { scan-assembler-times "larl\t%r\[0-9\]*,aligned\n" 1 } } */

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2023-08-01 19:11 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-01 19:11 [gcc r14-2910] IBM Z: Handle unaligned symbols Andreas Krebbel

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).