This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Use strlen when searching for a nul char
- From: Joseph Myers <joseph at codesourcery dot com>
- To: <pinskia at gmail dot com>
- Cc: Wilco Dijkstra <wdijkstr at arm dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 7 Oct 2015 15:20:31 +0000
- Subject: Re: [PATCH] Use strlen when searching for a nul char
- Authentication-results: sourceware.org; auth=none
- References: <003a01d1010c$ad404240$07c0c6c0$ at com> <5F638E7C-B8BD-4F94-8278-1F8B359CACCA at gmail dot com>
On Wed, 7 Oct 2015, pinskia@gmail.com wrote:
> > On Oct 7, 2015, at 7:30 AM, Wilco Dijkstra <wdijkstr@arm.com> wrote:
> >
> > Expand strchr (s, '\0') in C/C++ to use strlen. This is faster on most
> > targets as strlen is a simpler function. Passes GLIBC tests. I'm
> > planning to do the same for strrchr, strchrnul and rawmemchr in future
> > patches as people frequently use all of these to find the end of a
> > string.
> >
> > OK for commit?
>
> Shouldn't this also be an optimization inside gcc if not already?
I agree; I'd rather discourage the addition of such optimizations as
inlines in glibc unless they depend on information that's inherently not
available to GCC (e.g. properties of architecture-specific function
implementations in glibc). As I said before in
<https://sourceware.org/ml/libc-alpha/2015-06/msg00146.html> the aim
should be to make the GNU system as a whole as good as possible.
(And please accompany performance claims such as "faster on most targets"
with figures from the benchtests or a reason it's hard to produce such
figures. In this case I think the transformation could be justified for
GCC as something architecture-independent without specific performance
claims - strlen being inherently simpler because it only ever has to
search for 0 bytes, so it should never be asymptotically slower than the
alternative and may be faster.)
--
Joseph S. Myers
joseph@codesourcery.com