Re: [PATCH] Define __NO_MATH_INLINES and __NO_STRING_INLINES

["Joseph S. Myers" <jsm at polyomino dot org dot uk>]

On Tue, 25 May 2004, Giovanni Bajo wrote:

> this patch adds two new builtin defines on linux systems: __NO_MATH_INLINES and
> __NO_STRING_INLINES. These defines disable the inline assembly version of
> standard library functions in glibc, which conflict with the GCC builtins for
> the same functions.

I take it this doesn't cause problems for building glibc (which needs to
build exported versions of these functions into the library in case the
extern inlines from the headers aren't used - note newly compiled glibc
must keep exporting these to stay compatible with old programs needing
them)?  Maybe sysdeps/generic/string-inlines.c needs to #undef
__NO_STRING_INLINES (and something similar might be needed somewhere for
__NO_MATH_INLINES).

Since other systems than Linux (e.g. GNU Hurd, *bsd-gnu) use glibc, I
don't think linux.h is the right place.

Has this approach (predefining these macros) been agreed with the glibc
maintainers as the right way forward?  GNU projects should co-operate with
each other....

> This is known to positively affect speed on many testcases: see for instance
> http://gcc.gnu.org/ml/gcc/2004-04/msg00840.html. On the other hand, it might
> well be that we are still missing optimized builtins for some functions for
> which we are going to lose a fast assembly optimized version.

We have a list of string optimizations that at one point were in glibc but
not GCC, in projects/index.html.  Please check current glibc, including
the architecture-specific headers, and update this list to cover both
string.h and math.h optimizations that we don't have in GCC.  (Updating
the projects list should be routinely done when doing any patch affecting
something on it.)  We shouldn't base this on guesses about what might or
might not be lost; we should document exactly what needs to be done to be
uniformly better than glibc.  Note the list was never complete as it only
documented optimizations that could be done to ISO C functions without
calling non-ISO functions; defining these macros commits GCC to a wider
aim of optimizing non-ISO functions as well (some such optimizations have
already been done, but without updating the projects list).

Benchmarks are good, but they mix performance on different functions.  
Each function's inline can reasonably be disabled separately, using
fixincludes, or a patch to glibc to add an appropriate __GNUC_PREREQ
conditional; the latter also benefits people using glibc with a range of
different compilers by tuning the inlines to their version.

Note the comments in the projects list that:

   Care must be taken that any optimizations in GCC are
   standards-conforming in terms of not possibly accessing beyond the
   arrays involved (possibly within a function call created in the 
   optimization); whereas the glibc macros know the glibc implementation
   and how much memory it might access, GCC optimizations can't.

   There are some further optimizations in glibc not covered here, that
   either optimize calls to non-ISO C functions or call glibc internal
   functions in the expansion of the macro.

These are not fundamental problems, as long as we are prepared to add
mechanisms for the relevant information about library functions to be
provided to GCC, whether through target macros (with corresponding
restrictions on supported glibc versions) or pragmas.  The information
that may be used is such information as "this function accesses no more
than n bytes beyond the point where the strings differ", "an __mempcpy
function is available", "an __rawmemchr function is available".

> * The correct way to operate for the present and the future is to use GCC
> builtins for anything for which it would make sense to provide an inline
> version in glibc.

Agreed.  My concern is that each release should be *uniformly* no worse
than previous releases; *each* function should perform as well with GCC
built-ins as with the glibc inlines, not just benchmarks which may well
not test some of the more obscure functions.  The benchmarks are enough
for it to make sense to put this patch in now without waiting for every
glibc optimization to be implemented in GCC - provided we document every
optimization we are missing, in the projects list or (maybe better) in
Bugzilla as regressions, and have agreement from the glibc maintainers
that they will add no more optimizations that are disabled by
__NO_STRING_INLINES or __NO_MATH_INLINES, instead deferring purely to the
compiler for all future such optimizations.

-- 
Joseph S. Myers
jsm@polyomino.org.uk