This is the mail archive of the
mailing list for the GCC project.
Re: Fourth Draft "Unsafe fp optimizations" project description.
- To: ejr at CS dot Berkeley dot EDU, moshier at moshier dot ne dot mediaone dot net
- Subject: Re: Fourth Draft "Unsafe fp optimizations" project description.
- From: dewar at gnat dot com
- Date: Wed, 15 Aug 2001 20:16:41 -0400 (EDT)
- Cc: gcc at gcc dot gnu dot org, kaih at khms dot westfalen dot de
<<a small range of numbers. For example, some people think that
a number represents all those numbers within half an ulp
around it (in round-to-nearest). Treating floating-point
Note an interesting difference here,
everyone agrees that the appropriate IEEE representation for
the set of numbers within half a ulp of IEEE number x is x
(what else could it be).
But if you say that the IEEE number *represents* this set of numbers
you are saying something else entirely, and indeed that's where the
contention that Jason refers to arises.
<<Most of 754 is dedicated to making simple solutions work
correctly. 754 allows for experts to do whatever, but it tries
to support non-experts who don't even know it exists. New ideas
should be tested against that metric. Flush-to-zero fails.
's of course true, and I agree with everything. Nevertheless it is
unfortunate that vendors have too often thumbed their noses at this
When I was writing the microprocessor column for Open Systems Today,
I got very nice access to the top designers of all the microprocessor
technologies. In the case of MIPS and the R10K, we spent quite a bit
of time talking about the decision to flush-to-zero on this processor
(when previous MIPS had handled denormals properly). The attitude of
the designers was that most users didn't care, and that raw speed was
My column (go look it up if you like) ended up being generally favorable
to the R10K design, but was strongly critical of this particular decision.
WHat is needed is far better education of programmers to understand better
what they are doing when they use fpt.
And to bring back some gcc relevance here, junk warnings on floating-point
equality do NOT contribute to this education, quite the contrary they
reinforce damaging myths, in particular the myth that floating-point is
a fuzzy approximation of real arithmetic, and since it's fuzzy, you don't
have to worry about just how fuzzy.