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 - Proposed solution

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.


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.

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