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

[Edward Jason Riedy <ejr at CS dot Berkeley dot EDU>]

Oh well.  And Joe Buck writes:
 - 
 - It would seem that if we did 80-bit spills, then the -O flags would not
 - affect the results (assuming that the original code uses parentheses
 - to constrain the order of evaluation of FP expressions and that the
 - optimizer avoids transformations that can change numerical results,
 - such as pre-evaluating expressions with 64-bit that would otherwise
 - be evaluated using 80-bit precision at runtime).

Yup.  Seeing someone else actually propose this is what prompted my 
jumping in...  

Using 80-bit spills is a quick approximation to extending the FP stack
into memory, and it should give some of the benefit with very little 
(hopefully) hassle.  Of course, 80 bits is wider than the normal spill,
so it eats more memory bandwidth, cache space, etc.  Anyone who's that
concerned will bend over backwards to avoid spills anyways.

I believe -ffast-math is necessary before result-changing reorderings 
are allowed.  (Someone from here corrected me on usenet when I assumed
otherwise, iirc.)  The pre-evaluation could conceivably be handled by 
running in extra precision at compilation (there are well-documented 
tricks that will work on anything with a guard bit, and gcc doesn't 
support the old Crays that don't have it), but that may be more trouble 
than it's worth.  If I were being paranoid, I wouldn't want to risk 
compiling in any round-off, so I'd evaluate it myself.  Extreme 
precision in compiler evaluations should be platform independant, too.

And if there are never in-expression truncations, -ffloat-store should
give proper IEEE rounding in all cases.  I'm basing that on the informal
definition of IEEE arithmetic (the correct result correctly rounded),
but it feels true.  Need to check opposing round-off errors before I can 
say that for sure.  That error should be at most a bit, if anything.

Overflow conditions wouldn't be triggered until the store, but any 
instructions to test that must come after the expression evaluation, so 
the result would be stored before the test.  I need to review what should 
happen with underflow...  Computing in 80 bits when you think it's a 
double could mean you're not dividing by zero when you would have been.
It might change a divide-by-zero (NaN or +-inf) into an overflow (+-inf).

Seems like 80-bit spills would be closer to IEEE, if not close enough to
claim full support.  Off-hand I'd say people would be happier with
those numeric properties than with the current situation.

I'll think about the esoterica (probably break down and ask people here).  
It would certainly make gcc the most reliable x86 floating-point compiler 
I know.  Sun's does something similar to -ffloat-store by default (gee, 
look at how fast that ultra is), and Microsoft's runs off the end of the 
stack at run-time .  I don't know what Intel's does, so I'm not considering 
it.  ;)

Jason, who will happily accept corrections to the above...