This is the mail archive of the
mailing list for the GCC project.
Re: PATCH: Add pa8000 scheduling
- To: "Jerry Quinn" <jquinn at nortelnetworks dot com>
- Subject: Re: PATCH: Add pa8000 scheduling
- From: Jeffrey A Law <law at hurl dot cygnus dot com>
- Date: Thu, 18 Mar 1999 23:56:52 -0700
- cc: egcs-patches at egcs dot cygnus dot com
- Reply-To: law at cygnus dot com
In message <36F11FD2.2ED9C169@americasm01.nt.com>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
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.
> 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
> 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 pa.md 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"))))]
> "TARGET_PA20 && ! TARGET_SOFT_FLOAT"
> "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.