This is the mail archive of the
mailing list for the glibc project.
Old compiler optimizations in installed headers
- From: Joseph Myers <joseph at codesourcery dot com>
- To: <libc-alpha at sourceware dot org>
- Date: Fri, 22 May 2015 15:03:01 +0000
- Subject: Old compiler optimizations in installed headers
- Authentication-results: sourceware.org; auth=none
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