Re: weird optimization in sin+cos, x86 backend

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Mon, 13 Feb 2012, Vincent Lefevre wrote:

> Also note that CRlibm supports the 4 rounding modes, while the
> IBM Accurate Mathematical Library currently used in glibc behaves
> erratically (e.g. can even crash) on directed rounding modes.

FWIW the proposed ISO C bindings to IEEE 754-2008 (still at an early draft 
stage) include static rounding directions set by an FENV_ROUND pragma as 
well as dynamic rounding directions.

Assuming the processor only has one set of rounding modes so arithmetic in 
a static mode requires the compiler to insert code to save and restore the 
rounding mode, the rule is that function calls to functions in math.h and 
a few other headers are affected by the static mode but other calls are 
affected by the dynamic mode so the rounding mode would need restoring for 
the other calls.  You then have the cases:

* Dynamic rounding mode in effect: user calls a function such as sin, 
which should handle the mode it is called with (maybe checking what that 
mode is, then setting the mode to round-to-nearest for most of the 
internal calculations).

* Static mode in effect: can call sin with the dynamic mode set to that 
static mode, but may be better for the compiler to select a function for 
the right mode and call it directly if it knows what the functions for 
each mode are called.

Of course right now it would make sense for the problematic functions from 
the IBM Accurate Mathematical Library to be changed to set 
round-to-nearest internally if they can't handle other modes, to make 
things less bad until a better solution can be in place....

-- 
Joseph S. Myers
joseph@codesourcery.com