public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@adacore.com>
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] strub: avoid lto inlining
Date: Thu, 14 Dec 2023 16:52:29 -0300	[thread overview]
Message-ID: <orsf4436ki.fsf@lxoliva.fsfla.org> (raw)


The strub builtins are not suited for cross-unit inlining, they should
only be inlined by the builtin expanders, if at all.  While testing on
sparc64, it occurred to me that, if libgcc was built with LTO enabled,
lto1 might inline them, and that would likely break things.  So, make
sure they're clearly marked as not inlinable.

Regstrapped on x86_64-linux-gnu, also testing on sparc-solaris2.11.3.
Ok to install?


for  libgcc/ChangeLog

	* strub.c (ATTRIBUTE_NOINLINE): New.
	(ATTRIBUTE_STRUB_CALLABLE): Add it.
	(__strub_dummy_force_no_leaf): Drop it.
---
 libgcc/strub.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libgcc/strub.c b/libgcc/strub.c
index b0f990d9deebb..5062554d0e1e6 100644
--- a/libgcc/strub.c
+++ b/libgcc/strub.c
@@ -36,7 +36,12 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 # define TOPS <
 #endif
 
-#define ATTRIBUTE_STRUB_CALLABLE __attribute__ ((__strub__ ("callable")))
+/* Make sure these builtins won't be inlined, even with LTO.  */
+#define ATTRIBUTE_NOINLINE \
+  __attribute__ ((__noinline__, __noclone__))
+
+#define ATTRIBUTE_STRUB_CALLABLE \
+  __attribute__ ((__strub__ ("callable"))) ATTRIBUTE_NOINLINE
 
 /* Enter a stack scrubbing context, initializing the watermark to the caller's
    stack address.  */
@@ -72,7 +77,6 @@ __strub_update (void **watermark)
 /* Dummy function, called to force the caller to not be a leaf function, so
    that it can't use the red zone.  */
 static void ATTRIBUTE_STRUB_CALLABLE
-__attribute__ ((__noinline__, __noipa__))
 __strub_dummy_force_no_leaf (void)
 {
 }

-- 
Alexandre Oliva, happy hacker            https://FSFLA.org/blogs/lxo/
   Free Software Activist                   GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity
Excluding neuro-others for not behaving ""normal"" is *not* inclusive

             reply	other threads:[~2023-12-14 19:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-14 19:52 Alexandre Oliva [this message]
2023-12-15  7:00 ` Richard Biener
2023-12-19 23:53   ` Alexandre Oliva

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=orsf4436ki.fsf@lxoliva.fsfla.org \
    --to=oliva@adacore.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).