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

[Craig Burley <burley@gnu.org>]

>On Thu, Dec 17, 1998 at 02:27:02PM -0500, Brad Lucier wrote:
>> If that means spilling FP registers to 80 bit temporaries aligned to
>> 128-bit (or 64bit) boundaries, then so be it.
>
>Given that the speed penalty of this solution might be very small, except for
>(?) degenerate cases, we should not accept or decline this solution unless
>somebody states some hard data (read: benchmarks).

Apparently no hard data at all is needed for several people to have
already concluded my proposal is a "loser all around" and constitutes
nothing more than "numerical political correctness" -- some of the
people I've trusted most to be thoughtful and considerate before
making such statements in the past.

I'm now sorry to have proposed it in the first place.  It seems
to have been a huge waste of time, at least on my part.  I suspect
someday it'll be clear my proposal was both ahead of, and behind,
its time: ahead, because it seems quite likely the rest of the
industry will decide to go in that direction anyway (as some parts
apparently already do), and gcc will have to follow; behind, because
if gcc had long-ago been implemented on the x86 the way the x87 (FP unit)
designer apparently intended it to be used, we'd be discussing whether
to add an option to provide 32/64-bit spills to get extra performance,
and it's unlikely people would be calling the 80-bit spills a "loser
all around", but simply a "reasonable default" that some very
knowledgable users might wish to override for performance reasons.

In the meantime, I'll withdraw my proposal.  Which means I no longer
suggest the planned x86 machine-description rewrite, or any other
part of gcc, take into consideration the potential need for 80-bit
spills at all.  After all, if the performance is already known to
be a major problem, there's no need to even experiment with an
option to enable them, and certainly we wouldn't make it the default.

(If we someday decide we want to, as I expect will happen, we can just
rewrite the appropriate parts of gcc -- again.)

In case it isn't clear: I'm withdrawing my proposal only because
I don't really want to argue about it anymore, and I've decided I must
have completely lost touch with what is appropriate for Fortran and
gcc users, generally, to have so completely missed the boat on
how important performance might be to various people, so I probably
shouldn't be making such proposals in the first place.  Besides, it's
probably better for me to read up on all the relevant issues -- e.g.
become a numerical-analyst expert, so I too can know what's needed
to write working FP code -- before talking about it, or working on
related Fortran stuff, further.

So, for now, I'll just stick with fixing g77 bugs and doing other
non-FP work (once I get back from Christmas vacation, anyway), until
I can figure out what I *am* qualified to discuss, propose, design,
implement, and so on, and how to become more competent in the
relevant areas.

        tq vm, (burley)