This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: basic asm and memory clobbers

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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]