[Bug target/34702] 1.0 is not the inverse of 1.0 with -mrecip on x86

["ubizjak at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #6 from ubizjak at gmail dot com  2008-01-08 14:02 -------
(In reply to comment #3)

> It looks nice, but could you add (after converting my frenglish) something
> along the line "in particular the inverse of 1.0 is no longer 1.0, but
> 0.99999994" (or nearest(1.0,-1.0) or its C* equivalent).

I have added a small example you provided to the text:

--cut here--
... are generated only when @option{-funsafe-math-optimizations} is enabled
together with @option{-finite-math-only} and @option{-fno-trapping-math}.
Note that while the throughput of the sequence is higher than the throughput
of the non-reciprocal instruction, the precision of the sequence can be
decreased up to 2 ulp (i.e. the inverse of 1.0 equals 0.99999994).
--cut here--

The point of -mrecip is to create the sequence with the fastest throughput
possible on the expense of the precision. Please note, that we operate on
SFmode here, so precision should be of no concern. While plain rcpss & friends
are not precise enough to be even remotely usable (and they can be accessed
using builtins anyway), the NR enhanced reciprocals provide adequate precision
with great speedup. However, it looks that none of them are good enough for
plain -ffast-math, mainly due to direct comparisons of FP values as in exmple
you provided.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34702