This is the mail archive of the
mailing list for the GCC project.
Re: basic asm and memory clobbers - Proposed solution
- From: David Wohlferd <dw at LimeGreenSocks dot com>
- To: Andrew Haley <aph at redhat dot com>, Jeff Law <law at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, rth at redhat dot com
- Cc: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Paul_Koning at Dell dot com, jakub at redhat dot com, rth at gcc dot gnu dot org, pinskia at gcc dot gnu dot org, Segher Boessenkool <segher at kernel dot crashing dot org>, Ian Lance Taylor <iant at google dot com>, Sandra Loosemore <sandra at codesourcery dot com>, Hans-Peter Nilsson <hp at bitrange dot com>, bernd dot edlinger at hotmail dot de
- Date: Sat, 12 Dec 2015 22:15:02 -0800
- Subject: Re: basic asm and memory clobbers - Proposed solution
- Authentication-results: sourceware.org; auth=none
- References: <56552209 dot 1020306 at LimeGreenSocks dot com> <56592801 dot 9010606 at LimeGreenSocks dot com> <565DC5F4 dot 6080804 at foss dot arm dot com> <565E1E37 dot 9080609 at LimeGreenSocks dot com> <alpine dot DEB dot 2 dot 10 dot 1512012323160 dot 12604 at digraph dot polyomino dot org dot uk> <565E6862 dot 7070401 at redhat dot com> <566B4BA1 dot 8000509 at LimeGreenSocks dot com> <566BEE35 dot 6070804 at redhat dot com>
On 12/12/2015 1:51 AM, Andrew Haley wrote:
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
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
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
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
- 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
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.
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.