basic asm and memory clobbers - Proposed solution

[Segher Boessenkool]

On Sun, Dec 13, 2015 at 10:59:11PM -0800, David Wohlferd wrote:
> Is there a decision maker still teetering on the edge of making a call 
> here?

I think people are waiting for consensus, and we won't get consensus
until there is a good solution, something that gives workable semantics
(whatever those may be) and gives users a viable non-surprising way
forward, keeping in mind they have code that needs to work with older
compilers as well.

> On 12/13/2015 1:25 AM, Bernd Edlinger wrote:
> >>That is also my preferred solution,
> 
> I'm really not sure what the point of doing the memory clobber is. Yes, 
> I see that it is easier to code than "clobber everything."  And yes, it 
> might help with certain types of bugs for people who have or might 
> someday misuse asm.
> 
> But if we are trying to give users what they expect, shouldn't we be 
> doing the "clobber everything" Jeff suggested 
> (https://gcc.gnu.org/ml/gcc/2015-11/msg00081.html)?  Surely that's the 
> "safest" answer, and it's as likely to be what people expect as anything 
> else.  Adding the memory clobber will already break backward 
> compatibility and risk breaking existing code.  Why do all that for half 
> a solution?

That, and adding a memory clobber degrades performance for a lot of
existing basic asm that does not expect the clobber, e.g. asm(""),
asm("#"), asm("nop"), ...

> > The rationale for this is: there are lots of ways to write basic asm
> > statements, that may appear to work, if they clobber memory.
> 
> > because you can use all global values simply by name, users will
> > expect that to be supported.

This only works for some archs, for some ABIs, with some options.

> And if we do end up changing this, using basic asm will become more 
> dangerous than ever.  In addition to all the old problems (that will 
> still exist in earlier versions), now its behavior VARIES between 
> versions.  Programmers who want specific behavior (rather than our 
> assumption-du-jour) will be forced to CHANGE THEIR CODE to account for 
> this variability.

Yeah.  Which is why I prefer basic asm to have the same semantics as
extended asm without operands -- it does *now*, and has for many years.

- - -

There actually are three differences, it isn't *exactly* the same:
1) ia64 treats basic asm different, it always gives them stop bits;
2) basic asm does not use TARGET_MD_ASM_ADJUST, this is a problem;
3) basic asm does not need '%' (and for ASSEMBLER_DIALECT targets,
'{' '|' '}') escaped with an extra '%'.

This last point makes the "pretend basic asm never existed" option
unworkable, there is quite some code that relies on it.


Segher