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

[Craig Burley <burley at gnu dot org>]

>Given this, then doing 80 bit spills will fix things *only* if you
>guarantee that once a value hits the FPU it remains 80 bit (aka 80 bit
>contagion).  I.e. - the compiler can't store back into a double (for
>example) and then fetch this value back for additional computations.
>It has to always get the value from 80 bit memory instead.

Isn't that what we've been discussing from the beginning, i.e. from
the first email I sent containing my proposal?  Else, what have *you*
been talking about?

>If gcc actually does this, then great.  80 bit spills will fix the
>numerics and also give the excess precision people are demanding.  I
>haven't actually met any of these people, but rumor has it that they
>exist. :)

Been reading egcs-bugs lately?

>However, if gcc *doesn't* guarantee this, then the numerics will still
>suck, even with 80 bit spills.  They'll just suck less often.

I'm still not convinced we can guarantee this.  Even if we can't,
fixing this problem that we *do* know about will allow us some
time and breathing room to let *all* of us -- developers and users --
find out what further needs to be done, *and* what it might actually
cost.

>On the other hand, running the FPU in 64 bit mode *will* guarantee
>this at least for computations done on double precision numbers.  As
>for the single precision computations, this property won't hold, so
>they'll still suck, *but*, they'll suck exactly as much as the double
>precision computations would have sucked with an 80 bit FPU & 80 bit
>spills.

Since my proposal is not likely to be implemented anytime soon, I
suggest we try patching gcc to force programs to start in 64-bit
mode and otherwise not worry about it ("set once and forget") as
you've been proposing.

Then, leave this in the snapshots for as long as it takes to get some
real feedback on it, while publically encouraging people with numerical
codes, other libraries, and so on to try it out and see how it works.

Of course, we'd have to make it clear that this is not a committed-to
strategy, but is being done to collect data on its impact, so people
shouldn't start rewriting or recompiling their libraries to accommodate
it just yet.

>The choice is clear, at least for me.  I'm setting the FPU to 64 bit
>mode in all my code.  Maybe I'll even put it in crt0.o.

Yup.  We should do this (whichever gives the most coverage) across
the board in enough egcs snapshots to find out how it actually
affects people, e.g. how much other code must be rewritten.

As I've already pointed out, this is a proposal that might well break
things, possibly well down the road after we *think* it won't.

My proposal is unlikely to break things to nearly the same extent,
though it might slow things down a bit.  That's mainly why I prefer
it.

But the only way to convince some of you that I'm right about 64-bit-mode
FPU possibly breaking things is to convince you to install it, and see
what happens.  That way we can all find out for ourselves.

Again, I'm *not* in support of this proposal.  I *am* in support of
collecting data for it, and, since *my* proposal will take some time
to implement, we might as well implement this much-easier proposal
(at least that's how it could ideally work out) and see what happens,
if only to stop people from claiming that 64-bit-mode is some kind
of panacea (though it'd be great if it was).

What most worries me about your approach is how *clear* the choice
is for you *already*, without having all the data I see as necessary
for *any* of us to make a decision.  Being so willing to change such
a fundamental aspect of the processor's behavior when any gcc-compiled
main program starts running, without even *trying* to learn how that
might affect existing code, strikes me as rather irresponsible.  But
maybe you're right and I'm wrong; in any case, you don't seem to
pay attention to my warnings about this, so go ahead and implement it.
Maybe the feedback we get will convince you.  It's even possible it'll
stop me from worrying anymore.

>And I also realized why I'm still arguing about it.  I think people
>who find the problem have an easy & reasonable fix, so I don't think
>the whole thing really is a big issue.  But, I'd just like the issues
>to be clear for all involved.

I agree with that last part, definitely.  But people with code that
is 32-bit and/or 64-bit and is not able to handle intermediate
results that are sometimes 80-bit, sometimes chopped to 32/64 bits,
do *not* have an easy & reasonable fix, IMO, unless you count "stop
using gcc on the x86 [and m68k?]" as one.  But if you know of a
reasonable fix for each the cases that might come up, write up the
docs so we can check it out for ourselves, and evaluate those
fixes in terms of their clarity, expressiveness, and performance
on compiler/CPU combinations *other* than gcc/x86.

        tq vm, (burley)