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...)