Suggestions for the ultrasparc scheduler.
David S. Miller
Wed Oct 27 01:17:00 GMT 1999
Date: Wed, 27 Oct 1999 08:37:25 +0200
From: Matteo Frigo <email@example.com>
1) In config/sparc/sparc.h, the macro ADJUST_COST(...) is defined to be
sparc_adjust_cost(INSN, LINK, DEP, COST)
However, sparc_adjust_cost returns the new cost, but the return
value is not stored anywhere. Consequently, the cost is not
adjusted at all. The following patch fixes the problem.
Duh, obvious bug.
2) Floating-point additions and multiplications have a latency of 3
cycles on the ultrasparc-I (See Sun Microelectronics, STP1030BGA
UltraSPARC-I User's Manual, Rev 1.4, Jan 1996, table 17-1 and
elsewhere.) sparc.md models these instructions with a 4-cycle
latency. For the programs I tried, using a latency of 3 produces
slightly better code.
They have a 4 cycle latency when dependant instructions are
prematurely dispatched due to the instruction dispatch doing a
non-conservative dependency check in the G stage of the pipeline.
When this situation occurs, the incorrectly dispatched dependant
instruction is killed in the W stage and completely refetched, this
cancels out everything else in the pipeline and 9 cycles or more are
This high cost of hitting this condition is why I choose to use
the 4 number, please reread the latency table it is there.
The code improvements you saw are possibly due to decreased register
allocation pressure, but I can't be sure unless I see your test
3) ultra_schedule_insn accepts a ready list READY and an instruction
IP, and it places IP at the front of the ready list. In the
current implementation, ultra_schedule_insn swaps IP with the front
of the ready list (which is the insn with the highest priority).
Unfortunately, this swap delays the highest-priority instruction by
moving it deeper into the ready list. I found that a better policy
is to preserve the priority order of the ready list. This effect
can be accomplished by shifting all elements between the front of
the list and IP, preserving the order. The patch follows.
I'm trying to remember why I did things this way, I must have had a
good reason. I'll respond to this point when I can obtain some
more recollection about the situation.
David S. Miller
More information about the Gcc-bugs