public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Bernd Edlinger <bernd.edlinger@hotmail.de>
To: Dimitar Dimitrov <dimitar@dinux.eu>,
	Segher Boessenkool	<segher@kernel.crashing.org>,
	Christophe Lyon <christophe.lyon@linaro.org>,
	Thomas Preudhomme <thomas.preudhomme@linaro.org>,
	"gcc-patches@gcc.gnu.org"	<gcc-patches@gcc.gnu.org>,
	"richard.sandiford@arm.com"	<richard.sandiford@arm.com>
Subject: Re: [PATCH] [RFC] PR target/52813 and target/11807
Date: Tue, 18 Dec 2018 14:16:00 -0000	[thread overview]
Message-ID: <DB7PR07MB5353DE7AB638655BAE61FC09E4BD0@DB7PR07MB5353.eurprd07.prod.outlook.com> (raw)
In-Reply-To: <87woo84boh.fsf@arm.com>

[-- Attachment #1: Type: text/plain, Size: 2696 bytes --]

Hi,

while I looked closely at the asm statement in the gdb,
I realized that the SP clobber forces the function to use
the frame pointer, and prevents the red zone.  That
makes the push / pop sequence in the asm statement safe
to use, as long as the stack is restored to the original
value.  That can be a quite useful feature.  And that might
have been the reason why the rsp clobber was chosen in the
first place.

This seems to work for all targets, but it started to work
this way with gcc-6, all versions before that do ignore
this clobber stmt (as confirmed by godbolt).

The clobber stmt make the LRA register allocator switch
frame_pointer_needed to 1, and therefore in all likelihood,
all targets should use that consistently.

On 12/17/18 12:47 PM, Richard Sandiford wrote:
> Dimitar Dimitrov <dimitar@dinux.eu> writes:
>> On Sun, Dec 16 2018 at 14:36:26 EET Bernd Edlinger wrote:
>>> Hi,
>>>
>>> if I understood that right, then clobbering sp is and has always been
>>> ignored.
> 
> PR77904 was about the clobber not being ignored, so the behaviour
> hasn't been consistent.
> 

I think 77904 was a fall-out from the change in the LRA register allocator.
The patch referenced in the PR does simply honor frame_pointer_needed,
which changed with gcc-6, and caused a regression on arm.

> I'm also not sure it was always ignored in recent sources.  The clobber
> does get added to the associated rtl insn, and it'd be surprising if
> that never had an effect.
> 
>>> If that is right, then I would much prefer a warning, that says exactly
>>> that, because that would also help to understand why removing that clobber
>>> statement is safe even for old gcc versions.
> 
> If the asm does leave sp with a different value, then it's never been safe,
> regardless of the gcc version.  That's why an error seems more appropriate.
> 
>> Thank you. Looks like general consensus is to have a warning. See attached
>> patch that switches the error to a warning.
> 
> I don't think there's a good reason to treat this differently from the
> preexisting PIC register error.  If the argument for making it a warning
> rather than an error is that the asm might happen to work by accident,
> then the same is true for the PIC register.
> 

In the light of my findings, I believe with a good warning message that
explains that the SP needs to be restored to the previous value, that
is a useful feature, that enables the asm statement to push temporary
values on the stack which would not be safe otherwise.

Therefore I propose not to rip it out at this time.
See my proposed patch.  What do you think?

Is it OK?


Thanks
Bernd.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch-pr52813.diff --]
[-- Type: text/x-patch; name="patch-pr52813.diff", Size: 2726 bytes --]

2018-12-18  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	* cfgexpand.c (asm_clobber_reg_is_valid): Emit only a warning together
	with an information message when the stack pointer is clobbered.

testsuite:
2018-12-18  Bernd Edlinger  <bernd.edlinger@hotmail.de>

	* gcc.target/i386/pr52813.c: Adjust test.

Index: gcc/cfgexpand.c
===================================================================
--- gcc/cfgexpand.c	(revision 267164)
+++ gcc/cfgexpand.c	(working copy)
@@ -2854,6 +2854,7 @@ tree_conflicts_with_clobbers_p (tree t, HARD_REG_S
    asm clobber operand.  Some HW registers cannot be
    saved/restored, hence they should not be clobbered by
    asm statements.  */
+
 static bool
 asm_clobber_reg_is_valid (int regno, int nregs, const char *regname)
 {
@@ -2872,11 +2873,23 @@ asm_clobber_reg_is_valid (int regno, int nregs, co
       error ("PIC register clobbered by %qs in %<asm%>", regname);
       is_valid = false;
     }
-  /* Clobbering the STACK POINTER register is an error.  */
+  /* Clobbering the STACK POINTER register is likely an error.
+     However it is useful to force the use of frame pointer and prevent
+     the use of red zone.  Thus without this clobber, pushing temporary
+     values onto the stack might clobber the red zone or make stack based
+     memory references invalid.  */
   if (overlaps_hard_reg_set_p (regset, Pmode, STACK_POINTER_REGNUM))
     {
-      error ("Stack Pointer register clobbered by %qs in %<asm%>", regname);
-      is_valid = false;
+      if (warning (0, "Stack Pointer register clobbered by %qs in %<asm%>",
+		   regname))
+	{
+	  inform (input_location,
+		  "This does likely not do what you would expect."
+		  " The Stack Pointer register still needs to be restored to"
+		  " the previous value, however it is safe to push values onto"
+		  " the stack, when they are popped again from the stack"
+		  " before the asm statement terminates");
+	}
     }
 
   return is_valid;
Index: gcc/testsuite/gcc.target/i386/pr52813.c
===================================================================
--- gcc/testsuite/gcc.target/i386/pr52813.c	(revision 267164)
+++ gcc/testsuite/gcc.target/i386/pr52813.c	(working copy)
@@ -1,9 +1,10 @@
 /* Ensure that stack pointer cannot be an asm clobber.  */
 /* { dg-do compile { target { ! ia32 } } } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O3 -fomit-frame-pointer" } */
 
 void
 test1 (void)
 {
-  asm volatile ("" : : : "%esp"); /* { dg-error "Stack Pointer register clobbered" } */
+  asm volatile ("" : : : "%rsp"); /* { dg-warning "Stack Pointer register clobbered" } */
 }
+/* { dg-final { scan-assembler "(?n)pushq.*%rbp" } } */

  parent reply	other threads:[~2018-12-18 14:16 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-16 14:36 Bernd Edlinger
2018-12-16 16:14 ` Dimitar Dimitrov
2018-12-17 11:47   ` Richard Sandiford
2018-12-17 12:54     ` Christophe Lyon
2018-12-17 13:35       ` Richard Sandiford
2018-12-17 13:42         ` Christophe Lyon
2018-12-17 14:05           ` Bernd Edlinger
2018-12-17 14:10         ` Bernd Edlinger
2018-12-17 15:55     ` Segher Boessenkool
2018-12-17 18:46       ` Richard Sandiford
2018-12-17 20:15         ` Bernd Edlinger
2018-12-19  6:40           ` Dimitar Dimitrov
2018-12-19  9:29             ` Segher Boessenkool
2018-12-18 14:16     ` Bernd Edlinger [this message]
2018-12-18 15:14       ` Bernd Edlinger
2019-01-07  9:23   ` Jakub Jelinek
2019-01-07 21:51     ` Bernd Edlinger
2019-01-08 12:03       ` Richard Sandiford
2019-01-10 13:21         ` Segher Boessenkool
2019-01-10 21:23           ` Richard Sandiford
2019-01-10 21:26             ` Jakub Jelinek
2019-01-10 21:56               ` Richard Sandiford
2019-01-11 12:26                 ` Segher Boessenkool
2019-01-10 22:32             ` Bernd Edlinger
2019-01-11 12:18             ` Segher Boessenkool
2019-01-11 12:23               ` Richard Sandiford
2019-01-11 22:59         ` Jeff Law
2019-01-17 14:27           ` Christophe Lyon
2019-01-18  9:49             ` Richard Sandiford
  -- strict thread matches above, loose matches on Subject: below --
2018-12-09 10:09 Dimitar Dimitrov
2018-12-10 11:21 ` Richard Sandiford
2018-12-10 19:36   ` Dimitar Dimitrov
2018-12-11 15:52     ` Richard Sandiford
2018-12-12  9:42       ` Christophe Lyon
2018-12-12 10:03         ` Christophe Lyon
2018-12-12 16:39           ` Dimitar Dimitrov
2018-12-12 10:30         ` Thomas Preudhomme
2018-12-12 11:21           ` Thomas Preudhomme
2018-12-12 13:19             ` Christophe Lyon
2018-12-12 15:13               ` Christophe Lyon
2018-12-12 15:35                 ` Thomas Preudhomme
2018-12-12 16:26               ` Dimitar Dimitrov
2018-12-13 14:49                 ` Segher Boessenkool
2018-12-13 22:21                   ` Dimitar Dimitrov
2018-12-14  8:52                     ` Segher Boessenkool
2018-12-16  8:43                       ` Dimitar Dimitrov
2018-12-17 15:23                         ` Segher Boessenkool
2018-12-14 13:49               ` Richard Sandiford
2018-12-15 15:38                 ` Segher Boessenkool
2018-12-12 11:24 ` Andreas Schwab

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=DB7PR07MB5353DE7AB638655BAE61FC09E4BD0@DB7PR07MB5353.eurprd07.prod.outlook.com \
    --to=bernd.edlinger@hotmail.de \
    --cc=christophe.lyon@linaro.org \
    --cc=dimitar@dinux.eu \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.sandiford@arm.com \
    --cc=segher@kernel.crashing.org \
    --cc=thomas.preudhomme@linaro.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).