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: Roland McGrath <roland at hack dot frob dot com>
- To: "Wilco Dijkstra" <wdijkstr at arm dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Wed, 14 Jan 2015 11:32:44 -0800 (PST)
- 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> <001e01d03003$f67b8670$e3729350$ at com>
> 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...
Sure.
> 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:
We would need that if we wanted to do that. But these entrypoints are all
old and deprecated. They are only for the benefit of old code. Any code
so old that it hasn't been touched since there were actually systems to
build it on that don't have the C89 standard functions surely has worse
performance issues than this. Making the deprecated functions optimal only
encourages people to keep using them.
> Now the only remaining one to deal with is mempcpy - I'd like something like
> this in string/strings2.h:
Why? It's trivial enough for each memcpy implementation to implement
mempcpy too, and for many implementations rolling it in might save an
instruction or two over the generic addition. It doesn't seem worth
the complexity to bother with anything in the header files.