On 11/19/2015 7:14 PM, Segher Boessenkool wrote:
On Thu, Nov 19, 2015 at 05:23:55PM -0800, David Wohlferd wrote:
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.
I don't think this is necessary or useful. They are also awful names:
"clobberall" cannot clobber everything (think of the stack pointer),
I'm not emotionally attached to the names. But providing the same
capability to extended that we are proposing for basic doesn't seem so
odd. Shouldn't extended be able to do (at least) everything basic does?
My first thought is that it allows people to incrementally start
migrating from (new) basic to extended (something I think we should
encourage). Or use it as a debug tool to see if the failure you are
experiencing from your asm is due to a missing clobber. Since the
capability will already be implemented for basic, providing a way to
access it from extended seems trivial (if we can agree on a name).
As you say, clobbering the stack pointer presents special challenges
(although gcc has a specific way of dealing with stack register
clobbers, see 52813). This is why I described the feature as having
"the same semantics as whatever the new basic asm will be using."
and "clobbernone" does clobber some (those clobbered by any asm),
Seems like a quibble. Those other things (I assume you mean things like
pipelining?) most users aren't even aware of (or they wouldn't be so
eager to use inline asm in the first place). Would it be more palatable
if we called it "v5BasicAsmMode"? "ClobberMin"?
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.
Some do. The purpose is to stay compatible with asm written for older
versions of the compiler.
Backward compatibility is important. I understand that due to the cc0
change in x86, existing code may have broken without always clobbering
cc. This was seen as the safest way to ensure that didn't happen.
However no solution was/is available for people who correctly knew
whether their asm clobbers the flags.
Mostly I'm ok with that. All the ways that I can think of to try to
re-allow people to start using the cc clobber are just not worth it. I
simply can't believe there are many cases where there's going to be a
benefit.
But as I said: backward compatibility is important. Providing a way for
people who need/want the old basic asm semantics seems useful. And I
don't believe we can (quite) do that without clobbernone.
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.
24414 says the documented behaviour hasn't been true for at least
fourteen years. It isn't likely anyone is relying on that behaviour.
?
To my knowledge, there was no documentation of any sort about what basic
asm clobbered until I added it. But what people are (presumably)
relying on is that whatever it did in the last version, it's going to
continue to do that in the next. And albeit with good intentions, we
are planning on changing that.
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.
Saying nothing at all at least is *correct*.
We don't know that saying "it doesn't clobber flags" is wrong either.
All we know is that jeff said "I suspect this isn't consistent across
targets."
But that's neither here nor there. The real question is, if we can't
say that, what can we say?
- If 24414 is going in v6, then we can doc that it does the clobber and
be vague about the old behavior.
- If 24414 isn't going in v6, then what? I suppose we can say that it
can vary by platform. We could even provide your sample code as a means
for people to discover their platform's behavior.
It isn't necessary for users to know what registers the compiler
considers to be clobbered by an asm, unless they actually clobber
something in the assembler code themselves.
I'm not sure I follow.
If someone has code that uses a register, currently they must restore
the value before exiting the asm or risk disaster. So they might write
asm("push eax ; DoSomethingWith eax ; pop eax"). However if you know
that the compiler is going to clobber eax, then the push/pop is just a
waste of cycles and memory.
To write efficient code, it seems like you do need to know what the
compiler clobbers.
They can write extended asm in that case.
I agree that if they did that it would solve the problem. But...
Maybe you can put that in the doc? "If you modify any register or
memory, use an extended asm"? Jeff, do you agree with that?
Well, I'm already on record as saying I think any asm that isn't top
level should be extended, so I'm pretty much ok with that.
But that raises the question:
- If this is the requirement for using basic asm, why do we need to
change its behavior at all? Yes, code that uses registers or memory
might fail due to optimizations, but such code would be in violation of
supported usage.
- If registers and memory access are still supported in basic asm,
what's the point of doc'ing that you can't?
dw
