[tree-ssa] RFC: Never gimplify ASM_EXPRs

Richard Henderson rth@redhat.com
Fri Jun 6 05:23:00 GMT 2003


On Thu, Jun 05, 2003 at 10:30:43PM -0400, Jason Merrill wrote:
> Do people think that we ought to accept this sort of usage, or is it
> reasonable to require that an 'm' input operand be an lvalue?

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, e.g.

	static void __attribute__((constructor))
	set_53bit_precision (void)
	{
	  unsigned short cw;
	  __asm__ ("fnstcw %0" : "=m" (cw));
	  __asm__ ("fldcw %0" : : "m" (cw & ~0x300 | 0x200));
	}

One could easily pull the computation out to a local variable
and pass that to the asm.  Indeed, we *might* think about
requiring it; that would seem to make the semantics cleaner.

Less obvious is what to do with 

	__asm__ ("fldcw %0" : : "m" (0x027f));

Perhaps the "best" thing is to put the immediate into the
constant pool and use that, rather than allocating local
stack space.  That kind of decision may depend on the target.

Examining glibc usage, I don't immediately see anything that
relies on the implicit temporary.  Indeed, they appear to be
working around bugs in older gcc by doing "*&temp".

Linus, do you have an opinion here?

I definitely think we should issue an error for

  register short int x;
  __asm__ ("fldcw %0" : : "m"(x));

I.e. a DECL_P that cannot be addressed.  Possibly that
already happens inside the lang_hook; I havn't checked.


r~



More information about the Gcc mailing list