public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Wohlferd <dw@LimeGreenSocks.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	rth@gcc.gnu.org, pinskia@gcc.gnu.org, Jeff Law <law@redhat.com>,
	Sandra Loosemore <sandra@codesourcery.com>
Subject: Re: basic asm and memory clobbers
Date: Mon, 16 Nov 2015 01:23:00 -0000	[thread overview]
Message-ID: <56493010.9070707@LimeGreenSocks.com> (raw)
In-Reply-To: <20151109093229.GA5260@gate.crashing.org>

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

On 11/9/2015 1:32 AM, Segher Boessenkool wrote:
> On Sun, Nov 08, 2015 at 04:10:01PM -0800, David Wohlferd wrote:
>> It seems like a doc update is what is needed to close PR24414 (Old-style
>> asms don't clobber memory).
> What is needed to close the bug is to make the compiler work properly.

The question of course is, what does 'properly' mean?  My assertion is 
that 10 years on, 'properly' means whatever it's doing now. Changing it 
at this point will probably break more than it fixes, and (as you said) 
there is a plausible work-around using extended asm.

So while this bug could be resolved as 'invalid' (since the compiler is 
behaving 'properly'), I'm thinking to split the difference and 'fix' it 
with a doc patch that describes the supported behavior.

> Whether that means clobbering memory or not, I don't much care -- with
> the status quo, if you want your asm to clobber memory you have to use
> extended asm; if basic asm is made to clobber memory, if you want your
> asm to *not* clobber memory you have to use extended asm (which you
> can with no operands by writing e.g.  asm("bork" : );  ).  So both
> behaviours are available whether we make a change or not.
>
> But changing things now will likely break user code.
>
>>   Safely accessing C data and calling functions from basic @code{asm} is more
>> -complex than it may appear. To access C data, it is better to use extended
>> +complex than it may appear. To access C data (including both local and
>> +global register variables), use extended
>>   @code{asm}.
> I don't think this makes things clearer.  Register vars are described
> elsewhere already;

The docs for local register variables describe this limitation.  But 
globals does not.

Whether this information belongs in local register, global register, 
basic asm, or all 3 depends on which section of the docs users will be 
reading when they need to know this information.

> if you really think it needs mentioning here, put
> it at the end (in its own sentence), don't break up this sentence.

Ok.

> (dot space space).
>
>> +Basic @code{asm} statements are not treated as though they used a "memory"
>> +clobber, although they do implicitly perform a clobber of the flags
>> +(@pxref{Clobbers}).
> They do not clobber the flags.  Observe:

Ouch.  i386 shows the same thing for basic asm.

Having to preserve the flags is ugly, but since that's the behavior, 
let's write it down.

> ===
> void f(int a)
> {
>          a = a >> 2;
>          if (a <= 0)
>                  asm("OHAI");
>          if (a >= 0)
>                  asm("OHAI2");
> }
> ===
>
> Compiling this for powerpc gives (-m32, edited):
>
> f:
>          srawi. 9,3,2    # this sets cr0
>          ble 0,.L5       # this uses cr0
> .L2:
>          OHAI2
>          blr
>          .p2align 4,,15
> .L5:
>          OHAI
>          bnelr 0         # this uses cr0
>          b .L2
>
> which shows that CR0 (which is "cc") is live over the asm.  So are all
> other condition regs.
>
> It is true for cc0 targets I guess, but there aren't many of those left.
>
>> Also, there is no implicit clobbering of registers,
>> +so any registers changed must be restored to their original value before
>> +exiting the @code{asm}.
> One of the important uses of asm is to set registers GCC does not know
> about, so you might want to phrase this differently.

Ahh, good point.

What would you say to "general purpose registers?"

Update attached.

dw

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

Index: extend.texi
===================================================================
--- extend.texi	(revision 229910)
+++ extend.texi	(working copy)
@@ -7353,8 +7353,9 @@
 @end itemize
 
 Safely accessing C data and calling functions from basic @code{asm} is more 
-complex than it may appear. To access C data, it is better to use extended 
-@code{asm}.
+complex than it may appear. To access C data use extended @code{asm}. Do
+not attempt to directly access local or global register variables from
+within basic @code{asm} (@pxref{Explicit Register Variables}).
 
 Do not expect a sequence of @code{asm} statements to remain perfectly 
 consecutive after compilation. If certain instructions need to remain 
@@ -7376,6 +7377,11 @@
 visibility of any symbols it references. This may result in GCC discarding 
 those symbols as unreferenced.
 
+Basic @code{asm} statements are not treated as though they used a "memory"
+clobber (@pxref{Clobbers}). Also, neither the flags nor the general-purpose
+registers are clobbered, so any changes must be restored to their original
+value before exiting the @code{asm}.
+
 The compiler copies the assembler instructions in a basic @code{asm} 
 verbatim to the assembly language output file, without 
 processing dialects or any of the @samp{%} operators that are available with

  reply	other threads:[~2015-11-16  1:23 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-09  0:10 David Wohlferd
2015-11-09  9:32 ` Segher Boessenkool
2015-11-16  1:23   ` David Wohlferd [this message]
2015-11-16 21:29     ` Jeff Law
2015-11-17  5:56       ` David Wohlferd
2015-11-17  9:27         ` Andrew Haley
2015-11-17 21:31         ` Jeff Law
2015-11-17 22:07           ` Andrew Pinski
2015-11-18 22:04             ` Jeff Law
2015-11-18  1:28           ` Segher Boessenkool
2015-11-18 22:08             ` Jeff Law
2015-11-20  1:24           ` David Wohlferd
2015-11-20  1:53             ` Sandra Loosemore
2015-11-22  5:09               ` David Wohlferd
2015-11-20  3:14             ` Segher Boessenkool
2015-11-20 10:45               ` David Wohlferd
2015-11-20 14:56                 ` Segher Boessenkool
2015-11-20 20:01                   ` Jeff Law
2015-11-20 22:07                     ` Paul_Koning
2015-11-20 10:17             ` Andrew Haley
2015-11-20 10:38               ` David Wohlferd
2015-11-20 11:14                 ` Andrew Haley
2015-11-20 12:38                   ` David Wohlferd
2015-11-20 13:05                     ` Richard Henderson
2015-11-20 15:20                       ` Segher Boessenkool
2015-11-20 15:30                         ` Richard Henderson
2015-11-20 15:34                           ` Jakub Jelinek
2015-11-20 16:14                             ` Richard Henderson
2015-11-20 23:56                               ` David Wohlferd
2015-11-21 12:57                                 ` David Wohlferd
2015-11-23  9:56                                   ` Joseph Myers
2015-11-23 10:04                                   ` Andrew Haley
2015-11-23 20:37                                     ` Jeff Law
2015-11-23 21:36                                       ` David Wohlferd
2015-11-23 21:44                                         ` Paul_Koning
2015-11-24  1:39                                           ` David Wohlferd
2015-11-24  2:22                                             ` Segher Boessenkool
2015-11-24  4:48                                               ` Jeff Law
2015-11-24  5:12                                                 ` Segher Boessenkool
2015-11-24  5:25                                                   ` Jeff Law
2015-11-24 17:13                                             ` Paul_Koning
2015-11-24 17:49                                               ` Ian Lance Taylor
2015-11-24 18:00                                                 ` Paul_Koning
2015-11-25  2:11                                               ` David Wohlferd
2015-11-25  9:09                                                 ` Andrew Haley
2015-11-23 21:03                                     ` David Wohlferd
2015-11-24  9:48                                       ` Andrew Haley
2015-11-20 16:21                           ` Segher Boessenkool
2015-11-27 17:45                           ` Segher Boessenkool
2015-11-20 18:24                       ` Jeff Law
2015-11-20 19:39                         ` Paul_Koning
2015-11-26 10:30                       ` Hans-Peter Nilsson
2015-11-26 12:35                         ` Segher Boessenkool
2015-11-26 16:26                           ` Hans-Peter Nilsson
2015-11-26 21:54                             ` David Wohlferd
2015-11-26 23:39                               ` Hans-Peter Nilsson
2015-11-27  1:04                                 ` David Wohlferd
2015-11-20 16:41                   ` Jeff Law

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=56493010.9070707@LimeGreenSocks.com \
    --to=dw@limegreensocks.com \
    --cc=gcc@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=pinskia@gcc.gnu.org \
    --cc=rth@gcc.gnu.org \
    --cc=sandra@codesourcery.com \
    --cc=segher@kernel.crashing.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).