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

[Craig Burley <burley@gnu.org>]

>What would the performance cost be if we spilled ix86 FP registers
>as 80 bits?  Unfortunately I'm not familiar enough with the ix86
>instruction set to answer this question for myself.  How difficult
>would it be to change gcc to do 80 bit spills, without changing
>the size of float and double?

I think the performance cost is likely to be pretty minor, mostly
not noticeable, since it doesn't affect any code that isn't already
spilling 80-bit values by chopping them down.  (Though I guess
any code that makes certain uses of functions returning FP values
are likely to do such spills...but a bit of extra cache usage
around a procedure call isn't usually a noticeable hit against
performance, right?)

It's the difficulty of changing gcc that I think is the biggest
problem.

>It seems to me that it should cost a lot less than -ffloat-store
>and should get rid of the unpredictable behavior.  (Yes, it still
>doesn't match IEEE unless more is done, but it stops weirdness like
>root-finding algorithms that fail to converge if you're unlucky).

What I've come to believe is that, without this change, -ffloat-store
is useless except for the lucky and the very, very careful (who
also accept comparatively poor performance).  With this change,
-ffloat-store adds reasonable stability on top of reasonable
stability.

I don't feel comfortable saying that even the combination of this
change and -ffloat-store results in complete stability/predictability,
however, because I just don't know enough to say that, and I tend
to be pessimistic about such things.

        tq vm, (burley)