[PATCH] Optimize strchr (s, 0) to strlen

[Jakub Jelinek]

On Wed, Apr 20, 2016 at 11:17:06AM +0000, Wilco Dijkstra wrote:
> Can you quantify "don't like"? I benchmarked rawmemchr on a few targets
> and it's slower than strlen, so it's hard to guess what you don't like about it.

This is the same stuff as has been discussed for mempcpy, rawmemchr is the
API meant to use for getting pointer to the terminating '\0', if there are
deficiencies on the library side, they should be fixed.  If you hardcode in
GCC emitting worse sequence at the caller (which s + strlen (s) is), then
even once the library deficiency is fixed, you still don't get benefit from
it.  I wonder how you work around the
 define strchr(s, c) \
  (__extension__ (__builtin_constant_p (c) && !__builtin_constant_p (s) \
                  && (c) == '\0' \
                  ? (char *) __rawmemchr (s, c) \
                  : __builtin_strchr (s, c)))
in glibc headers anyway.

Another thing is for the cases where strlen is desirable to be expanded
inline, in that case rawmemchr (x, 0) or strchr (x, 0) is likely useful to be
expanded inline as well and then this decision should be done at expansion
time.

	Jakub