This is the mail archive of the egcs@egcs.cygnus.com mailing list for the EGCS project. See the EGCS home page for more information.


[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]

Re: Another PA question - possible bug?




  In message <36E69387.6B28D231@americasm01.nt.com>you write:
  > In pa.md, I was looking at various "fpalu" patterns tryig to learn about
  > them, and saw this one which left me a bit confused:
  > 
  > ;; This pattern forces (set (reg:DF ...) (float:DF (const_int ...)))
  > ;; to be reloaded by putting the constant into memory.
  > ;; It must come before the more general floatsidf2 pattern.
  > (define_insn ""
  >   [(set (match_operand:DF 0 "register_operand" "=f")
  > 	(float:DF (match_operand:SI 1 "const_int_operand" "m")))]
  >   "! TARGET_SOFT_FLOAT"
  >   "fldw%F1 %1,%0\;fcnvxf,sgl,dbl %0,%0"
  >   [(set_attr "type" "fpalu")
  >    (set_attr "length" "8")])
  > 
  > 
  > Most of the insn patterns I saw would set "type" to have an entry for
  > each assembly instruction.  Should this one set type to "fpload,fpalu"?
Not exactly.

The set a type and length for each alternative.  This insn only has one
alternative.

The one alternative generates two instructions.  We have no good way to
describe this from a scheduling standpoint.  This is one of the (many)
reasons why w generally frown on a single insn generating multiple
instructions.

If you want to make this accurate from a scheduling standpoint you would
need to split the instruction after reload has completed.  One insn to
load the value from memory, then another to do the conversion.

jeff