This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Inline C99 math functions
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Wilco Dijkstra <wdijkstr at arm dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 15 Jun 2015 14:44:53 +0000
- Subject: Re: [PATCH] Inline C99 math functions
- Authentication-results: sourceware.org; auth=none
- References: <001201d0a75b$921d9860$b658c920$ at com>
On Mon, 15 Jun 2015, Wilco Dijkstra wrote:
> Add inlining of the C99 math functions
> isinf/isnan/signbit/isfinite/isnormal/fpclassify using GCC built-ins
> when available. Since going through the PLT is expensive for these small
> functions, inlining results in major speedups (about 7x on Cortex-A57
> for isinf). The GCC built-ins are not correct if signalling NaN support
Where are the benchmarks for this? Please put them in benchtests so
actual reproducible figures can be given. That's the standard practice
for any change being justified on the basis of performance.
What are the effects on code size (especially for fpclassify)? If code
becomes larger, conditioning on !defined __OPTIMIZE_SIZE__ should be
considered.
> As a result of this many target overrides and the various
> __isnan/__finite inlines in math_private.h are no longer required. If
> agreed we could remove all this code and only keep the generic
> definition of isinf/etc which will use the builtin.
How do those inlines compare with the code GCC generates? As I understand
it, before your patch libm-internal calls to these macros would have
called the inline versions of functions such as __finite (no function
call, PLT or otherwise, and using integer arithmetic), and after the patch
libm-internal calls would have used the GCC inlines (with floating-point
arithmetic) - is the new state for libm-internal calls better than the old
state or not?
> 2015-06-15 Wilco Dijkstra <wdijkstr@arm.com>
>
[BZ #15367]
[BZ #17441]
--
Joseph S. Myers
joseph@codesourcery.com