Jakub Jelinek <ja...@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
