This is the mail archive of the 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: weird optimization in sin+cos, x86 backend

On Thu, 9 Feb 2012, Andrew Haley wrote:

> Okay, but the crlibm algorithms could be extended to long
> doubles and, presumably, floats.  Where's Vincent Lefevre
> when you need him?   :-)

The crlibm approach, involving exhaustive searches for worst cases for 
directed rounding, could as I understand it work for functions of one 
float, double or 80-bit long double argument, but I think the exhaustive 
searches are still infeasible for binary128 (113-bit mantissa) long 
double - although you could do functions that are probably (not proven) 
correctly rounded in that case.  For functions of two arguments such as 
pow, I don't know if it can produce proven correctly rounded versions even 
for float.

IBM long double (double+double) is a special case likely to need its own 
implementations of many functions.  In that case it's not very 
well-defined what correctly rounded even means (you *can* define it to be 
the closest representable double+double value, but I doubt that's feasible 
to implement in libm although it could be done for constant folding with 
MPFR, and the basic arithmetic operations don't claim to achieve it).  
Probably the best that's sensible is an output within a few ULP (ULPs 
defined as if the representation is fixed-width mantissa of 106 or 107 
bits except for subnormals) of the mathematical value of the function at 
an input within a few ULPs of the specified value - this may also be the 
best that's possible for other floating-point formats for some 
hard-to-calculate functions.

Joseph S. Myers

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