Re: basic asm and memory clobbers

[Segher Boessenkool <segher at kernel dot crashing dot org>]

On Fri, Nov 20, 2015 at 02:45:05AM -0800, David Wohlferd wrote:
> 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.

Names should be succinct, clear, and give a good indication of what the
thing named does.  If it is hard to make a good name it is likely that
the interface isn't so well designed.

> 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?

But that would be logical!  Can't have that.  Heh.

> As you say, clobbering the stack pointer presents special challenges 
> (although gcc has a specific way of dealing with stack register 
> clobbers, see 52813).

Yeah.  Actually, basic asm is handled specially in many places, too.

> >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"?

I meant things like x86 "cc".

> >>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.

Exactly.  The asm still can be moved "over" other uses of CC, it does
not limit transformations much at all.

> 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.
> 
> ?

24414 says these things haven't worked since at least 2.95.3, which is
fourteen years old now.

> >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 the assembler code does not clobber some register, but GCC treats it
as if it does, things will work correctly.


Segher