This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/63464] compare one character to many: faster


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]