Re: PowerPC register and memory cost update

[David Edelsohn <dje at watson dot ibm dot com>]

>>>>> Segher Boessenkool writes:

Segher> This doesn't handle special registers (lr, ctr) specially -- moves between
Segher> general and special registers get the same cost as general<->general moves,
Segher> and special<->special moves get twice that cost.  The old version didn't
Segher> make special<->general more expensive than general<->general either, but at
Segher> least it made special<->special really expensive.

	The new cost is accurate.  special<->special moves are not
extremely expensive.  It is basically the cost of moving through an
intermediate GPR.  Those moves might be more limited to fewer function
units than general<->general, but it's not excessively more expensive.

Segher> I can imagine this hurts a lot on register-starved routines, but I have no
Segher> benchmarks to back this up.  So please test or ignore :)

	I did test and posted the results.

Segher> On a related note, looking at scheduling dumps (from -da), it seems to me
Segher> that GCC thinks loads have latency of 2 cycles (correct) and throughput of
Segher> 1 per 2 cycles (incorrect for most cpu's, and certainly for the 7400 i had
Segher> it optimize for: it can issue one load per cycle).  This hurts my indirect
Segher> threaded code interpreter a lot.

Segher> Could you point me at the "guilty" part of GCC?  I just don't seem to be
Segher> able to find where the issue rates are described.

; (define_function_unit NAME MULTIPLICITY SIMULTANEITY
;                       TEST READY-DELAY ISSUE-DELAY [CONFLICT-LIST])

(define_function_unit "lsu" 1 0
  (and (eq_attr "type" "load")
       (eq_attr "cpu" "rs64a,mpccore,ppc603,ppc604,ppc604e,ppc620,ppc630,ppc750,ppc7400"))
  2 1)

That's 2 cycles of ready delay and 1 cycle of issue delay.  Those numbers
match what you stated. 

David