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

[hjstein at bfr dot co dot il (Harvey J. Stein)]

Craig Burley <burley@gnu.org> writes:

 > >This would imply that for now, since the spill width is 64 bits &
 > >can't immediately be changed, that the FPU be set to double precision,
 > >and when gcc is capable of spilling other widths then the spill width
 > >should be increased to 80 bits.
 > 
 > Okay, not a bad idea, but to set the FPU to double precision without
 > breaking existing code, the compiler would have to save the FPU
 > setting on entry to any procedure, ensure that it's restored when
 > that procedure returns, and restore it prior to any call, then
 > re-save and re-set it upon that call's return.  (And we cross our fingers
 > that the call wasn't made specifically to change the FPU settings,
 > to be made effective in the current routine, since we'd be breaking
 > that sort of thing.)

I think this is massive over-engineering.  The numerics are so screwed
up anyway with the 64 bit spills & fcn return temporary variables that
I really can't imagine that there's actually code relying on gcc which
will break if the FPU setting was globally double precision.

Furthermore, given all this, I think that anyone who's using gcc &
intentionally writing code to exploit the 80 bit FPU registers (read -
implementers of things like libm) must be sufficiently on the ball to
twiddle the control word back & forth for his code that requires it.

I can't imagine anyone who's not intentionally writing such code
ever noticing such a change.

On the other hand, I think that most people will see numeric problems
go away if the FPU width matched external data width.

Yes, technically speaking, one should push & pop FPU width according
to what the programmer expected when written.  But the thing is, most
programmers haven't thought about it at all.  Why do they need it to
be preserved, let alone preserved in a broken way (80 bit registers
spilled into 64 bit memory)?  Remember - the code that's already
compiled is *always* going to be doing 64 bit spills.  It's only the
newly recompiled code that might get 80 bit spills.  The only thing we
can do to fix the old code is to run the FPU in double precision.
Without a doubt, many more things will get fixed than will get broken.

On the other hand, I don't even know why I'm arguing about it anymore!
I'll just stick the appropriate glibc call to put the FPU into 64 bit
mode in the main or MAIN or MAIN__ of all my code & be done with it.

 > Somehow I don't think slowing FP performance to a crawl in gcc will
 > be considered acceptable, and I believe setting the FPU this way would
 > indeed slow performance to a crawl.

Again, I think this is overkill.

-- 
Harvey J. Stein
BFM Financial Research
hjstein@bfr.co.il