This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Removing bits/mathinline.h


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]