> Before going further with this, I'd suggest you have a look at your
> compiler settings.

They are set by the configure script:

gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes    -I. -I./Include    -DPy_BUILD_CORE -o
Objects/unicodeobject.o Objects/unicodeobject.c

> Such optimizations are normally performed by the
> compiler and don't need to be implemented in C, making maintenance
> harder.

The fact that the glibc includes such optimization (in much more
sophisticated form) suggests to me that many compilers don't perform
these optimizations automically.

> I tested using memchr() when writing those "naive" loops.

memchr() is mentioned in another issue, #13134.

> memchr()
> is inlined by the compiler just like the direct loop

I don't think so. If you look at the glibc's memchr() implementation,
it's a sophisticated routine, not a trivial loop. Perhaps you're
thinking about memcpy().

> and the generated
> code for the direct version is often easier to optimize for the compiler
> than the memchr() one, since it receives more knowledge about the used
> data types.

?? Data types are fixed in the memchr() definition, there's no knowledge
to be gained by inlining.