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.
