This is the mail archive of the
mailing list for the glibc project.
Re: Should we optimize memset to bzero?
- To: "H . J . Lu" <hjl at lucon dot org>
- Subject: Re: Should we optimize memset to bzero?
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Date: Fri, 2 Nov 2001 18:01:47 +0000 (GMT)
- cc: Jakub Jelinek <jakub at redhat dot com>, GNU C Library <libc-alpha at sources dot redhat dot com>
On Fri, 2 Nov 2001, H . J . Lu wrote:
> > Well, the thing is that glibc further optimizes __bzero(s,n) with
> > __builtin_memset(s,0,n); which often generates better code.
> > But, teaching gcc that it can use __bzero is difficult, since __bzero
> > is not part of any standard.
> Do we have any ideas when gcc will inline __builtin_memset(s,0,n)? I don't
> believe gcc will inline it if `n' is not a small constant. Can we guess what
> that small constant is?
Glibc shouldn't try to second-guess GCC here. Instead, *all* the inline
optimisations for standard string functions should move into GCC. Glibc
will then need to communicate to GCC that it has certain functions such as
__bzero that the built-in functions may reduce to. I've previously
suggested an implicitly included <stdc-macros.h> header that GCC would
automatically include (if it exists) before every translation unit in
order to define __STDC_ISO_10646__ (which describes library properties
that change with the glibc version, but must be constant throughout the
translation unit rather than just after some standard header has been
included) properly. This header could then include pragmas to declare the
availability of certain library functions, e.g.
#pragma GCC function_available __bzero
#pragma GCC function_available __rawmemchr
#pragma GCC function_available __mempcpy
Joseph S. Myers