[PATCH] Inline C99 math functions

[Joseph Myers]

On Tue, 16 Jun 2015, Wilco Dijkstra wrote:

> > Well, the benchmark should come first....
> 
> I added a new math-inlines benchmark based on the string benchmark 
> infrastructure.

Thanks.  I await the patch submission.

> So this clearly shows the GCC built-ins win by a huge margin, including the
> inline versions. It also shows that multiple isinf/isnan calls would be faster

That's interesting information - suggesting that changes in GCC to use 
integer arithmetic should be conditional on -fsignaling-nans, if doing the 
operations by integer arithmetic is slower (at least on this processor).

(It also suggests it's safe to remove the existing glibc-internal inlines 
as part of moving to using the built-in functions when possible.)

> > > Codesize of what? Few applications use these functions... GLIBC mathlib is
> > 
> > Size of any code calling these macros (for nonconstant arguments).
> 
> Well the size of the __isinf_t function is 160 bytes vs isinf_t 84 bytes
> due to the callee-save overhead of the function call. The builtin isinf uses
> 3 instructions inside the loop plus 3 lifted before it, while the call to
> __isinf needs 3 plus a lot of code to save/restore the callee-saves.

One might suppose that most functions using these macros contain other 
function calls as well, and so that the callee-save overhead should not be 
included in the comparison.

When you exclude callee-save overhead, how do things compare for 
fpclassify (the main case where inlining may be questionable when 
optimizing for size)?

-- 
Joseph S. Myers
joseph@codesourcery.com