Suggestions for the ultrasparc scheduler.

[David S. Miller]

   Date: Wed, 27 Oct 1999 08:37:25 +0200
   From: Matteo Frigo <athena@fftw.org>

   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
lost.

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
suite.

   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.

Later,
David S. Miller
davem@redhat.com