This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Fwd: Questions on PA machine description?
- To: law at cygnus dot com
- Subject: Re: Fwd: Questions on PA machine description?
- From: "Jerry Quinn" <jquinn at nortelnetworks dot com>
- Date: Thu, 18 Mar 1999 17:34:52 -0500
- CC: egcs at egcs dot cygnus dot com
- Organization: Nortel Technology
- References: <14489.921730350@hurl.cygnus.com>
Jeffrey A Law wrote:
>
> I'd create one additional unit -- fmac for all the other fp computation
> insn to show the partial latency as recommended by HP. Something like this:
>
> (define_function_unit "pa8000fmac" 2 0
> (and
> (eq_attr "type" "fpcc,fpalu,fpmulsgl,fpmuldbl")
> (eq_attr "cpu" "8000")) 2 1)
>
> ie, there's two fmac units which are fully pipelined. Results are available
> in 2 cycles.
>
> I'm going to make those changes and install the patch.
There seems to be some delay going on :-) I responded to your post on
egcs-patches before realizing you saw my revision of my original
scheduling.
The other message mentioned that eliminating autoincrement/autodecrement
instructions is a good thing. Do these instructions have the same
problem as fmpyadd, i.e. grabbing multiple reorder slots and function
units?
> The other thing to think about is how to show that some instructions which
> are data dependent can/should issue in the same cycle. ie, if an alu
> operation feeds another alu operation, then we should issue them in the
> same cycle.
>
> One thought would be to make the ready delay for alu instructions 0, then
> tweak haifa to add dependent instrutions to the ready queue immediately
> after it issues an insn with a ready delay of zero cycles.
What about making pa_adjust_cost set the cost of a data dependency to
0? The alpha port does this on the ev5.
Why is this a good thing? Won't an instruction that depends on another
one have to retire later than the other one?
Jerry
--
Jerry Quinn Tel: (514) 761-8737
jquinn@nortelnetworks.com Fax: (514) 761-8505
Speech Recognition Research