Spill frequency and alignment

[Stephen L Moshier <moshier@mediaone.net>]

  In certain important sections of the code, the number
  of memory references associated with spills and restores
  approaches the number of declared memory references.

In the terminology of reload, spilling merely reassigns a variable
from a register to a home on the stack.  I suspect that the force-mem
switch tends to create gratuitous copying, from the declared memory
variable to a register which then suffers reloading to the stack.  It
would be interesting if you were to find that -fno-force-mem had an
effect on either the overall execution speed or the amount of spilling
in your particular benchmark.

The fact that something was spilled does not imply that it was also
necessarily truncated.  Spilling and truncating are two different
effects to be evaluated.  If a `double' variable is merely copied into
a register and then recopied out to a `double' stack location, then it
was not actually truncated.  I thought we already had some test cases
that showed truncation, but in an hour or so of searching, I could not
find it either in the torture tests nor in any of the random C
programs that happened to be handy.  Thus I do not have a test case
for the bug, and the experience of searching for one has made me think
that the truncation effect may be rare compared to the overall
incidence of spilling.  That ratio affects the statistical estimation
of the speed penalty, because there would be no reason to widen the
spills that did not also truncate.

Permit me to reiterate that I consider extra-precise register problems
to be a hardware bug, not a compiler bug.  The Intel 8087 fraud is no
substitute for a real XFmode data type in the compiler nor for ways
to get IEEE behavior out of the hardware.