Old compiler optimizations in installed headers

[Joseph Myers <joseph at codesourcery dot com>]

We've recently had a discussion of whether it makes sense to keep various 
macros and inline functions in bits/string2.h that are only used for old 
GCC versions and only serve to optimize cases of small / constant 
arguments with those versions.  A similar issue applies to such things as 
inline __signbit* definitions in bits/mathinline.h - given 
<https://sourceware.org/ml/libc-alpha/2015-05/msg00521.html> could we just 
remove the various inlines on the basis that optimization for compilers 
before GCC 4.0 isn't a concern - and probably to various other inlines.

There was previously a discussion with a proposal in 
<https://sourceware.org/ml/libc-alpha/2013-01/msg00157.html> and with 
<https://sourceware.org/ml/libc-alpha/2013-01/msg00270.html> saying to 
avoid optimization regressions for old compilers.

Regarding what's supported at all, the baseline is C90 or C++98 plus long 
long support (although there are various places where headers in fact 
depend on other extensions to provide particular functionality).

Meanwhile, lots of architecture-specific .S function implementations in 
NPTL (especially, but maybe also elsewhere) have been removed, with 
benchmark evidence showing they don't actually provide better performance 
but do cause significant trouble in maintenance.

I'd like to propose that:

(a) if an optimization could clearly be done in the compiler - if it only 
depends on the standard semantics of standard functions, or fully-defined 
semantics of glibc functions that it would be reasonable to encode into 
GCC, rather than e.g. generating calls to a glibc-internal function - then 
we should be wary of adding it to glibc's headers in the first place: in 
accordance with principles of GNU projects working together, it's better 
to add the optimization to GCC; and

(b) where such optimizations are present in glibc headers and only 
relevant for GCC versions before some baseline (maybe 4.1 or 4.3), we 
should be willing to remove them to simplify the code and remove variants 
that aren't covered by normal glibc testing at all, without being 
concerned about worse code possibly being generated for users of old 
compilers.  Applying that principle to signbit and is* macros would allow 
complete removal of some mathinline.h implementations and removal of 
significant amounts of code from others.

-- 
Joseph S. Myers
joseph@codesourcery.com