basic asm and memory clobbers

basic asm and memory clobbers

[David Wohlferd]

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

It seems like a doc update is what is needed to close PR24414 (Old-style 
asms don't clobber memory).  I'm working on this now (phase 1) in the 
unlikely event that someone is inspired to make a code change here instead.

Like  Richard Henderson, I rather expected basic (or "old-style") asm to 
perform a memory clobber (it doesn't).  This bug is now over a decade 
old, so presumably the question of how this is going to work is 
settled.  IAC, the docs should reflect the current behavior.

Based on this issue plus what I have learned since last updating this 
page, I'm proposing the attached patch.

dw

CCing the commenters from the bug.

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

Index: extend.texi
===================================================================
--- extend.texi	(revision 229910)
+++ extend.texi	(working copy)
@@ -7353,7 +7353,8 @@
 @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 
+complex than it may appear. To access C data (including both local and
+global register variables), use extended
 @code{asm}.
 
 Do not expect a sequence of @code{asm} statements to remain perfectly 
@@ -7376,6 +7377,12 @@
 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, although they do implicitly perform a clobber of the flags
+(@pxref{Clobbers}). Also, there is no implicit clobbering of registers,
+so any registers changed 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

Re: basic asm and memory clobbers

[Segher Boessenkool]

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.

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; if you really think it needs mentioning here, put
it at the end (in its own sentence), don't break up this sentence.

(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:

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


Segher

Re: basic asm and memory clobbers

[David Wohlferd]

[-- 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

Re: basic asm and memory clobbers

[Jeff Law]

On 11/15/2015 06:23 PM, David Wohlferd wrote:
> 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.
I'd disagree.  A traditional asm has to be considered an opaque blob 
that read/write/clobber any register or memory location.

It's also the case that assuming an old style asm can read or clobber 
any memory location is the safe, conservative thing to do.  So the right 
thing in my mind is to ensure that behaviour and document it.

Andrew's logic is just plain wrong in that BZ.


>
>> 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.
Having an traditional asm clobber memory should not break user code.  It 
may pessimize it slightly, but if it does, that code was already broken.

>> (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.
Sadly, I suspect this isn't consistent across targets.

Jeff

Re: basic asm and memory clobbers

[David Wohlferd]

On 11/16/2015 1:29 PM, Jeff Law wrote:
> On 11/15/2015 06:23 PM, David Wohlferd wrote:
>> 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.
> I'd disagree.  A traditional asm has to be considered an opaque blob 
> that read/write/clobber any register or memory location.

When I first encountered basic asm, my expectation was that of course it 
clobbers.  It HAS to, right?  But that said, let me give my best devil's 
advocate impersonation and ask: Why?

- There is no standard that says it must do this.
- I'm only aware of 1 person who has ever asked for this change. And the 
request has been deemed so unimportant it has languished for a very long 
time.
- There is a plausible work-around with extended asm, which (mostly) has 
clear semantics regarding clobbers.
- While the change probably won't introduce bad code, if it does it will 
be in ways that are going to be difficult to track down, in an area 
where few have the expertise to debug.
- Existing code that currently does things 'right' (ie push/pop any 
modified registers) will suddenly be doing things 'wrong,' or at least 
wastefully.
- Other than top-level asm, it seems like every existing basic asm will 
(probably) get a new performance penalty (memory usage + code size + 
cycles) to allow for situations they may already be handling correctly 
or that don't apply.

True, these aren't particularly compelling reasons to not make the 
change.  But I also don't see any compelling benefits to offset them.

For existing users, presumably they have already found whatever solution 
they need and will just be annoyed that they have to revisit their code 
to see the impact of this change.  Will they need to #if to ensure 
consistent performance/function between gcc versions?  For future users, 
they will have the docs telling them the behavior, and pointing them to 
the (now well documented) extended asm.  Where's the benefit?

If someone were proposing basic asm as a new feature, I'd absolutely be 
arguing that it should clobber everything.  Or I might argue that basic 
asm should only be allowed at top-level (where I don't believe 
clobbering matters?) and everything else should be extended asm so we 
KNOW what to clobber (hmm...).

But changing this so gcc tries (probably futilely) to emulate other 
implementations of asm...  That seems like a weak case to support a 
change to this long-time behavior.  Unless there are other benefits I'm 
just not seeing?

--------------
Ok, that's my best shot.  You have way more expertise and experience 
here than I do, so I expect that after you think it over, you'll make 
the right call.  And despite my attempt here to defend the opposite 
side, I'm not entirely sure what the right call is.  But these seem like 
the right questions.

Either way, let me know if I can help.

> It's also the case that assuming an old style asm can read or clobber 
> any memory location is the safe, conservative thing to do. 

Well, safe-r.  Even if you make this change, embedding basic asm in C 
routines still seems risky.  Well, riskier than extended which is risky 
enough.

> So the right thing in my mind is to ensure that behaviour 

The right thing in my mind is to find ways to prod people into using 
extended asm instead of basic.  Then they explicitly specify their 
requirements rather than depending on clunky all-or-nothing defaults.

Maybe to the extent of gcc deprecating (non-top level) basic over time 
(-fallow-basic-asm=[none|top|any] where v6 defaults to 'any' and v7 
defaults to 'top').  I'd be surprised if gcc went this way, but that 
doesn't mean it wouldn't be better.

> and document it.

and to document it.

> Andrew's logic is just plain wrong in that BZ.
>
>
>>
>>> 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.
> Having an traditional asm clobber memory should not break user code.  
> It may pessimize it slightly, but if it does, that code was already 
> broken.

How much pessimism are we talking here?  Wouldn't clobbering everything 
effectively force the reloading of (some? most? all?) registers?  And 
more memory will be needed to store things that used to just require 
registers?  Along with a few more memory writes?  A single line of basic 
asm, even a comment, could have a non-trivial impact on the code that 
gets generated.

One common use I've seen for basic asm is "int $3" on x86 to break into 
the debugger (the basic asm docs use this as a sample). Changing this to 
a clobber-everything will make what used to be a minimally intrusive way 
to debug code into a high impact operation that may obscure the very 
thing being debugged.

I see how this change might save users (at least the ones who don't read 
the docs) some confusion.  Especially ones porting from other compilers 
that have a similar format for asm.  But it's not going to help people 
who come from compilers that allow the asm to directly access C 
variables.  Or that don't use strings and just embed the asm between 
braces.  And if I weren't already using extended asm, the performance 
questions this introduces to basic would probably be enough to push me 
there.

Or is that the intent?

>>> (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.
> Sadly, I suspect this isn't consistent across targets.

Bigger ouch.  I'll follow up on this after the discussion about changing 
basic asm is complete (which may render this moot).

dw

Re: basic asm and memory clobbers

[Andrew Haley]

On 17/11/15 05:55, David Wohlferd wrote:
> How much pessimism are we talking here?  Wouldn't clobbering everything 
> effectively force the reloading of (some? most? all?) registers?  And 
> more memory will be needed to store things that used to just require 
> registers?

No, really not.  It only affects locals whose address has been taken
and is live at that point.

> Along with a few more memory writes?  A single line of basic asm,
> even a comment, could have a non-trivial impact on the code that
> gets generated.
> 
> One common use I've seen for basic asm is "int $3" on x86 to break into 
> the debugger (the basic asm docs use this as a sample). Changing this to 
> a clobber-everything will make what used to be a minimally intrusive way 
> to debug code into a high impact operation that may obscure the very 
> thing being debugged.

I think that's really pretty unlikely.  Besides, if you need a
breakpoint for debugging you really don't want operations to move
across that breakpoint.

Andrew.

Re: basic asm and memory clobbers

[Jeff Law]

On 11/16/2015 10:55 PM, David Wohlferd wrote:
>
> - There is no standard that says it must do this.
True.  But these after all are extensions and extensions have been 
notoriously under-documented through the years.

> - I'm only aware of 1 person who has ever asked for this change. And the
> request has been deemed so unimportant it has languished for a very long
> time.
True.  But I'd say for this case it means it just hasn't been high 
enough on anyone's priority list to get resolved.   I wouldn't be at all 
surprised if Richard filed this bug to ensure that it didn't get lost. 
That's standard development procedure for items we notice, but aren't 
actively working on.

It's unfortunate that Andrew muddied the waters.  Andrew's conclusions, 
particularly in c#6 are simply wrong.


> - There is a plausible work-around with extended asm, which (mostly) has
> clear semantics regarding clobbers.
Converting an old-style asm to extended asm can be painful.  ANd in the 
case of legacy code the conversion process itself is a potential source 
of bugs.




> - While the change probably won't introduce bad code, if it does it will
> be in ways that are going to be difficult to track down, in an area
> where few have the expertise to debug.
> - Existing code that currently does things 'right' (ie push/pop any
> modified registers) will suddenly be doing things 'wrong,' or at least
> wastefully.
> - Other than top-level asm, it seems like every existing basic asm will
> (probably) get a new performance penalty (memory usage + code size +
> cycles) to allow for situations they may already be handling correctly
> or that don't apply.
> True, these aren't particularly compelling reasons to not make the
> change.  But I also don't see any compelling benefits to offset them.
The benefit is traditional asms do the expected thing.  With no way to 
describe dataflow, the only rational behaviour for a traditional asm is 
that it has to be considered a use/clobber of memory and hard registers.

The fact that it wasn't documented that way eons ago is simply a 
documentation bug -- likely due to the fact that back when the 
documentation for traditional asms was written, there were virtually no 
optimizations of memory referencing instructions -- essentially folks 
didn't ponder (much less document) how these asms would interact with 
memory.

In fact, if you go back to the change I made back in 1999 referenced by 
this BZ, you'll find that we had a mis-compilation of code around an ASM 
by a pass to remove redundant stores that had just been significantly 
improved.



>
> For existing users, presumably they have already found whatever solution
> they need and will just be annoyed that they have to revisit their code
> to see the impact of this change.  Will they need to #if to ensure
> consistent performance/function between gcc versions?  For future users,
> they will have the docs telling them the behavior, and pointing them to
> the (now well documented) extended asm.  Where's the benefit?
Existing users have to change nothing when we fix 24414.  The whole 
point behind 24414 is to point out a case where we are not honoring the 
uses/clobbers all hard regs and memory semantics of traditional asms.


>
> But changing this so gcc tries (probably futilely) to emulate other
> implementations of asm...  That seems like a weak case to support a
> change to this long-time behavior.  Unless there are other benefits I'm
> just not seeing?
When we fix 24414 by honoring the "uses/clobbers all hard registers and 
memory" semantics for old-style asms, those old-style asms will be 
*less* likely to cause problems in the presence of ever-improving 
optimization techniques.


>
> --------------
> Ok, that's my best shot.  You have way more expertise and experience
> here than I do, so I expect that after you think it over, you'll make
> the right call.  And despite my attempt here to defend the opposite
> side, I'm not entirely sure what the right call is.  But these seem like
> the right questions.
>
> Either way, let me know if I can help.
About the only immediate task would be to ensure that the documentation 
for traditional asms clearly documents the desired semantics and somehow 
note that there are known bugs in the implementation (ie 24414, handling 
of flags registers, and probably other oddities)

>>>> 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.
>> Having an traditional asm clobber memory should not break user code.
>> It may pessimize it slightly, but if it does, that code was already
>> broken.
>
> How much pessimism are we talking here?  Wouldn't clobbering everything
> effectively force the reloading of (some? most? all?) registers?  And
> more memory will be needed to store things that used to just require
> registers?  Along with a few more memory writes?  A single line of basic
> asm, even a comment, could have a non-trivial impact on the code that
> gets generated.
Essentially it means that old style asms become a point where the 
compiler has  to assume that memory and hard registers are 
read/clobbered.   Without going into all the details the asm essentially 
invalidates information the compiler might be tracking about the value 
in memory locations or hard registers.

So given two stores to the same memory location on opposite sides of the 
traditional asm, the compiler is _not_ allowed to remove the first store 
(because the traditional asm might read the value).  Nor is the compiler 
allowed to remove the second store (because the asm might have stored a 
value into that location).

Similar situations occur when reading memory locations.

>
> One common use I've seen for basic asm is "int $3" on x86 to break into
> the debugger (the basic asm docs use this as a sample). Changing this to
> a clobber-everything will make what used to be a minimally intrusive way
> to debug code into a high impact operation that may obscure the very
> thing being debugged.
Actually in that specific case, ensuring everything is consistent is 
actually a *good* thing.  And I suspect it's still a lot less intrusive 
than you might think.

>>>> +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.
>> Sadly, I suspect this isn't consistent across targets.
>
> Bigger ouch.  I'll follow up on this after the discussion about changing
> basic asm is complete (which may render this moot).
It likely depends on how the target models the flags.

jeff

Re: basic asm and memory clobbers

[Andrew Pinski]

On Wed, Nov 18, 2015 at 5:31 AM, Jeff Law <law@redhat.com> wrote:
> On 11/16/2015 10:55 PM, David Wohlferd wrote:
>>
>>
>> - There is no standard that says it must do this.
>
> True.  But these after all are extensions and extensions have been
> notoriously under-documented through the years.
>
>> - I'm only aware of 1 person who has ever asked for this change. And the
>> request has been deemed so unimportant it has languished for a very long
>> time.
>
> True.  But I'd say for this case it means it just hasn't been high enough on
> anyone's priority list to get resolved.   I wouldn't be at all surprised if
> Richard filed this bug to ensure that it didn't get lost. That's standard
> development procedure for items we notice, but aren't actively working on.
>
> It's unfortunate that Andrew muddied the waters.  Andrew's conclusions,
> particularly in c#6 are simply wrong.


Sorry about that.  I have since changed my views on this matter to say
old-style asm should clobber memory.  I should have written this
sooner but I have been busy with other things.

Thanks,
Andrew

>
>
>> - There is a plausible work-around with extended asm, which (mostly) has
>> clear semantics regarding clobbers.
>
> Converting an old-style asm to extended asm can be painful.  ANd in the case
> of legacy code the conversion process itself is a potential source of bugs.
>
>
>
>
>> - While the change probably won't introduce bad code, if it does it will
>> be in ways that are going to be difficult to track down, in an area
>> where few have the expertise to debug.
>> - Existing code that currently does things 'right' (ie push/pop any
>> modified registers) will suddenly be doing things 'wrong,' or at least
>> wastefully.
>> - Other than top-level asm, it seems like every existing basic asm will
>> (probably) get a new performance penalty (memory usage + code size +
>> cycles) to allow for situations they may already be handling correctly
>> or that don't apply.
>> True, these aren't particularly compelling reasons to not make the
>> change.  But I also don't see any compelling benefits to offset them.
>
> The benefit is traditional asms do the expected thing.  With no way to
> describe dataflow, the only rational behaviour for a traditional asm is that
> it has to be considered a use/clobber of memory and hard registers.
>
> The fact that it wasn't documented that way eons ago is simply a
> documentation bug -- likely due to the fact that back when the documentation
> for traditional asms was written, there were virtually no optimizations of
> memory referencing instructions -- essentially folks didn't ponder (much
> less document) how these asms would interact with memory.
>
> In fact, if you go back to the change I made back in 1999 referenced by this
> BZ, you'll find that we had a mis-compilation of code around an ASM by a
> pass to remove redundant stores that had just been significantly improved.
>
>
>
>>
>> For existing users, presumably they have already found whatever solution
>> they need and will just be annoyed that they have to revisit their code
>> to see the impact of this change.  Will they need to #if to ensure
>> consistent performance/function between gcc versions?  For future users,
>> they will have the docs telling them the behavior, and pointing them to
>> the (now well documented) extended asm.  Where's the benefit?
>
> Existing users have to change nothing when we fix 24414.  The whole point
> behind 24414 is to point out a case where we are not honoring the
> uses/clobbers all hard regs and memory semantics of traditional asms.
>
>
>>
>> But changing this so gcc tries (probably futilely) to emulate other
>> implementations of asm...  That seems like a weak case to support a
>> change to this long-time behavior.  Unless there are other benefits I'm
>> just not seeing?
>
> When we fix 24414 by honoring the "uses/clobbers all hard registers and
> memory" semantics for old-style asms, those old-style asms will be *less*
> likely to cause problems in the presence of ever-improving optimization
> techniques.
>
>
>>
>> --------------
>> Ok, that's my best shot.  You have way more expertise and experience
>> here than I do, so I expect that after you think it over, you'll make
>> the right call.  And despite my attempt here to defend the opposite
>> side, I'm not entirely sure what the right call is.  But these seem like
>> the right questions.
>>
>> Either way, let me know if I can help.
>
> About the only immediate task would be to ensure that the documentation for
> traditional asms clearly documents the desired semantics and somehow note
> that there are known bugs in the implementation (ie 24414, handling of flags
> registers, and probably other oddities)
>
>>>>> 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.
>>>
>>> Having an traditional asm clobber memory should not break user code.
>>> It may pessimize it slightly, but if it does, that code was already
>>> broken.
>>
>>
>> How much pessimism are we talking here?  Wouldn't clobbering everything
>> effectively force the reloading of (some? most? all?) registers?  And
>> more memory will be needed to store things that used to just require
>> registers?  Along with a few more memory writes?  A single line of basic
>> asm, even a comment, could have a non-trivial impact on the code that
>> gets generated.
>
> Essentially it means that old style asms become a point where the compiler
> has  to assume that memory and hard registers are read/clobbered.   Without
> going into all the details the asm essentially invalidates information the
> compiler might be tracking about the value in memory locations or hard
> registers.
>
> So given two stores to the same memory location on opposite sides of the
> traditional asm, the compiler is _not_ allowed to remove the first store
> (because the traditional asm might read the value).  Nor is the compiler
> allowed to remove the second store (because the asm might have stored a
> value into that location).
>
> Similar situations occur when reading memory locations.
>
>>
>> One common use I've seen for basic asm is "int $3" on x86 to break into
>> the debugger (the basic asm docs use this as a sample). Changing this to
>> a clobber-everything will make what used to be a minimally intrusive way
>> to debug code into a high impact operation that may obscure the very
>> thing being debugged.
>
> Actually in that specific case, ensuring everything is consistent is
> actually a *good* thing.  And I suspect it's still a lot less intrusive than
> you might think.
>
>>>>> +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.
>>>
>>> Sadly, I suspect this isn't consistent across targets.
>>
>>
>> Bigger ouch.  I'll follow up on this after the discussion about changing
>> basic asm is complete (which may render this moot).
>
> It likely depends on how the target models the flags.
>
> jeff

Re: basic asm and memory clobbers

[Segher Boessenkool]

On Tue, Nov 17, 2015 at 02:31:29PM -0700, Jeff Law wrote:
> >- There is a plausible work-around with extended asm, which (mostly) has
> >clear semantics regarding clobbers.
> Converting an old-style asm to extended asm can be painful.  ANd in the 
> case of legacy code the conversion process itself is a potential source 
> of bugs.

> >- While the change probably won't introduce bad code, if it does it will
> >be in ways that are going to be difficult to track down, in an area
> >where few have the expertise to debug.
> >- Existing code that currently does things 'right' (ie push/pop any
> >modified registers) will suddenly be doing things 'wrong,' or at least
> >wastefully.

Basic asm does not do this, and hasn't for a very long time.  So there
simply cannot be existing users that rely on this behaviour.  fwprop1
removes the save/restore already, in most cases.

> The fact that it wasn't documented that way eons ago is simply a 
> documentation bug -- likely due to the fact that back when the 
> documentation for traditional asms was written, there were virtually no 
> optimizations of memory referencing instructions -- essentially folks 
> didn't ponder (much less document) how these asms would interact with 
> memory.

_Does_ basic asm as currently implemented have a memory clobber?  If not,
it seems we can just remove basic asm completely and everything would
still work the same!


Segher

Re: basic asm and memory clobbers

[Jeff Law]

On 11/17/2015 03:07 PM, Andrew Pinski wrote:
> On Wed, Nov 18, 2015 at 5:31 AM, Jeff Law <law@redhat.com> wrote:
>> On 11/16/2015 10:55 PM, David Wohlferd wrote:
>>>
>>>
>>> - There is no standard that says it must do this.
>>
>> True.  But these after all are extensions and extensions have been
>> notoriously under-documented through the years.
>>
>>> - I'm only aware of 1 person who has ever asked for this change. And the
>>> request has been deemed so unimportant it has languished for a very long
>>> time.
>>
>> True.  But I'd say for this case it means it just hasn't been high enough on
>> anyone's priority list to get resolved.   I wouldn't be at all surprised if
>> Richard filed this bug to ensure that it didn't get lost. That's standard
>> development procedure for items we notice, but aren't actively working on.
>>
>> It's unfortunate that Andrew muddied the waters.  Andrew's conclusions,
>> particularly in c#6 are simply wrong.
>
>
> Sorry about that.  I have since changed my views on this matter to say
> old-style asm should clobber memory.  I should have written this
> sooner but I have been busy with other things.
I certainly understand being busy with other things.  Thanks for chiming 
in and clarifying your current thoughts.

Jeff

Re: basic asm and memory clobbers

[Jeff Law]

On 11/17/2015 06:28 PM, Segher Boessenkool wrote:
>
> _Does_ basic asm as currently implemented have a memory clobber?  If not,
> it seems we can just remove basic asm completely and everything would
> still work the same!
You'd have to dig into the various optimizers -- I know that it has a 
memory use in DSE, but I haven't audited the optimizers thoroughly.  In 
fact, the whole point behind the PR in question is there's at least one 
optimizer that is missing that check.

Jeff

Re: basic asm and memory clobbers

[David Wohlferd]

>> Unless there are other benefits I'm just not seeing?
> When we fix 24414 by honoring the "uses/clobbers all hard registers 
> and memory" semantics for old-style asms, those old-style asms will be 
> *less* likely to cause problems in the presence of ever-improving 
> optimization techniques.

Ok, this is a good point.  In fact, it may resolve existing problems 
that people don't know they have.

However I still have concerns that people might be surprised by the 
change in behavior.  Looking thru the linux kernel source (a significant 
collection of inline asm containing both basic (~878) and extended 
(4833) statements), it seems there are places where they really are 
going to want the "clobber nothing" semantics.

For that reason, I'd like to propose adding 2 new clobbers to extended 
asm as part of this work:

"clobberall" - This gives extended the same semantics as whatever the 
new basic asm will be using.
"clobbernone" - This gives the same semantics as the current basic asm.

Clobbernone may seem redundant, since not specifying any clobbers should 
do the same thing.  But actually it doesn't, at least on i386.  At 
present, there is no way for extended asm to not clobber "cc".  I don't 
know if other platforms have similar issues.

When basic asm changes, I expect that having a way to "just do what it 
used to do" is going to be useful for some people.

>> Either way, let me know if I can help.
> About the only immediate task would be to ensure that the 
> documentation for traditional asms clearly documents the desired 
> semantics and somehow note that there are known bugs in the 
> implementation (ie 24414, handling of flags registers, and probably 
> other oddities)

Given that gcc is at phase 3, I'm guessing this work won't be in v6?  Or 
would this be considered "general bugfixing?"

The reason I ask is I want to clearly document what the current behavior 
is as well as informing them about what's coming.  If this isn't 
changing until v7, the text can be updated then to reflect the new behavior.

> And I suspect it's still a lot less intrusive than you might think.

I tried to picture the most basic case I can think of that uses 
something clobber-able:

    for (int x=0; x < 1000; x++)
       asm("#stuff");

This generates very simple and highly performant code:

         movl    $1000, %eax
.L2:
         #stuff
         subl    $1, %eax
         jne     .L2

Using extended asm to simulate the clobberall gives:

         movl    $1000, 44(%rsp)
.L2:
         #stuff
         subl    $1, 44(%rsp)
         jne     .L2

It allocates an extra 4 bytes, and changed everything to memory accesses 
instead of using a register.  Obviously not a huge performance impact on 
this tiny sample, but it does suggest to me that sometimes there could be.

My point being simply that people may want the old behavior, so we need 
to be sure there's a way to get it (ie "clobbernone").

>>>>> +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.
>>> Sadly, I suspect this isn't consistent across targets.
>>
>> Bigger ouch.  I'll follow up on this after the discussion about changing
>> basic asm is complete (which may render this moot).
> It likely depends on how the target models the flags.

I'm not quite sure how to proceed here.  I'm pretty sure no one wants me 
to write "basic asm doesn't clobber flags, except that maybe it does on 
some (unspecified) platforms."

I've tried to follow the code, but without any particular success. I was 
hoping to see decode_reg_name_and_count (or decode_reg_name) being 
called from platform-specific routines and handling -3, but not so much.

Using users as beta testers is normally frowned upon (outside of 
Microsoft), but perhaps the solution here is to just say that it doesn't 
clobber flags (currently the most common case?), and update the docs if 
and when people complain?  Yes, that's bad, but saying nothing at all 
isn't any better.  And we know it's true for at least 2 platforms.

dw

Re: basic asm and memory clobbers

[Sandra Loosemore]

On 11/19/2015 06:23 PM, David Wohlferd wrote:

>> About the only immediate task would be to ensure that the
>> documentation for traditional asms clearly documents the desired
>> semantics and somehow note that there are known bugs in the
>> implementation (ie 24414, handling of flags registers, and probably
>> other oddities)
>
> Given that gcc is at phase 3, I'm guessing this work won't be in v6?  Or
> would this be considered "general bugfixing?"
>
> The reason I ask is I want to clearly document what the current behavior
> is as well as informing them about what's coming.  If this isn't
> changing until v7, the text can be updated then to reflect the new
> behavior.

Documentation fixes are accepted all the way through Stage 4, since 
there's less risk of introducing regressions in user programs from 
accidental documentation mistakes than code errors.

OTOH, I'd discourage adding anything to the docs about anticipated 
changes in future releases, except possibly to note that certain 
features or behavior are deprecated and may be removed in future 
releases (with a suggestion about what you should do instead).  We've 
already got too many "maybe someday this will be fixed" notes in the 
manual that are not terribly useful to users.

-Sandra

Re: basic asm and memory clobbers

[Segher Boessenkool]

On Thu, Nov 19, 2015 at 05:23:55PM -0800, David Wohlferd wrote:
> For that reason, I'd like to propose adding 2 new clobbers to extended 
> asm as part of this work:
> 
> "clobberall" - This gives extended the same semantics as whatever the 
> new basic asm will be using.
> "clobbernone" - This gives the same semantics as the current basic asm.

I don't think this is necessary or useful.  They are also awful names:
"clobberall" cannot clobber everything (think of the stack pointer),
and "clobbernone" does clobber some (those clobbered by any asm),

> Clobbernone may seem redundant, since not specifying any clobbers should 
> do the same thing.  But actually it doesn't, at least on i386.  At 
> present, there is no way for extended asm to not clobber "cc".  I don't 
> know if other platforms have similar issues.

Some do.  The purpose is to stay compatible with asm written for older
versions of the compiler.

> When basic asm changes, I expect that having a way to "just do what it 
> used to do" is going to be useful for some people.

24414 says the documented behaviour hasn't been true for at least
fourteen years.  It isn't likely anyone is relying on that behaviour.

> but perhaps the solution here is to just say that it doesn't 
> clobber flags (currently the most common case?), and update the docs if 
> and when people complain?  Yes, that's bad, but saying nothing at all 
> isn't any better.  And we know it's true for at least 2 platforms.

Saying nothing at all at least is *correct*.

It isn't necessary for users to know what registers the compiler
considers to be clobbered by an asm, unless they actually clobber
something in the assembler code themselves.  They can write extended
asm in that case.

Maybe you can put that in the doc?  "If you modify any register or
memory, use an extended asm"?  Jeff, do you agree with that?


Segher

Re: basic asm and memory clobbers

[Andrew Haley]

On 20/11/15 01:23, David Wohlferd wrote:
> I tried to picture the most basic case I can think of that uses 
> something clobber-able:
> 
>     for (int x=0; x < 1000; x++)
>        asm("#stuff");
> 
> This generates very simple and highly performant code:
> 
>          movl    $1000, %eax
> .L2:
>          #stuff
>          subl    $1, %eax
>          jne     .L2
> 
> Using extended asm to simulate the clobberall gives:
> 
>          movl    $1000, 44(%rsp)
> .L2:
>          #stuff
>          subl    $1, 44(%rsp)
>          jne     .L2
> 
> It allocates an extra 4 bytes, and changed everything to memory accesses 
> instead of using a register.

Can you show us your code?  I get

xx:
	movl	$1000, %eax
.L2:
	#stuff
	subl	$1, %eax
	jne	.L2
	rep; ret

for

void xx() {
  for (int x=0; x < 1000; x++)
    asm volatile("#stuff" : : : "memory");
}

What you're describing looks like a bug: x doesn't have its address
taken.

Andrew.

Re: basic asm and memory clobbers

[David Wohlferd]

On 11/20/2015 2:17 AM, Andrew Haley wrote:
> On 20/11/15 01:23, David Wohlferd wrote:
>> I tried to picture the most basic case I can think of that uses
>> something clobber-able:
>>
>>      for (int x=0; x < 1000; x++)
>>         asm("#stuff");
>>
>> This generates very simple and highly performant code:
>>
>>           movl    $1000, %eax
>> .L2:
>>           #stuff
>>           subl    $1, %eax
>>           jne     .L2
>>
>> Using extended asm to simulate the clobberall gives:
>>
>>           movl    $1000, 44(%rsp)
>> .L2:
>>           #stuff
>>           subl    $1, 44(%rsp)
>>           jne     .L2
>>
>> It allocates an extra 4 bytes, and changed everything to memory accesses
>> instead of using a register.
> Can you show us your code?  I get
>
> xx:
> 	movl	$1000, %eax
> .L2:
> 	#stuff
> 	subl	$1, %eax
> 	jne	.L2
> 	rep; ret
>
> for
>
> void xx() {
>    for (int x=0; x < 1000; x++)
>      asm volatile("#stuff" : : : "memory");
> }
>
> What you're describing looks like a bug: x doesn't have its address
> taken.

The intent for 24414 is to change basic asm such that it will become 
(quoting jeff) "an opaque blob that read/write/clobber any register or 
memory location."  Such being the case, "memory" is not sufficient:

#define CLOBBERALL "eax", "ebx", "ecx", "edx", "r8", "r9", "r10", "r11", 
"r12", "r13", "r14", "r15", "edi", "esi", "ebp", "cc", "memory"

int main()
{
    for (int x=0; x < 1000; x++)
       asm("#":::CLOBBERALL);
}

dw

Re: basic asm and memory clobbers

[David Wohlferd]

On 11/19/2015 7:14 PM, Segher Boessenkool wrote:
> On Thu, Nov 19, 2015 at 05:23:55PM -0800, David Wohlferd wrote:
>> For that reason, I'd like to propose adding 2 new clobbers to extended
>> asm as part of this work:
>>
>> "clobberall" - This gives extended the same semantics as whatever the
>> new basic asm will be using.
>> "clobbernone" - This gives the same semantics as the current basic asm.
> I don't think this is necessary or useful.  They are also awful names:
> "clobberall" cannot clobber everything (think of the stack pointer),

I'm not emotionally attached to the names.  But providing the same 
capability to extended that we are proposing for basic doesn't seem so 
odd.  Shouldn't extended be able to do (at least) everything basic does?

My first thought is that it allows people to incrementally start 
migrating from (new) basic to extended (something I think we should 
encourage).  Or use it as a debug tool to see if the failure you are 
experiencing from your asm is due to a missing clobber.  Since the 
capability will already be implemented for basic, providing a way to 
access it from extended seems trivial (if we can agree on a name).

As you say, clobbering the stack pointer presents special challenges 
(although gcc has a specific way of dealing with stack register 
clobbers, see 52813).  This is why I described the feature as having 
"the same semantics as whatever the new basic asm will be using."

> and "clobbernone" does clobber some (those clobbered by any asm),

Seems like a quibble.  Those other things (I assume you mean things like 
pipelining?) most users aren't even aware of (or they wouldn't be so 
eager to use inline asm in the first place).  Would it be more palatable 
if we called it "v5BasicAsmMode"?  "ClobberMin"?

>> Clobbernone may seem redundant, since not specifying any clobbers should
>> do the same thing.  But actually it doesn't, at least on i386.  At
>> present, there is no way for extended asm to not clobber "cc".  I don't
>> know if other platforms have similar issues.
> Some do.  The purpose is to stay compatible with asm written for older
> versions of the compiler.

Backward compatibility is important.  I understand that due to the cc0 
change in x86, existing code may have broken without always clobbering 
cc.  This was seen as the safest way to ensure that didn't happen.  
However no solution was/is available for people who correctly knew 
whether their asm clobbers the flags.

Mostly I'm ok with that.  All the ways that I can think of to try to 
re-allow people to start using the cc clobber are just not worth it.  I 
simply can't believe there are many cases where there's going to be a 
benefit.

But as I said: backward compatibility is important.  Providing a way for 
people who need/want the old basic asm semantics seems useful. And I 
don't believe we can (quite) do that without clobbernone.

>> When basic asm changes, I expect that having a way to "just do what it
>> used to do" is going to be useful for some people.
> 24414 says the documented behaviour hasn't been true for at least
> fourteen years.  It isn't likely anyone is relying on that behaviour.

?

To my knowledge, there was no documentation of any sort about what basic 
asm clobbered until I added it.  But what people are (presumably) 
relying on is that whatever it did in the last version, it's going to 
continue to do that in the next.  And albeit with good intentions, we 
are planning on changing that.

>> but perhaps the solution here is to just say that it doesn't
>> clobber flags (currently the most common case?), and update the docs if
>> and when people complain?  Yes, that's bad, but saying nothing at all
>> isn't any better.  And we know it's true for at least 2 platforms.
> Saying nothing at all at least is *correct*.

We don't know that saying "it doesn't clobber flags" is wrong either.  
All we know is that jeff said "I suspect this isn't consistent across 
targets."

But that's neither here nor there.  The real question is, if we can't 
say that, what can we say?

- If 24414 is going in v6, then we can doc that it does the clobber and 
be vague about the old behavior.
- If 24414 isn't going in v6, then what?  I suppose we can say that it 
can vary by platform.  We could even provide your sample code as a means 
for people to discover their platform's behavior.

> It isn't necessary for users to know what registers the compiler
> considers to be clobbered by an asm, unless they actually clobber
> something in the assembler code themselves.

I'm not sure I follow.

If someone has code that uses a register, currently they must restore 
the value before exiting the asm or risk disaster.  So they might write 
asm("push eax ; DoSomethingWith eax ; pop eax"). However if you know 
that the compiler is going to clobber eax, then the push/pop is just a 
waste of cycles and memory.

To write efficient code, it seems like you do need to know what the 
compiler clobbers.

> They can write extended asm in that case.

I agree that if they did that it would solve the problem.  But...

> Maybe you can put that in the doc?  "If you modify any register or
> memory, use an extended asm"?  Jeff, do you agree with that?

Well, I'm already on record as saying I think any asm that isn't top 
level should be extended, so I'm pretty much ok with that.

But that raises the question:

- If this is the requirement for using basic asm, why do we need to 
change its behavior at all?  Yes, code that uses registers or memory 
might fail due to optimizations, but such code would be in violation of 
supported usage.
- If registers and memory access are still supported in basic asm, 
what's the point of doc'ing that you can't?

dw

Re: basic asm and memory clobbers

[Andrew Haley]

On 20/11/15 10:37, David Wohlferd wrote:
> The intent for 24414 is to change basic asm such that it will become 
> (quoting jeff) "an opaque blob that read/write/clobber any register or 
> memory location."  Such being the case, "memory" is not sufficient:
> 
> #define CLOBBERALL "eax", "ebx", "ecx", "edx", "r8", "r9", "r10", "r11", 
> "r12", "r13", "r14", "r15", "edi", "esi", "ebp", "cc", "memory"

Hmm.  I would not be at all surprised to see this cause reload
failures.  You certainly shouldn't clobber the frame pointer on
any machine which needs one.

Andrew.

Re: basic asm and memory clobbers

[David Wohlferd]

On 11/20/2015 3:14 AM, Andrew Haley wrote:
> On 20/11/15 10:37, David Wohlferd wrote:
>> The intent for 24414 is to change basic asm such that it will become
>> (quoting jeff) "an opaque blob that read/write/clobber any register or
>> memory location."  Such being the case, "memory" is not sufficient:
>>
>> #define CLOBBERALL "eax", "ebx", "ecx", "edx", "r8", "r9", "r10", "r11",
>> "r12", "r13", "r14", "r15", "edi", "esi", "ebp", "cc", "memory"
> Hmm.  I would not be at all surprised to see this cause reload
> failures.  You certainly shouldn't clobber the frame pointer on
> any machine which needs one.

If I don't clobber ebp, gcc just uses it:

         movl    $1000, %ebp
.L2:
         #
         subl    $1, %ebp
         jne     .L2

The original purpose of this code was to attempt to show that this kind 
of "clobbering everything" behavior (the proposed new behavior for basic 
asm) could have non-trivial impact on existing routines. While I've been 
told that changing the existing "clobber nothing" approach to this kind 
of "clobber everything" is "less intrusive than you might think," I'm 
struggling to believe it.  It seems to me that one asm("nop") thrown 
into a driver routine to fix a timing problem could end up making a real 
mess.

But actually we're kind of past that.  When Jeff, Segher, (other) Andrew 
and Richard all say "this is how it's going to work," it's time for me 
to set aside my reservations and move on.

So now I'm just trying my best to make sure that if it *is* an issue, 
people have a viable solution readily available.  And to make sure it's 
all correctly doc'ed (which is what started this whole mess).

dw

Re: basic asm and memory clobbers

[Richard Henderson]

On 11/20/2015 01:38 PM, David Wohlferd wrote:
> On 11/20/2015 3:14 AM, Andrew Haley wrote:
>> On 20/11/15 10:37, David Wohlferd wrote:
>>> The intent for 24414 is to change basic asm such that it will become
>>> (quoting jeff) "an opaque blob that read/write/clobber any register or
>>> memory location."  Such being the case, "memory" is not sufficient:
>>>
>>> #define CLOBBERALL "eax", "ebx", "ecx", "edx", "r8", "r9", "r10", "r11",
>>> "r12", "r13", "r14", "r15", "edi", "esi", "ebp", "cc", "memory"
>> Hmm.  I would not be at all surprised to see this cause reload
>> failures.  You certainly shouldn't clobber the frame pointer on
>> any machine which needs one.
>
> If I don't clobber ebp, gcc just uses it:
>
>          movl    $1000, %ebp
> .L2:
>          #
>          subl    $1, %ebp
>          jne     .L2

I believe you'd have to have magic in there to conditionally clobber the 
register if it isn't being used as a frame pointer.

That said...

> The original purpose of this code was to attempt to show that this kind of
> "clobbering everything" behavior (the proposed new behavior for basic asm)
> could have non-trivial impact on existing routines. While I've been told that
> changing the existing "clobber nothing" approach to this kind of "clobber
> everything" is "less intrusive than you might think," I'm struggling to believe
> it.  It seems to me that one asm("nop") thrown into a driver routine to fix a
> timing problem could end up making a real mess.
>
> But actually we're kind of past that.  When Jeff, Segher, (other) Andrew and
> Richard all say "this is how it's going to work," it's time for me to set aside
> my reservations and move on.
>
> So now I'm just trying my best to make sure that if it *is* an issue, people
> have a viable solution readily available.  And to make sure it's all correctly
> doc'ed (which is what started this whole mess).

I'd be perfectly happy to deprecate and later completely remove basic asm 
within functions.

Because IMO it's essentially useless.  It has no inputs, no outputs, and no way 
to tell the compiler what machine state has been changed.  We can say that "it 
clobbers everything", but that's not actually useful, and quite difficult as 
you're finding out.

It seems to me that it would be better to remove the feature, forcing what must 
be an extremely small number of users to audit and update to extended asm.



r~

Re: basic asm and memory clobbers

[Segher Boessenkool]

On Fri, Nov 20, 2015 at 02:45:05AM -0800, David Wohlferd wrote:
> On 11/19/2015 7:14 PM, Segher Boessenkool wrote:
> >On Thu, Nov 19, 2015 at 05:23:55PM -0800, David Wohlferd wrote:
> >>For that reason, I'd like to propose adding 2 new clobbers to extended
> >>asm as part of this work:
> >>
> >>"clobberall" - This gives extended the same semantics as whatever the
> >>new basic asm will be using.
> >>"clobbernone" - This gives the same semantics as the current basic asm.
> >I don't think this is necessary or useful.  They are also awful names:
> >"clobberall" cannot clobber everything (think of the stack pointer),
> 
> I'm not emotionally attached to the names.

Names should be succinct, clear, and give a good indication of what the
thing named does.  If it is hard to make a good name it is likely that
the interface isn't so well designed.

> But providing the same 
> capability to extended that we are proposing for basic doesn't seem so 
> odd.  Shouldn't extended be able to do (at least) everything basic does?

But that would be logical!  Can't have that.  Heh.

> As you say, clobbering the stack pointer presents special challenges 
> (although gcc has a specific way of dealing with stack register 
> clobbers, see 52813).

Yeah.  Actually, basic asm is handled specially in many places, too.

> >and "clobbernone" does clobber some (those clobbered by any asm),
> 
> Seems like a quibble.  Those other things (I assume you mean things like 
> pipelining?) most users aren't even aware of (or they wouldn't be so 
> eager to use inline asm in the first place).  Would it be more palatable 
> if we called it "v5BasicAsmMode"?  "ClobberMin"?

I meant things like x86 "cc".

> >>Clobbernone may seem redundant, since not specifying any clobbers should
> >>do the same thing.  But actually it doesn't, at least on i386.  At
> >>present, there is no way for extended asm to not clobber "cc".  I don't
> >>know if other platforms have similar issues.
> >Some do.  The purpose is to stay compatible with asm written for older
> >versions of the compiler.
> 
> Backward compatibility is important.  I understand that due to the cc0 
> change in x86, existing code may have broken without always clobbering 
> cc.  This was seen as the safest way to ensure that didn't happen.  
> However no solution was/is available for people who correctly knew 
> whether their asm clobbers the flags.
> 
> Mostly I'm ok with that.  All the ways that I can think of to try to 
> re-allow people to start using the cc clobber are just not worth it.  I 
> simply can't believe there are many cases where there's going to be a 
> benefit.

Exactly.  The asm still can be moved "over" other uses of CC, it does
not limit transformations much at all.

> But as I said: backward compatibility is important.  Providing a way for 
> people who need/want the old basic asm semantics seems useful. And I 
> don't believe we can (quite) do that without clobbernone.
> 
> >>When basic asm changes, I expect that having a way to "just do what it
> >>used to do" is going to be useful for some people.
> >24414 says the documented behaviour hasn't been true for at least
> >fourteen years.  It isn't likely anyone is relying on that behaviour.
> 
> ?

24414 says these things haven't worked since at least 2.95.3, which is
fourteen years old now.

> >It isn't necessary for users to know what registers the compiler
> >considers to be clobbered by an asm, unless they actually clobber
> >something in the assembler code themselves.
> 
> I'm not sure I follow.

If the assembler code does not clobber some register, but GCC treats it
as if it does, things will work correctly.


Segher

Re: basic asm and memory clobbers

[Segher Boessenkool]

On Fri, Nov 20, 2015 at 02:05:01PM +0100, Richard Henderson wrote:
> I'd be perfectly happy to deprecate and later completely remove basic asm 
> within functions.
> 
> Because IMO it's essentially useless.  It has no inputs, no outputs, and no 
> way to tell the compiler what machine state has been changed.  We can say 
> that "it clobbers everything", but that's not actually useful, and quite 
> difficult as you're finding out.
> 
> It seems to me that it would be better to remove the feature, forcing what 
> must be an extremely small number of users to audit and update to extended 
> asm.

Should  asm("bla");  then be an extended asm with no input, no outputs,
no (non-automatic) clobbers?  That would be the most straightforward and
logical semantics, but will it break user code?


Segher

Re: basic asm and memory clobbers

[Richard Henderson]

On 11/20/2015 04:20 PM, Segher Boessenkool wrote:
> On Fri, Nov 20, 2015 at 02:05:01PM +0100, Richard Henderson wrote:
>> I'd be perfectly happy to deprecate and later completely remove basic asm
>> within functions.
>>
>> Because IMO it's essentially useless.  It has no inputs, no outputs, and no
>> way to tell the compiler what machine state has been changed.  We can say
>> that "it clobbers everything", but that's not actually useful, and quite
>> difficult as you're finding out.
>>
>> It seems to me that it would be better to remove the feature, forcing what
>> must be an extremely small number of users to audit and update to extended
>> asm.
>
> Should  asm("bla");  then be an extended asm with no input, no outputs,
> no (non-automatic) clobbers?  That would be the most straightforward and
> logical semantics, but will it break user code?

I'm suggesting that we don't accept that at all inside a function.  One must 
audit the source and make a conscious decision to write asm("bla" : ); instead.

Accepting basic asm outside of a function is perfectly ok, since that's just a 
mechanism by which one can inject complete assembly routines into a C 
translation unit.


r~

Re: basic asm and memory clobbers

[Jakub Jelinek]

On Fri, Nov 20, 2015 at 04:29:50PM +0100, Richard Henderson wrote:
> On 11/20/2015 04:20 PM, Segher Boessenkool wrote:
> >On Fri, Nov 20, 2015 at 02:05:01PM +0100, Richard Henderson wrote:
> >>I'd be perfectly happy to deprecate and later completely remove basic asm
> >>within functions.
> >>
> >>Because IMO it's essentially useless.  It has no inputs, no outputs, and no
> >>way to tell the compiler what machine state has been changed.  We can say
> >>that "it clobbers everything", but that's not actually useful, and quite
> >>difficult as you're finding out.
> >>
> >>It seems to me that it would be better to remove the feature, forcing what
> >>must be an extremely small number of users to audit and update to extended
> >>asm.
> >
> >Should  asm("bla");  then be an extended asm with no input, no outputs,
> >no (non-automatic) clobbers?  That would be the most straightforward and
> >logical semantics, but will it break user code?
> 
> I'm suggesting that we don't accept that at all inside a function.  One must
> audit the source and make a conscious decision to write asm("bla" : );
> instead.
> 
> Accepting basic asm outside of a function is perfectly ok, since that's just
> a mechanism by which one can inject complete assembly routines into a C
> translation unit.

Isn't that going to break too much code though?  I mean, e.g. including
libgcc...

	Jakub

Re: basic asm and memory clobbers

[Richard Henderson]

On 11/20/2015 04:34 PM, Jakub Jelinek wrote:
> Isn't that going to break too much code though?  I mean, e.g. including
> libgcc...

I don't know.  My suspicion is very little.

But that's actually what I'd like to know before we start adjusting code in 
other ways wrt basic asms.


r~

Re: basic asm and memory clobbers

[Segher Boessenkool]

On Fri, Nov 20, 2015 at 04:29:50PM +0100, Richard Henderson wrote:
> >>It seems to me that it would be better to remove the feature, forcing what
> >>must be an extremely small number of users to audit and update to extended
> >>asm.
> >
> >Should  asm("bla");  then be an extended asm with no input, no outputs,
> >no (non-automatic) clobbers?  That would be the most straightforward and
> >logical semantics, but will it break user code?
> 
> I'm suggesting that we don't accept that at all inside a function.  One 
> must audit the source and make a conscious decision to write asm("bla" : ); 
> instead.

Ah, or excepting asm("bla") and treating it just like asm("bla" : ), but
giving a warning?  That will get people to migrate at least.

> Accepting basic asm outside of a function is perfectly ok, since that's 
> just a mechanism by which one can inject complete assembly routines into a 
> C translation unit.

Of course.  You cannot have extended asm outside of functions at all.


Segher

Re: basic asm and memory clobbers

[Jeff Law]

On 11/20/2015 04:14 AM, Andrew Haley wrote:
> On 20/11/15 10:37, David Wohlferd wrote:
>> The intent for 24414 is to change basic asm such that it will become
>> (quoting jeff) "an opaque blob that read/write/clobber any register or
>> memory location."  Such being the case, "memory" is not sufficient:
>>
>> #define CLOBBERALL "eax", "ebx", "ecx", "edx", "r8", "r9", "r10", "r11",
>> "r12", "r13", "r14", "r15", "edi", "esi", "ebp", "cc", "memory"
>
> Hmm.  I would not be at all surprised to see this cause reload
> failures.  You certainly shouldn't clobber the frame pointer on
> any machine which needs one.
Right.  It'll cause other issues as well.  It's the only reason why I 
didn't change the code internally to stomp every hard register back in 1999.

jeff

Re: basic asm and memory clobbers

[Jeff Law]

On 11/20/2015 06:05 AM, Richard Henderson wrote:

>
> I'd be perfectly happy to deprecate and later completely remove basic
> asm within functions.
>
> Because IMO it's essentially useless.  It has no inputs, no outputs, and
> no way to tell the compiler what machine state has been changed.  We can
> say that "it clobbers everything", but that's not actually useful, and
> quite difficult as you're finding out.
And even more difficult to document exactly what happens, largely 
because the implementation in GCC isn't consistent across passes and 
there's differences in behaviour that are dependent on the target 
implementation as well.

Unfortunately there's not a single place where we can ensure consistent 
behaviour, so each pass has had to handle ASMs independently, and I'm 
pretty sure they all get it wrong to varying degrees.


>
> It seems to me that it would be better to remove the feature, forcing
> what must be an extremely small number of users to audit and update to
> extended asm.
That might be a little drastic.  Though if we want to go this direction, 
the first step is to deprecate for a major release cycle.  It would be 
interesting to see how much stuff would complain/break.

jeff

Re: basic asm and memory clobbers

[Paul_Koning]

> On Nov 20, 2015, at 1:24 PM, Jeff Law <law@redhat.com> wrote:
> 
> On 11/20/2015 06:05 AM, Richard Henderson wrote:
> 
>> ...
>> It seems to me that it would be better to remove the feature, forcing
>> what must be an extremely small number of users to audit and update to
>> extended asm.
> That might be a little drastic.  Though if we want to go this direction, the first step is to deprecate for a major release cycle.  It would be interesting to see how much stuff would complain/break.

I would expect: a lot.  I've seen plenty of people writing asm statements (in small quantities, admittedly) who have never heard of extended asm.

	paul

Re: basic asm and memory clobbers

[Jeff Law]

On 11/20/2015 07:56 AM, Segher Boessenkool wrote:

>>>> When basic asm changes, I expect that having a way to "just do what it
>>>> used to do" is going to be useful for some people.
>>> 24414 says the documented behaviour hasn't been true for at least
>>> fourteen years.  It isn't likely anyone is relying on that behaviour.
>>
>> ?
>
> 24414 says these things haven't worked since at least 2.95.3, which is
> fourteen years old now.
That's not a good reason to leave things as-is.

The problem is that optimizers continue to improve.   So an old-style 
asm that worked in the past may mysteriously start failing as folks move 
forward with their compiler -- because we haven't properly implemented 
the right semantics of old-style asms, which is in part because certain 
aspects were never documented properly and partly because of reload 
issues :(

If we keep old style asms, then we need to properly document what their 
behaviour is supposed to be, and continue to fix bugs where we do not 
honor that behaviour.

The latter is somewhat painful because we don't have a single place 
where we can audit & fix any semantic problems.  It's scattered in 
various optimizers throughout GCC.  And I suspect most are getting it 
wrong in one way or another.


Jeff

Re: basic asm and memory clobbers

[Paul_Koning]

> On Nov 20, 2015, at 3:01 PM, Jeff Law <law@redhat.com> wrote:
> 
> On 11/20/2015 07:56 AM, Segher Boessenkool wrote:
> 
>>>>> When basic asm changes, I expect that having a way to "just do what it
>>>>> used to do" is going to be useful for some people.
>>>> 24414 says the documented behaviour hasn't been true for at least
>>>> fourteen years.  It isn't likely anyone is relying on that behaviour.
>>> 
>>> ?
>> 
>> 24414 says these things haven't worked since at least 2.95.3, which is
>> fourteen years old now.
> That's not a good reason to leave things as-is.
> 
> The problem is that optimizers continue to improve.   So an old-style asm that worked in the past may mysteriously start failing as folks move forward with their compiler -- because we haven't properly implemented the right semantics of old-style asms, which is in part because certain aspects were never documented properly and partly because of reload issues :(
> 
> If we keep old style asms, then we need to properly document what their behaviour is supposed to be, and continue to fix bugs where we do not honor that behaviour.

Yes.  I know I've run into cases before where certain documented properties were not honored. I can't find the details right now; I think it was "old style asm always behaves as if marked 'volatile'. "

	paul

Re: basic asm and memory clobbers

[David Wohlferd]

On 11/20/2015 8:14 AM, Richard Henderson wrote:
> On 11/20/2015 04:34 PM, Jakub Jelinek wrote:
>> Isn't that going to break too much code though?  I mean, e.g. including
>> libgcc...
>
> I don't know.  My suspicion is very little.
>
> But that's actually what I'd like to know before we start adjusting 
> code in other ways wrt basic asms.

I can provide a little data here.

In an effort to gain some perspective, I've been looking at inline asm 
usage in the linux kernel (4.3).  Clearly this isn't "typical usage," 
but it is probably one of the biggest users of inline asm, and likely 
has the best justifications for doing so (being an OS and all).

There are ~5,711 instances of inline asm in use.  Of those, ~4,833 are 
extended and ~878 are basic.

I don't have any numbers about how many are top level vs in function, 
but let me see what I can do.

A quick look at libgcc shows that there are 109 extended and 45 basic 
asm statements.  I'll see how many end up being top-level, but it looks 
like most of them.

dw

Re: basic asm and memory clobbers

[David Wohlferd]

On 11/20/2015 3:55 PM, David Wohlferd wrote:
> On 11/20/2015 8:14 AM, Richard Henderson wrote:
>> On 11/20/2015 04:34 PM, Jakub Jelinek wrote:
>>> Isn't that going to break too much code though?  I mean, e.g. including
>>> libgcc...
>>
>> I don't know.  My suspicion is very little.
>>
>> But that's actually what I'd like to know before we start adjusting 
>> code in other ways wrt basic asms.
>
> I can provide a little data here.
>
> In an effort to gain some perspective, I've been looking at inline asm 
> usage in the linux kernel (4.3).  Clearly this isn't "typical usage," 
> but it is probably one of the biggest users of inline asm, and likely 
> has the best justifications for doing so (being an OS and all).
>
> There are ~5,678 instances of inline asm in use.  Of those, ~4,833 are 
> extended and ~845 are basic.
>
> I don't have any numbers about how many are top level vs in function, 
> but let me see what I can do.

Ok, the news here is mixed.  Of those 845:

- Only 50 of them look like top level asm.  I was hoping for more.
- 457 are in 6 files in the lib/raid6 directory, so there's a bunch that 
can be done quickly.
- That leaves 338 miscellaneous other uses spread throughout some 200 
files across multiple platforms.  That seems like a lot.

Despite the concerns expressed by Jeff about the difficulties in 
changing from basic to extended, it looks to me like they don't need any 
conversion (other s/%/%%/).  Adding the trailing colon should be 
sufficient to provide the semantics they have now, which apparently is 
deemed sufficient.

> A quick look at libgcc shows that there are 109 extended and 45 basic 
> asm statements.  I'll see how many end up being top-level, but it 
> looks like most of them.

Of the 45 basic asm statements, only 9 aren't top-level.  They all 
appear to be trivial to change to extended.

To sum up:

- Some projects (like libgcc) are going to be simple to update. Maybe an 
hour's work all told.
- Some projects (like testsuite) are going to take longer.  While the 
changes are mostly straight-forward, the number of files involved will 
be a factor.
- I took a look at the Mingw-w64 project.  It has ~20 non-top level 
asms, so also pretty simple to update.
- But some projects (like linux kernel) are going to be more 
challenging.  Not so much making the changes (although that will take a 
while) as convincing yourself that the change was harmless and still 
compiles on all supported platforms.

Yes, this represents a very limited sample.  And one weighted towards 
projects that are more likely to use asm.  But it does give some sense 
of the scale.

So, what now?

While I'd like to take the big step and start kicking out warnings for 
non-top-level right now, that may be too bold for phase 3.  A more 
modest step for v6 would just provide a way to find them (maybe 
something like -Wnon-top-basic-asm or -Wonly-top-basic-asm) and doc the 
current behavior as well as the upcoming change.

Adding the warning is not something I can do.  But I'll create the doc 
patch once someone confirms that this is the plan.

dw

Re: basic asm and memory clobbers

[David Wohlferd]

On 11/19/2015 5:53 PM, Sandra Loosemore wrote:
> On 11/19/2015 06:23 PM, David Wohlferd wrote:
>
>>> About the only immediate task would be to ensure that the
>>> documentation for traditional asms clearly documents the desired
>>> semantics and somehow note that there are known bugs in the
>>> implementation (ie 24414, handling of flags registers, and probably
>>> other oddities)
>>
>> Given that gcc is at phase 3, I'm guessing this work won't be in v6?  Or
>> would this be considered "general bugfixing?"
>>
>> The reason I ask is I want to clearly document what the current behavior
>> is as well as informing them about what's coming.  If this isn't
>> changing until v7, the text can be updated then to reflect the new
>> behavior.
>
> Documentation fixes are accepted all the way through Stage 4, since 
> there's less risk of introducing regressions in user programs from 
> accidental documentation mistakes than code errors.

The code change isn't yet finalized.  I'm hoping to doc something 
vaguely like:

"basic asm (other than at top level) is being deprecated because <blah 
blah> potentially unsafe due to optimizations <blah blah blah>.  You can 
locate the statements that will no longer be supported using 
-Wonly-top-basic-asm.  Change them to use extended asm instead."

What's your take on having the user guide link to the gcc wiki?  If we 
do make this change, I'd kinda like to create a "how to convert basic 
asm to extended."  But it doesn't seem like a good fit for the user 
docs.  But if the user docs don't reference the wiki, I doubt anyone 
would ever find it.

> OTOH, I'd discourage adding anything to the docs about anticipated 
> changes in future releases, except possibly to note that certain 
> features or behavior are deprecated and may be removed in future 
> releases (with a suggestion about what you should do instead). 

I'd love to see the doc folks make a pass and remove every "some day 
this won't work" text that doesn't include this.  If there is no way for 
users to prepare, you aren't helping.

And remove all the "some day there might be a new feature" stuff too.  
It just wastes users' time trying to figure out if "some day" has 
arrived yet.  And it makes them cry when the new feature, which is 
exactly what they need, isn't there yet.

> We've already got too many "maybe someday this will be fixed" notes in 
> the manual that are not terribly useful to users.

You'd get my vote to remove them all.  If I got a vote.

dw

Re: basic asm and memory clobbers

[Joseph Myers]

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

Note that basic asm is part of the standard C++ syntax.  "An asm 
declaration has the form
asm-definition:
asm ( string-literal ) ;
The asm declaration is conditionally-supported; its meaning is 
implementation-defined. [ Note: Typically
it is used to pass information through the implementation to an assembler. 
— end note ]" (7.4 [dcl.asm]).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: basic asm and memory clobbers

[Andrew Haley]

On 21/11/15 12:56, David Wohlferd wrote:
> So, what now?
> 
> While I'd like to take the big step and start kicking out warnings for 
> non-top-level right now, that may be too bold for phase 3.  A more 
> modest step for v6 would just provide a way to find them (maybe 
> something like -Wnon-top-basic-asm or -Wonly-top-basic-asm) and doc the 
> current behavior as well as the upcoming change.

Warnings would be good.

My warning still holds: there are modes of compilation on some
machines where you can't clobber all registers without causing reload
failures.  This is why Jeff didn't fix this in 1999.  So, if we really
do want to clobber "all" registers in basic asm it'll take a lot of
work.

Andrew.

Re: basic asm and memory clobbers

[Jeff Law]

On 11/23/2015 03:04 AM, Andrew Haley wrote:
> On 21/11/15 12:56, David Wohlferd wrote:
>> So, what now?
>>
>> While I'd like to take the big step and start kicking out warnings for
>> non-top-level right now, that may be too bold for phase 3.  A more
>> modest step for v6 would just provide a way to find them (maybe
>> something like -Wnon-top-basic-asm or -Wonly-top-basic-asm) and doc the
>> current behavior as well as the upcoming change.
>
> Warnings would be good.
>
> My warning still holds: there are modes of compilation on some
> machines where you can't clobber all registers without causing reload
> failures.  This is why Jeff didn't fix this in 1999.  So, if we really
> do want to clobber "all" registers in basic asm it'll take a lot of
> work.
Exactly.  In retrospect, I probably should have generated more tests for 
those conditions back in '99.  Essentially they'd document a class of 
problems we'd like to fix over time.

I know some have been addressed in various forms, but it hasn't been 
systematic.

My recommendation here is to:

   1. Note in the docs what the behaviour should be.  This guides where
   we want to go from an implementation standpoint.  I think it'd be fine
   to *suggest* only using old style asms at the toplevel, but I'm less
   convinced that mandating that restriction is wise.

   2. As we come across failures for adhere to the desired behaviour,
   fix or document them as known inconsistencies.  If we find that some
   are inherently un-fixable, then we'll need to tighten the docs around
   those.


The more I think about it, I'm just not keen on forcing all those 
old-style asms to change.

jeff

Re: basic asm and memory clobbers

[David Wohlferd]

On 11/23/2015 2:04 AM, Andrew Haley wrote:
> On 21/11/15 12:56, David Wohlferd wrote:
>> So, what now?
>>
>> While I'd like to take the big step and start kicking out warnings for
>> non-top-level right now, that may be too bold for phase 3.  A more
>> modest step for v6 would just provide a way to find them (maybe
>> something like -Wnon-top-basic-asm or -Wonly-top-basic-asm) and doc the
>> current behavior as well as the upcoming change.
> Warnings would be good.

Richard's suggestion was:

 > I'm suggesting that we don't accept [basic asm] at all inside a 
function.  One must audit the source and make a conscious decision to 
write asm("bla" : ); instead.  Accepting basic asm outside of a function 
is perfectly ok.

I'm really not a compiler-writer, but I've taken a shot at implementing 
this.  While Richard is talking about completely deprecating this 
feature (a direction I support), I've started by emitting warnings, and 
by having the warnings disabled by default. This allows people to 
experiment with the new direction without getting clobbered by it.  My 
intent is something like this:

-Wonly-top-basic-asm
Warn if basic @code{asm} statements are used inside a function (ie not
at file scope/top level).  Due to the potential for unsafe optimizations,
always use extended instead of basic asm inside functions.  This
warning is disabled by default and is not enabled by -Wall or -Wextra.

I probably won't include the bits about Wall or Wextra in the actual doc 
patch.  They're here more to provoke comments in case someone thinks 
this behavior should change.  I'm open to suggestions about alternate 
names, too.

I've got this working for both c and c++.  It doesn't affect other 
places that use "asm" like "explicit register variables," "asm labels," 
"extended asm" or "top level basic asm."  It is also pleasantly small.  
As written, it should be useful to find places in current code that are 
at risk.

However (there's always a 'however'), it doesn't correctly handle 
"naked" functions (ie __attribute__((naked)) ).  By definition, naked 
functions can *only* include basic asm 
(https://gcc.gnu.org/ml/gcc/2014-05/msg00172.html).  So generating a 
warning for them is incorrect.

I'll need help fixing that.

I don't know if it is possible from within the parsers (where my current 
code is being added) to walk back up and get the attributes for the 
function.  I assume not.  In that case, I'll need some help finding some 
place up the call stack where you can.  Suggestions welcome.

The patch is at http://www.LimeGreenSocks.com/gcc/24414f.zip and 
includes test code.

> My warning still holds: there are modes of compilation on some
> machines where you can't clobber all registers without causing reload
> failures.  This is why Jeff didn't fix this in 1999.  So, if we really
> do want to clobber "all" registers in basic asm it'll take a lot of
> work.

I was always reluctant to see this change made.  In addition to the 
issues you mention, I had questions about the impact on the surrounding 
code.  I like Richard's direction much better.  We can start with a 
disabled warning, then upgrade as seems warranted.

dw

Re: basic asm and memory clobbers

[David Wohlferd]

On 11/23/2015 12:37 PM, Jeff Law wrote:
> On 11/23/2015 03:04 AM, Andrew Haley wrote:
>> On 21/11/15 12:56, David Wohlferd wrote:
>>> So, what now?
>>>
>>> While I'd like to take the big step and start kicking out warnings for
>>> non-top-level right now, that may be too bold for phase 3.  A more
>>> modest step for v6 would just provide a way to find them (maybe
>>> something like -Wnon-top-basic-asm or -Wonly-top-basic-asm) and doc the
>>> current behavior as well as the upcoming change.
>>
>> Warnings would be good.
>>
>> My warning still holds: there are modes of compilation on some
>> machines where you can't clobber all registers without causing reload
>> failures.  This is why Jeff didn't fix this in 1999.  So, if we really
>> do want to clobber "all" registers in basic asm it'll take a lot of
>> work.
> Exactly.  In retrospect, I probably should have generated more tests 
> for those conditions back in '99.  Essentially they'd document a class 
> of problems we'd like to fix over time.
>
> I know some have been addressed in various forms, but it hasn't been 
> systematic.
>
> My recommendation here is to:
>
>   1. Note in the docs what the behaviour should be.  This guides where
>   we want to go from an implementation standpoint.  I think it'd be fine
>   to *suggest* only using old style asms at the toplevel, but I'm less
>   convinced that mandating that restriction is wise.

I hear your concerns about mandating this.  Perhaps starting by 
providing an option to find them, then (someday) enabling that option by 
default?

>   2. As we come across failures for adhere to the desired behaviour,
>   fix or document them as known inconsistencies.  If we find that some
>   are inherently un-fixable, then we'll need to tighten the docs around
>   those.

It's your expectation that extended asm won't be sufficient to resolve 
these issues?

> The more I think about it, I'm just not keen on forcing all those 
> old-style asms to change.

If you mean you aren't keen to change them to "clobber all," I'm with 
you.  If you are worried about changing them from basic to extended, 
what kinds of problems do you foresee?  I've been reading a lot of basic 
asm lately, and it seems to me that most of it would be fine with a 
simple colon.  Certainly no worse than the current behavior.

dw

Re: basic asm and memory clobbers

[Paul_Koning]

> On Nov 23, 2015, at 4:36 PM, David Wohlferd <dw@LimeGreenSocks.com> wrote:
> 
> ...
>> The more I think about it, I'm just not keen on forcing all those old-style asms to change.
> 
> If you mean you aren't keen to change them to "clobber all," I'm with you.  If you are worried about changing them from basic to extended, what kinds of problems do you foresee?  I've been reading a lot of basic asm lately, and it seems to me that most of it would be fine with a simple colon.  Certainly no worse than the current behavior.

I'm not sure.  I have some asm("sync") which I think assume that this means asm("sync"::"memory")

	paul

Re: basic asm and memory clobbers

[David Wohlferd]

On 11/23/2015 1:44 PM, Paul_Koning@Dell.com wrote:
>> On Nov 23, 2015, at 4:36 PM, David Wohlferd <dw@LimeGreenSocks.com> wrote:
>>
>> ...
>>> The more I think about it, I'm just not keen on forcing all those old-style asms to change.
>> If you mean you aren't keen to change them to "clobber all," I'm with you.  If you are worried about changing them from basic to extended, what kinds of problems do you foresee?  I've been reading a lot of basic asm lately, and it seems to me that most of it would be fine with a simple colon.  Certainly no worse than the current behavior.
> I'm not sure.  I have some asm("sync") which I think assume that this means asm("sync"::"memory")

Another excellent reason to nudge people towards using extended asm.  If 
you saw asm("sync":::"memory"), you would *know* what it did, without 
having to read the docs (which don't say anyway).

I'm pretty confident that asm("") doesn't clobber memory on i386, but 
maybe that behavior is platform-specific.  Since i386 doesn't have 
"sync", I assume you are on something else?

If you have a chance to experiment, I'd love confirmation from other 
platforms that asm("blah") is the same as asm("blah":).  Feel free to 
email me off list to discuss.

dw

Re: basic asm and memory clobbers

[Segher Boessenkool]

On Mon, Nov 23, 2015 at 05:39:17PM -0800, David Wohlferd wrote:
> On 11/23/2015 1:44 PM, Paul_Koning@Dell.com wrote:
> >>On Nov 23, 2015, at 4:36 PM, David Wohlferd <dw@LimeGreenSocks.com> wrote:
> >>
> >>...
> >>>The more I think about it, I'm just not keen on forcing all those 
> >>>old-style asms to change.
> >>If you mean you aren't keen to change them to "clobber all," I'm with 
> >>you.  If you are worried about changing them from basic to extended, what 
> >>kinds of problems do you foresee?  I've been reading a lot of basic asm 
> >>lately, and it seems to me that most of it would be fine with a simple 
> >>colon.  Certainly no worse than the current behavior.
> >I'm not sure.  I have some asm("sync") which I think assume that this 
> >means asm("sync"::"memory")
> 
> Another excellent reason to nudge people towards using extended asm.  If 
> you saw asm("sync":::"memory"), you would *know* what it did, without 
> having to read the docs (which don't say anyway).
> 
> I'm pretty confident that asm("") doesn't clobber memory on i386, but 
> maybe that behavior is platform-specific.  Since i386 doesn't have 
> "sync", I assume you are on something else?
> 
> If you have a chance to experiment, I'd love confirmation from other 
> platforms that asm("blah") is the same as asm("blah":).  Feel free to 
> email me off list to discuss.

The extended asm one is "asm_operands", the basic asm one is "asm_input".
There are places where those are handled differently.  If any of that
matters, who knows.

Here is a test that shows that on at least PowerPC the basic asm is
identical to the extended asm without clobber (compile with -O2 -S and
-fno-ipa-icf if you want to have it easier to read).  In this case,
the basic asm is treated as not clobbering memory at the tree level
already, before expanding to RTL.


Segher


===
int a;

void ext_m(void)
{
        int t = a;
        a = 42;
        asm("lolz" : : : "memory");
        a = t;
}

void ext(void)
{
        int t = a;
        a = 42;
        asm("lolz" :);
        a = t;
}

void bas(void)
{
        int t = a;
        a = 42;
        asm("lolz");
        a = t;
}
===

PowerPC output (-m32, redacted):

ext_m:
        lis 9,a@ha
        li 8,42
        lwz 10,a@l(9)
        stw 8,a@l(9)
        lolz
        stw 10,a@l(9)
        blr

ext:
        lolz
        blr

bas:
        lolz
        blr

Re: basic asm and memory clobbers

[Jeff Law]

On 11/23/2015 07:22 PM, Segher Boessenkool wrote:
>
> Here is a test that shows that on at least PowerPC the basic asm is
> identical to the extended asm without clobber (compile with -O2 -S and
> -fno-ipa-icf if you want to have it easier to read).  In this case,
> the basic asm is treated as not clobbering memory at the tree level
> already, before expanding to RTL.
And that IMHO, ought to be considered a bug.

Jeff

Re: basic asm and memory clobbers

[Segher Boessenkool]

On Mon, Nov 23, 2015 at 09:48:42PM -0700, Jeff Law wrote:
> On 11/23/2015 07:22 PM, Segher Boessenkool wrote:
> >
> >Here is a test that shows that on at least PowerPC the basic asm is
> >identical to the extended asm without clobber (compile with -O2 -S and
> >-fno-ipa-icf if you want to have it easier to read).  In this case,
> >the basic asm is treated as not clobbering memory at the tree level
> >already, before expanding to RTL.
> And that IMHO, ought to be considered a bug.

I agree.  Almost everyone does, as far as I can see.

The question is if we want to retain this functionality.  No one has
depended on this in a long time -- they couldn't, it has been broken
since forever -- and there is another mechanism that does reliably
give this functionality (extended asm).

The first pass that goes wrong for this testcase is fre2, fwiw.


Segher

Re: basic asm and memory clobbers

[Jeff Law]

On 11/23/2015 10:12 PM, Segher Boessenkool wrote:
> On Mon, Nov 23, 2015 at 09:48:42PM -0700, Jeff Law wrote:
>> On 11/23/2015 07:22 PM, Segher Boessenkool wrote:
>>>
>>> Here is a test that shows that on at least PowerPC the basic asm is
>>> identical to the extended asm without clobber (compile with -O2 -S and
>>> -fno-ipa-icf if you want to have it easier to read).  In this case,
>>> the basic asm is treated as not clobbering memory at the tree level
>>> already, before expanding to RTL.
>> And that IMHO, ought to be considered a bug.
>
> I agree.  Almost everyone does, as far as I can see.
>
> The question is if we want to retain this functionality.  No one has
> depended on this in a long time -- they couldn't, it has been broken
> since forever -- and there is another mechanism that does reliably
> give this functionality (extended asm).
>
> The first pass that goes wrong for this testcase is fre2, fwiw.
I think that's the wrong way to look at things -- it's not that nobody 
is depending on this behaviour, it's nobody has had a problem due to 
this bug.

I've seen some amazing things through the years where you'd think 
there's absolutely no way they could work -- but they did for a long 
time with nobody noticing some absolutely horridly wrong code, that when 
tickled just right would wreck havoc.

So again, I would suggest we document the desired behaviour and work 
towards fixing any deviations from that behaviour.

jeff

Re: basic asm and memory clobbers

[Andrew Haley]

On 23/11/15 21:02, David Wohlferd wrote:
>> On 11/23/2015 2:04 AM, Andrew Haley wrote:
>> > My warning still holds: there are modes of compilation on some
>> > machines where you can't clobber all registers without causing reload
>> > failures.  This is why Jeff didn't fix this in 1999.  So, if we really
>> > do want to clobber "all" registers in basic asm it'll take a lot of
>> > work.
>
> I was always reluctant to see this change made.  In addition to the 
> issues you mention, I had questions about the impact on the surrounding 
> code.  I like Richard's direction much better.  We can start with a 
> disabled warning, then upgrade as seems warranted.

I don't see any problem with unconditionally clobbering memory.

Andrew.

Re: basic asm and memory clobbers

[Paul_Koning]

> On Nov 23, 2015, at 8:39 PM, David Wohlferd <dw@LimeGreenSocks.com> wrote:
> 
> On 11/23/2015 1:44 PM, Paul_Koning@Dell.com wrote:
>>> On Nov 23, 2015, at 4:36 PM, David Wohlferd <dw@LimeGreenSocks.com> wrote:
>>> 
>>> ...
>>>> The more I think about it, I'm just not keen on forcing all those old-style asms to change.
>>> If you mean you aren't keen to change them to "clobber all," I'm with you.  If you are worried about changing them from basic to extended, what kinds of problems do you foresee?  I've been reading a lot of basic asm lately, and it seems to me that most of it would be fine with a simple colon.  Certainly no worse than the current behavior.
>> I'm not sure.  I have some asm("sync") which I think assume that this means asm("sync"::"memory")
> 
> Another excellent reason to nudge people towards using extended asm.  If you saw asm("sync":::"memory"), you would *know* what it did, without having to read the docs (which don't say anyway).
> 
> I'm pretty confident that asm("") doesn't clobber memory on i386, but maybe that behavior is platform-specific.  Since i386 doesn't have "sync", I assume you are on something else?

Yes, MIPS.
> 
> If you have a chance to experiment, I'd love confirmation from other platforms that asm("blah") is the same as asm("blah":).  Feel free to email me off list to discuss.

I'm really concerned with loosening the meaning of basic asm.  I wish I could find the documentation that says, or implies, that it is a memory clobber.  And/or that it is implicitly volatile.

The problem is that it's clear from existing code that this assumption was made, and that defining it otherwise would break such code.  For example, the code I quoted clearly won't work if stores are moved across the asm("sync").

Given the ever improving optimizers, these things are time bombs -- code that worked for years might suddenly break when the compiler is upgraded.

If such breakage is to be done, it must at least come with a warning (which must default to ON).  But I'd prefer to see the more conservative approach (more clobbers) taken.

	paul

Re: basic asm and memory clobbers

[Ian Lance Taylor]

On Tue, Nov 24, 2015 at 8:58 AM,  <Paul_Koning@dell.com> wrote:
>
> I'm really concerned with loosening the meaning of basic asm.  I
> wish I could find the documentation that says, or implies, that it
> is a memory clobber.  And/or that it is implicitly volatile.

The volatile one is right there in the current docs.

https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html#Basic-Asm

"All basic asm blocks are implicitly volatile."

Even back in GCC 2.95.3, the docs say
(https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC93) "If you
write an asm instruction with no outputs, GNU CC will know the
instruction has side-effects and will not delete the instruction or
move it outside of loops" and "An asm instruction without any operands
or clobbers (and "old style" asm) will not be deleted or moved
significantly, regardless, unless it is unreachable, the same wasy as
if you had written a volatile keyword."

However, I'm not aware that basic asm's were ever implicitly memory
clobbers.  Again, back in GCC 2.95.3: "If your assembler instruction
modifies memory in an unpredictable fashion, add `memory' to the list
of clobbered registers."

Ian

Re: basic asm and memory clobbers

[Paul_Koning]

> On Nov 24, 2015, at 12:49 PM, Ian Lance Taylor <iant@google.com> wrote:
> 
> On Tue, Nov 24, 2015 at 8:58 AM,  <Paul_Koning@dell.com> wrote:
>> 
>> I'm really concerned with loosening the meaning of basic asm.  I
>> wish I could find the documentation that says, or implies, that it
>> is a memory clobber.  And/or that it is implicitly volatile.
> 
> The volatile one is right there in the current docs.
> 
> https://gcc.gnu.org/onlinedocs/gcc/Basic-Asm.html#Basic-Asm
> 
> "All basic asm blocks are implicitly volatile."

Ok, that's what I remembered.  I reported finding that this was not implemented correctly, some number of versions ago.

	paul

Re: basic asm and memory clobbers

[David Wohlferd]

On 11/24/2015 8:58 AM, Paul_Koning@Dell.com wrote:
>> On Nov 23, 2015, at 8:39 PM, David Wohlferd <dw@LimeGreenSocks.com> wrote:
>>
>> On 11/23/2015 1:44 PM, Paul_Koning@Dell.com wrote:
>>>> On Nov 23, 2015, at 4:36 PM, David Wohlferd <dw@LimeGreenSocks.com> wrote:
>>>>
>>>> ...
>>>>> The more I think about it, I'm just not keen on forcing all those old-style asms to change.
>>>> If you mean you aren't keen to change them to "clobber all," I'm with you.  If you are worried about changing them from basic to extended, what kinds of problems do you foresee?  I've been reading a lot of basic asm lately, and it seems to me that most of it would be fine with a simple colon.  Certainly no worse than the current behavior.
>>> I'm not sure.  I have some asm("sync") which I think assume that this means asm("sync"::"memory")
>> Another excellent reason to nudge people towards using extended asm.  If you saw asm("sync":::"memory"), you would *know* what it did, without having to read the docs (which don't say anyway).
>>
>> I'm pretty confident that asm("") doesn't clobber memory on i386, but maybe that behavior is platform-specific.  Since i386 doesn't have "sync", I assume you are on something else?
> Yes, MIPS.
>> If you have a chance to experiment, I'd love confirmation from other platforms that asm("blah") is the same as asm("blah":).  Feel free to email me off list to discuss.
> I'm really concerned with loosening the meaning of basic asm.  I wish I could find the documentation that says, or implies, that it is a memory clobber.  And/or that it is implicitly volatile.
>
> The problem is that it's clear from existing code that this assumption was made, and that defining it otherwise would break such code.  For example, the code I quoted clearly won't work if stores are moved across the asm("sync").
>
> Given the ever improving optimizers, these things are time bombs -- code that worked for years might suddenly break when the compiler is upgraded.
>
> If such breakage is to be done, it must at least come with a warning (which must default to ON).  But I'd prefer to see the more conservative approach (more clobbers) taken.

It looks like Ian has already addressed most of your concerns.  Just to 
emphasize one point:

The current behavior of basic asm is to NOT clobber memory.  So your 
existing code that performs asm("sync") is already at risk.

The 'fix' I am proposing is to give warnings for every use of basic asm 
inside functions (top-level asm is not a problem).  Users should change 
all such code to use extended so that they can (must) explicitly specify 
what their asm clobbers (if anything).  Armed with this information, the 
optimizers can do their work safely.  And people maintaining the code 
can finally be clear about what the asm really does.

And the code change should be simple.  They can get the same "clobber 
nothing" behavior that basic asm has always performed by simply adding a 
colon on the end ( asm("sync":) ).  Or they can use any of extended 
asm's features to get different behavior ( asm("sync":::"memory") ).

Or to put that another way, correctly written basic asm can be converted 
to extended by just adding a colon.  Incorrect code may require a bit 
more work.

dw

Re: basic asm and memory clobbers

[Andrew Haley]

On 25/11/15 02:11, David Wohlferd wrote:
> The 'fix' I am proposing is to give warnings for every use of basic asm 
> inside functions (top-level asm is not a problem).

I'm not sure that's such a great idea on its own.

My suggestion:

1.  Clobber memory.

2.  Document a rule which says that all registers which are used must be
    saved and restored.

This won't break any existing usages, and is AFAICS entirely in the spirit
of what was originally intended and with the ISO C specification.

Andrew.

Re: basic asm and memory clobbers

[Hans-Peter Nilsson]

On Fri, 20 Nov 2015, Richard Henderson wrote:
> I'd be perfectly happy to deprecate and later completely remove basic asm
> within functions.

We've explictly promised (directed to kernel people IIRC) that
the empty basic asm; 'asm ("")', has forward-compatible
outlining magic, so people would not have to keep adding
ever-new attributes like noinline,noclone to avoid finding their
functions "spilling over", so please exclude that.  To wit, from
extend.texi:

@item noinline
@cindex @code{noinline} function attribute
This function attribute prevents a function from being considered for
inlining.
@c Don't enumerate the optimizations by name here; we try to be
@c future-compatible with this mechanism.
If the function does not have side-effects, there are optimizations
other than inlining that cause function calls to be optimized away,
although the function call is live.  To keep such calls from being
optimized away, put
@smallexample
asm ("");
@end smallexample

@noindent
(@pxref{Extended Asm}) in the called function, to serve as a
special
side-effect.

brgds, H-P

Re: basic asm and memory clobbers

[Segher Boessenkool]

On Thu, Nov 26, 2015 at 05:30:48AM -0500, Hans-Peter Nilsson wrote:
> On Fri, 20 Nov 2015, Richard Henderson wrote:
> > I'd be perfectly happy to deprecate and later completely remove basic asm
> > within functions.
> 
> We've explictly promised (directed to kernel people IIRC) that
> the empty basic asm; 'asm ("")', has forward-compatible
> outlining magic, so people would not have to keep adding
> ever-new attributes like noinline,noclone to avoid finding their
> functions "spilling over", so please exclude that.  To wit, from
> extend.texi:
> 
> @item noinline
> @cindex @code{noinline} function attribute
> This function attribute prevents a function from being considered for
> inlining.
> @c Don't enumerate the optimizations by name here; we try to be
> @c future-compatible with this mechanism.
> If the function does not have side-effects, there are optimizations
> other than inlining that cause function calls to be optimized away,
> although the function call is live.  To keep such calls from being
> optimized away, put
> @smallexample
> asm ("");
> @end smallexample
> 
> @noindent
> (@pxref{Extended Asm}) in the called function, to serve as a
> special
> side-effect.

Any asm without outputs (including basic asm) is volatile, so it can
not be optimised away.  Putting an empty asm in a noinline function
should always work as you want, it's not because it is basic asm.


Segher

Re: basic asm and memory clobbers

[Hans-Peter Nilsson]

On Thu, 26 Nov 2015, Segher Boessenkool wrote:
> On Thu, Nov 26, 2015 at 05:30:48AM -0500, Hans-Peter Nilsson wrote:
> > On Fri, 20 Nov 2015, Richard Henderson wrote:
> > > I'd be perfectly happy to deprecate and later completely remove basic asm
> > > within functions.
> >
> > We've explictly promised (directed to kernel people IIRC) that
> > the empty basic asm; 'asm ("")', has forward-compatible
> > outlining magic, so people would not have to keep adding
> > ever-new attributes like noinline,noclone to avoid finding their
> > functions "spilling over", so please exclude that.  To wit, from
> > extend.texi:
> >
> > @item noinline
> > @cindex @code{noinline} function attribute
> > This function attribute prevents a function from being considered for
> > inlining.
> > @c Don't enumerate the optimizations by name here; we try to be
> > @c future-compatible with this mechanism.
> > If the function does not have side-effects, there are optimizations
> > other than inlining that cause function calls to be optimized away,
> > although the function call is live.  To keep such calls from being
> > optimized away, put
> > @smallexample
> > asm ("");
> > @end smallexample
> >
> > @noindent
> > (@pxref{Extended Asm}) in the called function, to serve as a
> > special
> > side-effect.
>
> Any asm without outputs (including basic asm) is volatile, so it can
> not be optimised away.  Putting an empty asm in a noinline function
> should always work as you want, it's not because it is basic asm.

I know, the point is that we've promised the above and we
shouldn't back down on this mechanism to instead deprecate and
warn about it, as seems to be the direction.

This happens to be expressed as a basic asm and was chosen
because the right things happen regarding backwards-
compatibility.  More care has to be taken for forward-
compatibility.  I'm a bit worried that it still works only
because of happenstance.

I know what (I hope) you're thinking but it's hard to produce a
test-case that fails when a future yet unknown optimization
causes "spill-over", but I can imagine a quick return-path
seeming inlinable in LTO.

brgds, H-P

Re: basic asm and memory clobbers

[David Wohlferd]

On 11/26/2015 8:26 AM, Hans-Peter Nilsson wrote:
> On Thu, 26 Nov 2015, Segher Boessenkool wrote:
>> On Thu, Nov 26, 2015 at 05:30:48AM -0500, Hans-Peter Nilsson wrote:
>>> On Fri, 20 Nov 2015, Richard Henderson wrote:
>>>> I'd be perfectly happy to deprecate and later completely remove basic asm
>>>> within functions.
>>> We've explictly promised (directed to kernel people IIRC) that
>>> the empty basic asm; 'asm ("")', has forward-compatible
>>> outlining magic, so people would not have to keep adding
>>> ever-new attributes like noinline,noclone to avoid finding their
>>> functions "spilling over", so please exclude that.  To wit, from
>>> extend.texi:
>>>
>>> @item noinline
>>> @cindex @code{noinline} function attribute
>>> This function attribute prevents a function from being considered for
>>> inlining.
>>> @c Don't enumerate the optimizations by name here; we try to be
>>> @c future-compatible with this mechanism.
>>> If the function does not have side-effects, there are optimizations
>>> other than inlining that cause function calls to be optimized away,
>>> although the function call is live.  To keep such calls from being
>>> optimized away, put
>>> @smallexample
>>> asm ("");
>>> @end smallexample
>>>
>>> @noindent
>>> (@pxref{Extended Asm}) in the called function, to serve as a
>>> special
>>> side-effect.
>> Any asm without outputs (including basic asm) is volatile, so it can
>> not be optimised away.  Putting an empty asm in a noinline function
>> should always work as you want, it's not because it is basic asm.
> I know, the point is that we've promised the above and we
> shouldn't back down on this mechanism to instead deprecate and
> warn about it, as seems to be the direction.

That is indeed the direction I am heading unless someone stops me.

I was not aware of this magic.  Thanks for pointing it out.  To be 
clear, wouldn't asm("":) have the same effect?

Since we have committed to this, we don't want to change it lightly.  
Also, looking at existing inline asm, this is probably one of the most 
common uses.  Allowing this exception will probably ease the migration, 
even if it makes the docs a little clunkier.

So how about this:

1) Change the docs to say asm("":), so future coders will do "the right 
thing."
2) Allow the exception for v6.
3) Re-evaluate if-and-when we continue with the deprecation process.

> This happens to be expressed as a basic asm and was chosen
> because the right things happen regarding backwards-
> compatibility.  More care has to be taken for forward-
> compatibility.  I'm a bit worried that it still works only
> because of happenstance.
>
> I know what (I hope) you're thinking but it's hard to produce a
> test-case that fails when a future yet unknown optimization
> causes "spill-over", but I can imagine a quick return-path
> seeming inlinable in LTO.

dw

Re: basic asm and memory clobbers

[Hans-Peter Nilsson]

On Thu, 26 Nov 2015, David Wohlferd wrote:
> On 11/26/2015 8:26 AM, Hans-Peter Nilsson wrote:
> > On Thu, 26 Nov 2015, Segher Boessenkool wrote:
> > > On Thu, Nov 26, 2015 at 05:30:48AM -0500, Hans-Peter Nilsson wrote:
> > > > @item noinline
...
> > > > asm ("");
...
> > I know, the point is that we've promised the above and we
> > shouldn't back down on this mechanism to instead deprecate and
> > warn about it, as seems to be the direction.
>
> That is indeed the direction I am heading unless someone stops me.
>
> I was not aware of this magic.  Thanks for pointing it out.  To be clear,
> wouldn't asm("":) have the same effect?

That does not matter.  It'd require source-code changes to
users' code.  BTW, does that syntax work for really olden gcc
(say 2.95 era)?  Either way, we promised 'asm("")'.  I'm pretty
sure the empty string is identifiable.  Whatever happens to
register-clobbering effects (wrt. this being expressed as a
"basic asm") is less interesting; it can be made the same as
'asm("":)' whenever any actual-basic-asm-deprecation is
complete, IIUC.

I have no issue with any *actual* basic asm changes.  That might
be a good idea, modulo standards issues of course (IIUC it's
optional in *some* ISO/ANSI standards, but better check all
applicable versions).

> Since we have committed to this, we don't want to change it lightly.

Right.  I don't understand why we couldn't except this
particular thing from actual-basic-asm-deprecation.  FWIW, I see
the point in making sure 'asm("":)' does the same, for syntax
consistency, but I wouldn't call that syntax "the right thing".

brgds, H-P

Re: basic asm and memory clobbers

[David Wohlferd]

 >> To be clear, wouldn't asm("":) have the same effect?
 >
 > That does not matter.  It'd require source-code changes to
 > users' code.

My suggestion was to allow the exception to the "basic asm in a 
function" warning, but change the docs to show using the new syntax.  
This does not require any user code change.  But it kinda does matter 
whether or not it will work.

Copy/pasting my suggestion:

1) Change the docs to say asm("":), so future coders will do "the right 
thing."
2) Allow the exception for v6.
3) Re-evaluate if-and-when we continue with the deprecation process.

It may not be clear from this, but I don't expect step 3 to happen until 
at least v7.

And saying "the right thing" may be a bit flip.  But if deprecating 
basic asm is the path we are choosing, then telling users to use this 
syntax is how the text should read.  Assuming it works.

 > BTW, does that syntax work for really olden gcc
 > (say 2.95 era)?

The oldest docs I can find are 2.95.3, and they talk about the extended 
asm syntax, so I assume so: 
https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC93

 > Either way, we promised 'asm("")'.  I'm pretty
 > sure the empty string is identifiable.

It is.  I've already updated my code to support this exception.

dw

Re: basic asm and memory clobbers

[Segher Boessenkool]

On Fri, Nov 20, 2015 at 04:29:50PM +0100, Richard Henderson wrote:
> On 11/20/2015 04:20 PM, Segher Boessenkool wrote:
> >Should  asm("bla");  then be an extended asm with no input, no outputs,
> >no (non-automatic) clobbers?  That would be the most straightforward and
> >logical semantics, but will it break user code?
> 
> I'm suggesting that we don't accept that at all inside a function.  One 
> must audit the source and make a conscious decision to write asm("bla" : ); 
> instead.

I have now audited all code involving RTL's ASM_INPUT (i.e. the basic asm),
and those work identically to zero-operand no-clobber volatile ASM_OPERANDS
(i.e., extended asm) everywhere.  Well, two exceptions: the mep port does
not handle that second form (which can never happen currently), and the
ia64 port treats the two forms differently for its placing of stop bits.

So as far as RTL is concerned, we do not need to force users' source code
changes for transitioning to "no more basic asm".

Now looking at what happens before RTL...  probably more exciting ;-)


Segher