basic asm and memory clobbers

[David Wohlferd]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 24414b.patch
Type: text/x-patch
Size: 1329 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20151116/de61dc9c/attachment.bin>