basic asm and memory clobbers - Proposed solution

[David Wohlferd]

On 12/12/2015 1:51 AM, Andrew Haley wrote:
>> Solution 2:
>> Change the docs to say that basic asm clobbers everything (memory, all
>> registers, etc) or perhaps just memory (some debate here), but that due
>> to bugs that will eventually be addressed, it doesn't currently work
>> this way.
> You've missed the most practical solution, which meets most common
> usage: clobber memory, but not registers.

Actually, that's intended to be part of Solution #2 ("or perhaps just 
memory").  Sorry if that wasn't clear.

> That allows most of the
> effects that people intuitively want and expect,

The nice thing about guessing what people want and expect is that it can 
be molded however we need to suit our point of view.  I could make a 
similar case that what people want is the behavior from other compilers 
that have built-in assemblers.  Those compilers can 'see' what registers 
are being used by the asm and adapt.  Since GCC can't provide that 
capability, people might 'expect' it to clobber every register if that's 
what is needed to support the same behavior.

I'm not trying to advocate for clobbering registers.  My point is simply 
that I don't see how we can *know* what people want and expect.  You can 
say they expect memory.  Jeff can say they expect memory+registers.  I 
can say they expect it to work the same way tomorrow that it did 
yesterday.  Who's right?  I'm not prepared to say.  But I don't think 
any of us are wrong.

> but avoids the breakage of register clobbers.

You are right "just memory clobber" does remove some performance issues, 
and the breakage that could result from clobbering registers.  Also, 
while I have never written nor read an optimizer, my guess is that the 
biggest 'win' as far as positioning the basic asm comes from the memory 
clobber (compared to clobbering registers).  So this does get us most of 
the benefits of "clobber everything" with less effort and fewer 
consequences.

However breakage and performance issues can still result solely from 
adding memory clobbers.  And as I mentioned, "just memory clobber" may 
not be the behavior people expect.  And if we aren't solving that, might 
there be a second update later to add registers?  Talk about confusing 
semantics...

> It allows basic asm to be used in a
> sensible way by pushing and popping all used registers.

If I were using basic asm, this would indeed seem like a sensible approach.

However, it is not the most efficient.  If I can clobber registers, 
push/pop are just wasted cycles.  This just seems like another argument 
for deprecating basic asm and pushing people to extended.

----------------------
Imagine for a moment:

If the only way right now to do inline asm in gcc was extended, and I 
proposed adding basic, how could I justify this 'new' feature? Other 
than 'top-level,' I can't think of a single benefit that it would 
provide.  Pointless push/pops, problems with positioning and the other 
headaches it causes have no upside.

Contra-wise, what if starting today all new inline asm were written 
using extended?  How would that be a bad thing?  What would be the 
downside?  Yes, people can still write bad code with extended, but its 
semantics are well-understood and have been for a long time (certainly 
compared to basic).  Additionally, the abilities it provides allow 
people to solve problems that basic never will.

Which means (to me), the only real justification for the continued 
existence of basic asm is backward compatibility.  Which makes the 
arguments for changing its behavior (whether a little or a lot) kinda weird.

I still vote for doing everything we can think of to discourage people 
from using basic and begin using extended:

- Change the docs to flat out deprecate basic (excluding top-level).
- Add the warning so people's integrated dev environments will show the 
suspect lines.
- Make the warning a default, but overridable (-Wno-only-top-basic-asm), 
so people who HAVE to support the old syntax still can.
- Make sure the docs for the warning describe (link to?) how to change 
asm from basic to extended and why.
- Any bugs people report or posts people make involving basic asm get 
resolved as 'Try it with extended.'

Every year these items are in place would make basic asm less important 
as people slowly move to extended.  Maybe by the time we get around to 
flagging it as a fatal error (say in 2025), no one will care.

True, this won't magically solve people's problems for them if they've 
been using basic asm wrong.  But it does point out that there are 
(potential) problems, where those problems are and motivates people to 
fix them (which seems like quite reasonable behavior for a compiler).  
More importantly, we haven't broken or degraded anything that was 
already working.

I'm just afraid that instead of pursuing any of these solutions, we are 
going to pursue Solution #0: Do nothing.  A rather unsatisfying outcome 
after all this effort.

dw

PS I was surprised by how many people downloaded my patch to produce the 
warning.  Apparently there is some interest in finding (fixing?) these 
basic asm statements.  Even if we don't end up changing anything, I 
guess that's something.