This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, i386]: Rewrite x87 sqrt patterns


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]