Re: Improving math function wrappers

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 16 Mar 2017, Szabolcs Nagy wrote:

> On 16/03/17 14:29, Joseph Myers wrote:
> > On Thu, 16 Mar 2017, Wilco Dijkstra wrote:
> > 
> >> Given other languages don't even have the concept of errno, C99 doesn't 
> >> require it, and no application ever reads errno, it is inefficient to 
> >> force the use of the wrappers in almost all cases.
> > 
> > C99 not requiring it was an incompatible quiet change from C90.
> 
> i think glibc only has to set errno when user code is
> compiled with c89 compatibility and even then only for
> math functions that were defined in c89 and then only
> guarantee correct errno setting in default rounding mode
> (c89 code cannot access the fenv).

Incompatible quiet change means a good idea to implement the compatible 
mode ((math_errhandling & MATH_ERRNO) != 0) as far as possible.  Just like 
it's a good idea to avoid size_t wider than unsigned long.

Compilers for non-C languages without the concept of these functions 
setting errno can of course default to -fno-math-errno by default (and 
built-in no-errno functions that can be used with -fmath-errno is 
otherwise enabled would also be desirable for fma, sqrt, etc.).

> > (There may be cases where errno setting in the main implementations will 
> > require adding checks there not currently present, if e.g. the function 
> > does "return x - x;" in the non-finite argument case to return NaN and 
> > also raise "invalid" for Inf arguments - but such cases should not 
> > generally be significant for performance; the performance relevant cases 
> > are those involving finite arguments and results, not error cases or NaNs 
> > as arguments.)
> 
> i don't think setting errno in asm would be necessary,
> just turn "return x-x;" into "return specialcase1(x);"
> where specialcase1 is generic c code shared by targets,
> these are only called in cold code paths (if the errno
> setting is in a hot path then wrapper vs no wrapper
> does not make much difference and a wrapper can always
> be in c)

Whether the asm code calls a special-case function or __errno_location or 
sets TLS errno directly doesn't make much difference, you still need lots 
of target-specific checks for NaNs / overflow etc.  (Some cases may 
already be inside cold paths, some, e.g. overflow / underflow where the 
exception is implicit from the calculation but errno needs an extra check, 
may not, although the value to check should at least already be in a 
register.)

-- 
Joseph S. Myers
joseph@codesourcery.com