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