Re: [PATCH] Define __NO_MATH_INLINES and __NO_STRING_INLINES

[Jakub Jelinek <jakub at redhat dot com>]

On Thu, May 27, 2004 at 04:13:11AM +0200, Giovanni Bajo wrote:
> The fact that we have many regressions for each new version show that this is
> much of an ideal goal. A good one, indeed, but ideal. My patch is probably
> going to increase performance for many users, and cause a few regressions. I
> believe this is true for most patches we apply. Yet, we are in stage 1. We
> still merged tree-ssa, which is known to have regressions that will be fixed
> before release, so I hope my patch is just acceptable as well.

Please consider
http://sources.redhat.com/ml/libc-hacker/2004-05/msg00043.html
http://sources.redhat.com/ml/libc-hacker/2004-05/msg00047.html
http://sources.redhat.com/ml/libc-hacker/2004-05/msg00048.html

I wonder if you can come up with a benchmark which would justify your change
now.  I'm fairly certain GLIBC 2.3.4 will be out long time before GCC 3.5
(or 4.0?).

BTW; __builtin_bzero should be IMHO changed, so that if clear_storage called
from it decides to call a function instead of expanding inline, it doesn't call
memset (x, '\0', y) but bzero (x, y).
glibc then can have a choice between defining __bzero (s, n) to
__builtin_memset (s, '\0', n) (for architectures where it implements bzero
as a wrapper around memset and thus memset is more efficient, see e.g. ppc)
and __builtin_bzero (s, n) which could be used on arches where bzero library
function is faster than memset.

	Jakub