Re: FLOATING-POINT CONSISTENCY, -FFLOAT-STORE, AND X86

[Craig Burley <burley at gnu dot org>]

>Spilling of fp registers was very rare before the fforce-mem flag was
>turned by default.  In fact there was a compiler bug that would
>overflow the x87 register stack before any fp register actually got spilled.
>Running with -fno-force-mem will tend to relieve any actual pressure on fp
>register allocations.

That makes sense.  Note that my proposal attempts to *completely* address
this particular problem completely -- to make the spilling of FP
registers *never* change the values.  Reducing the problem to the point
where we could say "spilling tends to happen less" would probably
not be worthwhile to anyone in the numerical programming community.

For example, -fno-force-mem does not make any of the actual examples
we've been discussing start working.  My proposal does, because it
fixes the spills themselves, not the likelihood of whether they occur
in the first place.

>Compiler-generated temporaries are not the same thing as spilling.

Indeed.

>The ffloat-store switch usually will not work on them, as you can
>see by stepping through some compilations.

I wonder if we should come to some agreement on terminology when
discussing this issue.  I'd suggest:

  user-named variable: a variable named in the program being compiled,
  its data type being assigned either explicitly or implicitly.

  compiler-generated temporary: a variable invented by the compiler to
  represent an intermediate computation, such as the `a * b' in
  `d = a * b + c'.

  spill: relocation of a variable from one physical location (such as
  a hardware register) to another (such as memory) while the code is
  running, usually to make room in the first location for another
  variable.

-ffloat-store affects only user-named floating-point variables, by
making sure they aren't permitted to carry any more precision than
is normal for their data type.  The "store" and related terminology
(used in the documentation), misleads some people into thinking this
relates to registers and thus, somehow, compiler-generated temporaries
and/or spills.

-fforce-mem affects where the compiler physically places variables
(user-named and compiler-generated), and can thus affect spills.
Since -fno-force-mem does not force all such variables into memory,
it is not really strongly related to -ffloat-store, or to spilling.
That is, -fforce-mem forces memory operands (whatever that means!)
into *pseudo* registers, so the compiler can perform more optimizations
on them, but -fno-force-mem does not force operands *out* of pseudo
registers.

My proposal affects what happens to values that are spilled.  Ideally,
it would make spills never cause a change in value.

If my proposal is adopted, I think it'd render another proposed
option actually useful -- one that is like -ffloat-store, but applies
to *all* variables, compiler-generated as well as user-named.

        tq vm, (burley)