From: Andreas Krebbel <krebbel@linux.ibm.com>
To: gcc-patches@gcc.gnu.org
Subject: [Committed] IBM zSystems: Assume symbols without explicit alignment to be ok
Date: Mon, 26 Jun 2023 18:45:12 +0200 [thread overview]
Message-ID: <20230626164512.11512-1-krebbel@linux.ibm.com> (raw)
A change we have committed back in 2015 relies on the backend
requested ABI alignment to be applied to ALL symbols by the
middle-end. However, this does not appear to be the case for external
symbols. With this commit we assume all symbols without explicit
alignment to be aligned according to the ABI. That's the behavior we
had before.
This fixes a performance regression caused by the 2015 patch. Since
then the address of external char type symbols have been pushed to the
literal pool, although it is safe to access them with larl (which
requires symbols to reside at even addresses).
Bootstrapped and regression tested on s390x.
gcc/
* config/s390/s390.cc (s390_encode_section_info): Set
SYMBOL_FLAG_SET_NOTALIGN2 only if the symbol has explicitely been
misaligned.
gcc/testsuite/
* gcc.target/s390/larl-1.c: New test.
---
gcc/config/s390/s390.cc | 6 +++--
gcc/testsuite/gcc.target/s390/larl-1.c | 32 ++++++++++++++++++++++++++
2 files changed, 36 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/s390/larl-1.c
diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
index 9284477396d..d9f10542473 100644
--- a/gcc/config/s390/s390.cc
+++ b/gcc/config/s390/s390.cc
@@ -13706,8 +13706,10 @@ s390_encode_section_info (tree decl, rtx rtl, int first)
{
/* Store the alignment to be able to check if we can use
a larl/load-relative instruction. We only handle the cases
- that can go wrong (i.e. no FUNC_DECLs). */
- if (DECL_ALIGN (decl) == 0 || DECL_ALIGN (decl) % 16)
+ 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)
SYMBOL_FLAG_SET_NOTALIGN2 (XEXP (rtl, 0));
else if (DECL_ALIGN (decl) % 32)
SYMBOL_FLAG_SET_NOTALIGN4 (XEXP (rtl, 0));
diff --git a/gcc/testsuite/gcc.target/s390/larl-1.c b/gcc/testsuite/gcc.target/s390/larl-1.c
new file mode 100644
index 00000000000..5ef2ef63f82
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/larl-1.c
@@ -0,0 +1,32 @@
+/* Check if load-address-relative instructions are created */
+
+/* { dg-do compile { target { s390*-*-* } } } */
+/* { dg-options "-O2 -march=z10 -mzarch -fno-section-anchors" } */
+
+/* An explicitely misaligned symbol. This symbol is NOT aligned as
+ mandated by our ABI. However, the back-end needs to handle that in
+ order to make things like __attribute__((packed)) work. The symbol
+ address is expected to be loaded from literal pool. */
+/* { dg-final { scan-assembler "lgrl\t%r2," { target { lp64 } } } } */
+/* { dg-final { scan-assembler "lrl\t%r2," { target { ! lp64 } } } } */
+extern char align1 __attribute__((aligned(1)));
+
+/* { dg-final { scan-assembler "larl\t%r2,align2" } } */
+extern char align2 __attribute__((aligned(2)));
+
+/* { dg-final { scan-assembler "larl\t%r2,align4" } } */
+extern char align4 __attribute__((aligned(4)));
+
+/* An external char symbol without explicit alignment has a DECL_ALIGN
+ of just 8. In contrast to local definitions DATA_ABI_ALIGNMENT is
+ NOT applied to DECL_ALIGN in that case. Make sure the backend
+ still assumes this symbol to be aligned according to ABI
+ requirements. */
+/* { dg-final { scan-assembler "larl\t%r2,align_default" } } */
+extern char align_default;
+
+char * foo1 () { return &align1; }
+char * foo2 () { return &align2; }
+char * foo3 () { return &align4; }
+char * foo4 () { return &align_default; }
+
--
2.41.0
reply other threads:[~2023-06-26 16:45 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=20230626164512.11512-1-krebbel@linux.ibm.com \
--to=krebbel@linux.ibm.com \
--cc=gcc-patches@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).