This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Removing bits/mathinline.h
- From: Joseph Myers <joseph at codesourcery dot com>
- To: <libc-alpha at sourceware dot org>
- Date: Mon, 12 Mar 2018 21:17:28 +0000
- Subject: Removing bits/mathinline.h
- Authentication-results: sourceware.org; auth=none
We have a general principle of preferring optimization of calls to glibc
functions, where that optimization can be done on the basis of the
standard semantics of the functions in question, to be done through
compiler built-in functions rather than inline functions and macros in
glibc headers. This helps make the semantics of the code clearer to the
compiler, where early optimization with inline functions and macros tends
to obscure it, and allows optimization based on per-function settings and
information about which code is hot or cold, which is not possible for
header-based optimization.
In accordance with this principle I'd like to propose that we should aim
to eliminate bits/mathinline.h, and with it the separate libm tests for
inline function variants and the libm-test-ulps entries for those tests.
There would be several parts to such a removal; any comments on this
proposal?
1. Where the bits/mathinline.h contents are only active at all for old
compiler versions, I think the removal should be uncontroversial.
2. Likewise, where the relevant compiler optimizations have already been
present for a long time but the header optimizations still aren't
disabled.
3. In the cases where current GCC doesn't have the relevant optimizations,
I'd still propose to remove the bits/mathinline.h optimizations (filing a
GCC bug for such missing optimizations but not requiring it to be fixed to
remove the header optimizations).
4. Where the inlines are used for building glibc itself (defined for
__LIBC_INTERNAL_MATH_INLINES) they would move to a non-installed header
such as math_private.h. This is without prejudice to other possible
changes that might eliminate the need for such inlines for building glibc,
such as moving to using built-in sqrt directly, with -fno-math-errno,
instead of using __ieee754_sqrt (some of the __LIBC_INTERNAL_MATH_INLINES
cases are for __ieee754_sqrt functions; other architecture already have
those inlines in math_private.h instead).
5. That applies the same to most or all of the contents of the m68k
bits/mathinline.h, which is required for building the out-of-line libm
functions for m68k. Right now, building for m68k with -Os is broken
because of bits/mathinline.h not being included by math.h in that case.
--
Joseph S. Myers
joseph@codesourcery.com