This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Optimize strchr (s, 0) to strlen
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, nd <nd at arm dot com>
- Date: Mon, 18 Apr 2016 17:30:53 +0000
- Subject: Re: [PATCH] Optimize strchr (s, 0) to strlen
- Authentication-results: sourceware.org; auth=none
- Nodisclaimer: True
- References: <AM3PR08MB0088CA61259F65FAAB4D8196836B0 at AM3PR08MB0088 dot eurprd08 dot prod dot outlook dot com>,<20160418170900 dot GK2920 at laptop dot zalov dot cz>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, Apr 18, 2016 at 05:00:45PM +0000, Wilco Dijkstra wrote:
>> Optimize strchr (s, 0) to s + strlen (s). strchr (s, 0) appears a common
>> idiom for finding the end of a string, however it is not a very efficient
>> way of doing so. Strlen is a much simpler operation which is significantly
>> faster (eg. on x86 strlen is 50% faster for strings of 8 bytes and about
>> twice as fast as strchr on strings of 1KB).
>
> That is generally a bad idea, it really depends on the target.
> So, perhaps such decision should be done on a case by case basis,
> and certainly not this early.
> Often strchr (s, 0) should be just optimized as rawmemchr (s, 0) instead.
I don't see how it would depend on the target - under what circumstances could
strchr possibly be faster than strlen? The former must do 2 comparisons per
character - the latter only 1.
Note rawmemchr is a non-standard function, ie. GCC would need to be told
whether the target library supports it, so it would require new builtins and
infrastructure.
Also rawmemchr is significantly slower than strlen on most targets, even when
an assembly implementation is available. That's why I posted this patch for GLIBC:
https://sourceware.org/ml/libc-alpha/2016-04/msg00382.html
Wilco