This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PATCH: Add pa8000 scheduling

  In message <>you write:
  > I thought perhaps for fmpyadd and fmpysub, if we make them grab both alu
  > units, that would effectively keep them from being used - sort of
  > equivalent to hogging two slots in the reorder buffer.  Does that make
  > sense?
I don't think it's worth the effort.  I recommend disabling them when
pa_cpu == PROCESSOR_8000.

  > Should all the combinations in pa_combine_instructions be prevented or
  > just the fmpyadd/sub?
All of them should be prevented.

  > I've sent in a (incomplete) patch for 2.0 assembler support for the
  > extra floating point instructions.  So at least in theory, an
  > architecture switch makes sense now.
Soon :-)

  > I created an -march= switch based
  > on discussion on the egcs list a month and a half ago centered around
  > the ppc port and the arch and schedule switches.  The discussion sounded
  > like people were in favor of a more standard approach to switch naming. 
  > I can do a -mpa-risc-2-0 switch if you prefer.
Let's go ahead and stick with the way things have been done.  If we want
-march, we can make it a synonym for the traditional way we've done this on
the PA port.

  > I figured that TARGET_SNAKE would be set even for 2.0.  Does this sound
  > right?

  > Also, should we be worried about 32 bit vs. 64 bit?
Not at this time.  These instructions can be used when the processor is
in narrow mode.

  > Finally, I'm trying to add entries to to generate fmpyfadd
  > instructions.  What I have so far is something like:
  > (define_insn ""
  >   [(set (match_operand:DF 0 "register_operand" "=f")
  > 	(plus:DF (match_operand:DF 1 "register_operand" "f")
  > 		 (mult:DF (match_operand:DF 2 "register_operand" "f")
  > 			  (match_operand:DF 3 "register_operand" "f"))))]
  >   "fmpyfadd,dbl %3,%2,%1,%0"
  >   [(set_attr "type" "fpalu")
  >    (set_attr "length" "4")])
  > with a second pattern reversing the order of the addend operand and the
  > mult operator (and two more for single precision).  My main problem
  > (maybe there are others :-) is that I don't understand how the pattern
  > matching is done.  Does this make sense? 
Yes.  It looks pretty good.

  > Or should there be two
  > separate set operators with the mult target being a match_dup of one of
  > the plus operator's operands?
One set since we only have one output from the instruction.  ie, we have
an instruction that has 3 input operands and 1 output operand.  Thus we
only need one set target.

  > I've been wandering through the docs
  > reading on RTL and several .md files trying to find a similar
  > multiply-accumulate pattern, but admit I'm still confused as to how
  > patterns are applied.
It takes a little time.  You're on the right track.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]