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
