Re: asm changes? [Was: Re: flow.c bugfix ]

[Jeffrey A Law <law at cygnus dot com>]

  In message <19981204154400.E13033@dot.cygnus.com>you write:
  > On Fri, Dec 04, 1998 at 10:48:20PM +0100, Bernd Schmidt wrote:
  > > If we change gcc to suddenly allocate explicitly clobbered regs to input
  > > operands, we are going to break all correctly written asm statements
  > > that assume that this cannot happen.  The correct behaviour has been
  > > documented at least since gcc-1.42, and actual behaviour has been differe
  > nt
  > > only on SMALL_REGISTER_CLASSES machines.  I don't think we want to change
  > > the meaning of all existing asm statements out there.
  > 
  > Uh, we're not suggesting that.
It was something suggested by one of the ppc linux guys about a year ago.  Note
that such rewriting could be limited to the case where only one reg can satisfy
the input operand.  That weeds out all the properly written asms from being
modified by this hack.  The net result is the hack would really only apply to
the existing x86 asms and any new ones folks write.

Basically it would be legitimizing (via one way or another) existing practice
on the x86.  Something to think about.


  > Linus' proposal was to define something
  > new, an early clobber input:

  > 
  >   asm("" : : "&r"(value))
  > 
  > which would mean that it's register is not shared with any other input
  > or output, and that its contents are dead after the asm.
Right.

My biggest concern with this scheme was nowhere else does '&' on an input
have any meaning, in fact, the compiler will not do the exptected thing
if you have a define_insn where one of the inputs is earlyclobbered.  The
vast majority of the compiler assumes side effects are exposed in the RTL
structure itself.


However asms are somewhat different.  The comiler does look at the strings
early to determine the side effects for the asm.  So it may be feasible to
grok the new "&" early, and note the side effect in the asm's rtl to keep the
rest of the compiler happy.

This may take the form of internally turning it the earlyclobber input into
input+output matching operands with the earlyclobber on the output or some
other form.  I don't know yet.  But it is important that the side effect of
cobbering the input register be shown somewhere in the rtl.


jeff