Re: Improving math function wrappers

[Wilco Dijkstra <Wilco.Dijkstra@arm.com>]

Joseph Myers <joseph@codesourcery.com> wrote:

> Code in glibc's libraries should already be setting the TLS initial-exec 
> errno variable directly (that's how __set_errno is defined in 
> include/errno.h).  But any case that sets errno should not be 
> performance-critical; the issue is the effects on performance of non-error 
> cases with finite arguments (which should just be checking if the result 
> is non-finite or zero, depending on the function - but the issue raised 
> here was consequent need to save the arguments for subsequent checks in 
> the unlikely case to see whether e.g. a NaN result was an error or from a 
> NaN argument, and it's possible the code in the error case might have 
> other prologue/epilogue effects that don't get shrink-wrapped away).

Setting errno is not in any way performance critical indeed - even a function
call would be fast enough. It is cases like this that show up as having a high
overhead:

double
__pow (double x, double y)
{
  double z = __ieee754_pow (x, y);
  if (__glibc_unlikely (!isfinite (z)))
     ...
  else if (__builtin_expect (z == 0.0, 0)
	   && isfinite (x) && x != 0 && isfinite (y)
	   && _LIB_VERSION != _IEEE_)
     ...

This means saving and restoring x and y across the call (ie. setting up a stack
frame with 3-4 callee-saves) and 2 if statements on the critical path - all
completely unnecessary.

Inlining __ieee754_pow would help but still keep the extra checks - so moving
them into existing checks for special cases is best if we can't remove errno support.

> If we set errno in some main function implementations I think we should be 
> clear that adding a wrapper is still a fine way to fix one of the 
> remaining bugs about missing errno setting in cases where 
> architecture-specific implementations are involved, with the option of 
> optimizing later by moving away from that wrapper.

Yes, we'd still have to keep the wrapper if there are any targets that require it.
It could be removed once such code has been updated or if the generic
implementation ends up faster (quite likely given this happened for several string
functions)...

Wilco