[PATCH, i386]: Rewrite x87 sqrt patterns
Michael Matz
matz@suse.de
Wed Nov 22 13:29:00 GMT 2006
Hi,
On Wed, 22 Nov 2006, Uros Bizjak wrote:
> > > > The i386 sqrt patterns doesn't truncate the result of fsqrt x87
> > > > instruction.
> > >
> > > And neither do add, sub. mult, or div. What's special about sqrt
> > > that it deserves this treatement?
> >
> > Right. If you _really_ want to fix x87 you'll have to explicitely
> > truncate every intermediate result, just like -ffloat-store. I guess
> > nobody wants that, so why do it for sqrt?
>
> Because there is a difference between returned results when sqrt() is
> implemented as a builtin function or when it is implemented as a library
> call. This is similar to the problems of __builtin_fmod() vs fmod()
> library call on x87.
>
> So, is it tolerable to substitute sqrt() call with a __builtin_sqrt()
> that returns "different" results?
I have no authority here, but given that x87 is as it is you don't even
get any interesting precision guarantee about division, so it doesn't seem
to make much sense to require such guarantees from sqrt, hence yes, IMHO
it is tolerable that __builtin_sqrt and sqrt return different results on
x87 (different meaning with more precision, not arbitrary differences :)
).
> If it is, could __builtin_fmod() also return different results than
> fmod()?
The same argumentation as above would hold IMHO. Unless I'm missing
something peculiar about fmod's usecases (for instance if it is the only
way to determine some property about the arithmetic in use, it might make
sense to require more strictness from it than what is guaranteed by the
base operations).
Ciao,
Michael.
More information about the Gcc-patches
mailing list