[tree-ssa] RFC: Never gimplify ASM_EXPRs

[Linus Torvalds]

On Thu, 5 Jun 2003, Richard Henderson wrote:
> 
> Current behaviour is to allow both memory and non-memory inputs.
> If the original form, modulo folding, of the input is
> 
>   (1) INDIRECT_REF, then that memory used,
>   (2) DECL_P, then lang_hooks.mark_addressable is called, which
>       forces stack allocation of the variable, and that is used,
>   (3) Otherwise we create a temporary.
> 
> The third point is marginally useful

Yes. But it is pretty marginal.

I think the third point is largely "syntactic sugar", and it's so trivial
to work around that if it makes sense to say that "m" must match a lvalue,
and people feel that it makes a better compiler, then I don't think (3) is
worth keeping.

After all, it's trivial to just create the temporary in the code, 
and change your example
	
	__asm__ ("fldcw %0" : : "m" (cw & ~0x300 | 0x200));

into

	{
		unsigned long newcw = cw & ~0x300 | 0x200;
		__asm__ ("fldcw %0" : : "m" (newcw));
	}

and this always works, and considering that there aren't _that_ many users
of inline assembly, if a lvalue rule makes the compiler more robust and
makes the rules clearer, I'm all for it.

NOTE! One reason I'm actually all for this is that I've always been
worried about this issue for inline asms anyway. Take a look at the kernel
<asm/bitops.h> header and the "ADDR" define - right now it's using a
volatile, but historically it has had other "tricks" to make sure that the
compiler doesn't do anything strange. It used to use a cast to an array
instead of using a volatile pointer, just to make sure that gcc internally
saw the thing as a MEM and didn't reload it or use some cached value
thing.

So I'd personally love to see the strict rule: '"m" must match an lvalue,
and will use the address of that lvalue', if only to make one less gray
area. 

But you must make the decision, since it _will_ break existing code. Not a 
lot, and in easy-to-fix ways, but still.. I don't mind fixing the kernel 
for something like this, but others may find it irritating.

[ I actually have a few other gcc features I wouldn't mind see go away.  
  That "cast is an lvalue" is a horror, and same goes for "conditional is 
  an lvalue". Both extensions are just crap, and don't buy you anything in
  the language - they are purely syntactic sugar, and they are badly
  designed.

  If somebody really wants the "cast of an lvalue is an lvalue" thing,
  then you can always get it by doing the address-of of the lvalue, 
  casting to the proper pointer, and derefencing. The gcc extension is 
  only a bad shorthand that doesn't fit the C language. Same goes for the 
  conditional.

  And yes, again we'd have to fix the kernel if these features were 
  removed. And I'm a lazy bastard, and I won't fix it unless gcc really
  does deprecate them. But I'd love to be forced to fix the kernel from
  yet another ugly gcc'ism. Punish me, 'cause I've been bad! ]

		Linus