Re: earlyclobbers in fix_trunc* on x86

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

  In message <19990905014156.A23498@cygnus.com>you write:
  > On Fri, Sep 03, 1999 at 10:28:21PM -0400, Jim Kingdon wrote:
  > >   (define_insn "*fix_truncdi_1"
  > >     [(set (match_operand:DI 0 "nonimmediate_operand" "m,?r")
  > >     (fix:DI (match_operand 1 "register_operand" "f,f")))
  > >      (clobber (match_operand:SI 2 "memory_operand" "o,o"))
  > >      (clobber (match_operand:DI 3 "memory_operand" "m,m"))
  > >      (clobber (match_scratch:SI 4 "=&r,=&r"))
  > >      (clobber (match_scratch:XF 5 "=f,f"))]
  > >     "TARGET_80387 && FLOAT_MODE_P (GET_MODE (operands[1]))"
  > >     "* return output_fix_trunc (insn, operands);"
  > >     [(set_attr "type" "multi")])
  > > 
  > > OK, so the age-old question is "is there a way for operands[0] to be
  > > set, followed by a memory reference?" (if so we need an earlyclobber).
  > 
  > Well, nearly.  Only if that's "arbitrary memory reference". 
  > In this case we know that operands[3] will be a stack slot
  > since we set it up that way.  So there's no conflict.
Well, wouldn't it be a frame-relative slot?  Which would then make it subject
to reloading, right?  Or does the x86 have ciscy enough address modes that
we don't have to worry about the reload?

jeff