4 ms·

It's worth pointing out that the author was reading an outdated implementation of strlen() from glibc. The generic implementation is still here with the same co

It's worth pointing out that the author was reading an outdated implementation of strlen() from glibc. The generic implementation is still here with the same code, and would be complied if no ARCH-specific implementation is written, as seen here, https://github.com/bminor/glibc/blob/master/string/strlen.c https://github.com/bminor/glibc/blob/master/string/strlen.c. But it's probably irrelevant to most systems today, as the assembly version is almost always used, e.g. * i386: https://github.com/bminor/glibc/blob/master/sysdeps/i386/strlen.S https://github.com/bminor/glibc/blob/master/sysdeps/i386/str... * i586/i686: https://github.com/bminor/glibc/blob/master/sysdeps/i386/i586/strlen.S https://github.com/bminor/glibc/blob/master/sysdeps/i386/i58... * i686 w/ SSE2: https://github.com/bminor/glibc/blob/master/sysdeps/i386/i686/multiarch/strlen-sse2.S https://github.com/bminor/glibc/blob/master/sysdeps/i386/i68... * i686 w/ SSE2 + BSF: https://github.com/bminor/glibc/blob/master/sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S https://github.com/bminor/glibc/blob/master/sysdeps/i386/i68... * x86_64 w/ SSE2: https://github.com/bminor/glibc/blob/master/sysdeps/x86_64/strlen.S https://github.com/bminor/glibc/blob/master/sysdeps/x86_64/s... * ARM: https://github.com/bminor/glibc/blob/master/sysdeps/arm/strlen.S https://github.com/bminor/glibc/blob/master/sysdeps/arm/strl... * ARMv6: https://github.com/bminor/glibc/blob/master/sysdeps/arm/armv6/strlen.S https://github.com/bminor/glibc/blob/master/sysdeps/arm/armv... * ARMv6T2: https://github.com/bminor/glibc/blob/master/sysdeps/arm/armv6t2/strlen.S https://github.com/bminor/glibc/blob/master/sysdeps/arm/armv... * ARMv8a/AArch64: https://github.com/bminor/glibc/blob/master/sysdeps/aarch64/strlen.S https://github.com/bminor/glibc/blob/master/sysdeps/aarch64/... * ARMv8a/AArch64 w/ ASIMD: https://github.com/bminor/glibc/blob/master/sysdeps/aarch64/multiarch/strlen_asimd.S https://github.com/bminor/glibc/blob/master/sysdeps/aarch64/... etc.

zamalek 7y ago
I was wondering how it would compare to the code produced by auto-vectorization, I guess it doesn't matter with hand-crafted assembly.
- kllrnohj 7y ago
  https://godbolt.org/z/QP3H-d https://godbolt.org/z/QP3H-d There isn't any auto-vectorization. Clang & GCC both do basically the same thing here.
- wahern 7y ago
  The compiler can't autovectorize because it can't assume it's okay to read past the end of the string. Only the human or the machine can make that determination, using special knowledge about the environment, such as that when locating the NUL byte out-of-bounds reads are okay so long as they don't cross a page boundary. And "okay" is a stretch because tools like Valgrind ship with huge lists of manually maintained suppressions to account for hacks like this that violate the standard rules.
  - flukus 7y ago
    But in this case a human applied their special knowledge in glibc, what's stopping the human applying the same knowledge to the compiler itself for this specific OS/arch?
    - wahern 7y ago
      Primarily because it would make it more difficult to detect and debug out-of-bounds reads, so at the very least it's not something you'd want to do by default, even at high optimization levels. Possibly it might also be an awkward, complex, or dangerous (as in risk of unintended consequences) optimization to selectively violate the memory model that way. But I'm not familiar with the internals of optimizing compilers, so that's just conjecture.

zamalek 7y ago

I was wondering how it would compare to the code produced by auto-vectorization, I guess it doesn't matter with hand-crafted assembly.

kllrnohj 7y ago
https://godbolt.org/z/QP3H-d https://godbolt.org/z/QP3H-d There isn't any auto-vectorization. Clang & GCC both do basically the same thing here.
wahern 7y ago
The compiler can't autovectorize because it can't assume it's okay to read past the end of the string. Only the human or the machine can make that determination, using special knowledge about the environment, such as that when locating the NUL byte out-of-bounds reads are okay so long as they don't cross a page boundary. And "okay" is a stretch because tools like Valgrind ship with huge lists of manually maintained suppressions to account for hacks like this that violate the standard rules.
- flukus 7y ago
  But in this case a human applied their special knowledge in glibc, what's stopping the human applying the same knowledge to the compiler itself for this specific OS/arch?
  - wahern 7y ago
    Primarily because it would make it more difficult to detect and debug out-of-bounds reads, so at the very least it's not something you'd want to do by default, even at high optimization levels. Possibly it might also be an awkward, complex, or dangerous (as in risk of unintended consequences) optimization to selectively violate the memory model that way. But I'm not familiar with the internals of optimizing compilers, so that's just conjecture.