https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464
--- Comment #6 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #1)
> We have this optimization implemented for switches,
Thanks, that's indeed the most natural place for it, although I hadn't thought
of testing that...
Glibc's strspn has:
__STRING_INLINE size_t
__strspn_c3 (const char *__s, int __accept1, int __accept2, int __accept3)
{
size_t __result = 0;
/* Please note that __accept1 to __accept3 never can be '\0'. */
while (__s[__result] == __accept1 || __s[__result] == __accept2
|| __s[__result] == __accept3)
++__result;
return __result;
}
This is only called when optimizing and with a second argument that is a string
literal, but it is still inconvenient to turn that into a switch, so it seems
useful to optimize this form as well (well, maybe we could expand
__builtin_strspn in gcc instead so it also works for larger constant second
arguments, but creating a loop is not so nice and there are plenty of other
similar functions).
(By the way, those optimizations are protected by a test __builtin_constant_p
(s) which only seems to be true if passing _directly_ a string literal, maybe
__builtin_constant_p could be made to return true a bit more often, or glibc
could test instead __builtin_constant_p (s[0]) etc)
(For completeness, I also compared with a "repne scasb; je" version I found
somewhere in glibc, which was more than 20 times slower, and quite difficult to
generate since we don't allow clobbers on asm goto...)