This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: bzero/bcopy/bcmp/mempcpy (was: Improve strncpy performance further)
- From: "Wilco Dijkstra" <wdijkstr at arm dot com>
- To: "'Roland McGrath'" <roland at hack dot frob dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Wed, 14 Jan 2015 14:11:16 -0000
- Subject: RE: bzero/bcopy/bcmp/mempcpy (was: Improve strncpy performance further)
- Authentication-results: sourceware.org; auth=none
- References: <001801d02b72$6ce0c3c0$46a24b40$ at com> <20150108185812 dot 285782C3BF6 at topped-with-meat dot com> <001901d02c0d$43cf9920$cb6ecb60$ at com> <20150109191632 dot 694692C3C1F at topped-with-meat dot com> <001a01d02dc9$bd6f0370$384d0a50$ at com> <20150113191449 dot AD91B2C39DC at topped-with-meat dot com>
Roland McGrath wrote:
> There are no uses of bcopy outside of tests, and portability macros in code
> (possibly, or once) shared with gnulib. There is a bcopy macro in
> locale/programs/simple-hash.c, but it's not used anywhere. I've removed
> that in the patch below.
>
> There are three uses of bzero outside of tests. I've changed those to
> memset in the patch below. In my build (x86_64-linux-gnu, GCC 4.8.3) this
> did not change the compiled code at all--so they were already being reduced
> to memset or inlined directly by the compiler.
GCC often expands bzero into memset, but not all versions do this, and neither
do all options, so you cannot rely on this. So before your patch login/logout.c
might actually call bzero...
We need something like this in string.h so we always optimize all calls to
standard optimized functions, irrespectively of the compiler and options used:
#ifdef __USE_MISC
# define bzero(s, n) memset (s, '\0', n)
# define __bzero(s, n) memset (s, '\0', n)
# define bcopy(src, dest, n) memmove (dest, src, n)
# define bcmp(s1, s2) memcmp(s1, s2)
#endif
Does that seem reasonable?
Now the only remaining one to deal with is mempcpy - I'd like something like
this in string/strings2.h:
#define mempcpy(dest, src, n) __mempcpy_inline (dest, src, n)
__STRING_INLINE void *__mempcpy_inline (void *dest, void *src, size_t n)
{
return memcpy(dest, src, n) + n;
}
If there are targets which want to keep using their optimized version, then
the above could be guarded by a define (eg. _HAVE_OPTIMIZED_MEMPCPY) which would
be defined by any target which has an optimized mempcpy. Or is there an easier way
to test whether a target has added an optimized version of a generic function?
> Here's what I've just committed. As I mentioned above, it caused no
> changes to the compiled code on x86_64-linux-gnu with gcc-4.8.3, except for
> the expected s/bcmp/memcmp/ changes that are trivially provably harmless.
Thanks, that looks good.
Wilco