Excess double register spillage on the UltraSparc?

Edward Jason Riedy ejr@cs.berkeley.edu
Fri Oct 30 17:57:00 GMT 1998

Snipped from output from a recent (two days ago) CVS egcs:
>        ldd     [%g3+56], %f2 ! 120 *movdf_insn_v9only/2
>        std     %f2, [%fp-32] ! 394 *movdf_insn_v9only/3
>        ldd     [%i0+%i5], %f52 ! 106 *movdf_insn_v9only/2
>        std     %f8, [%fp-24] ! 397 *movdf_insn_v9only/3

Am I correct in assuming that these snippets are due to the local 
spilling code?  The stores (one of which is very, very nasty,
even though the scheduler was told to do its thing) are unnecessary, 
and neither Sun's cc (4.2) nor egcs 1.1b generates any...  There are 
the same number of faddd and fmuld instructions generated by each
compiler for this loop, so there should be enough registers.

I'm trying to poke through the (automatically generated) C code to
find exactly the constructs causing this, but it's being a pain.
If there's an option to interleave the C with the assembler (kinda
like Sun's output), I'd love to know.

This is from a double-precision matrix-matrix multiply that was
found to be `optimal' for Sun's cc (exhaustive search of a certain
parameter space).  I'm trying to understand some of the differences...  
The one found `optimal' for egcs tends to be about 10 MFLOP/s slower. 
And one for egcs-1.1b is much slower (obvious enough that I haven't 
fully timed it), so the optimizations and that wonderful Sparc rewrite 
have certainly helped in this case.  Thank you thank you thank you.


More information about the Gcc-bugs mailing list