This is the mail archive of the gcc@gcc.gnu.org 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



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


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