[all-commits] [llvm/llvm-project] 8701c2: Refactor WIDE_READ to allow finer control over hig...

[Sterling-Augustine via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 8701c2a9106bcf4b9c1178125b56958f9aab7faf
      https://github.com/llvm/llvm-project/commit/8701c2a9106bcf4b9c1178125b56958f9aab7faf
  Author: Sterling-Augustine <saugustine at google.com>
  Date:   2025-12-04 (Thu, 04 Dec 2025)

  Changed paths:
    M libc/cmake/modules/LLVMLibCCompileOptionRules.cmake
    M libc/config/config.json
    M libc/config/linux/arm/config.json
    M libc/config/linux/config.json
    M libc/config/linux/riscv/config.json
    M libc/docs/configure.rst
    M libc/src/string/memory_utils/aarch64/inline_strlen.h
    M libc/src/string/memory_utils/generic/inline_strlen.h
    M libc/src/string/memory_utils/x86_64/inline_strlen.h
    A libc/src/string/string_length.h
    M libc/src/string/string_utils.h
    M utils/bazel/llvm-project-overlay/libc/BUILD.bazel
    M utils/bazel/llvm-project-overlay/libc/libc_configure_options.bzl

  Log Message:
  -----------
  Refactor WIDE_READ to allow finer control over high-performance function selection (#165613)

[This is more of a straw-proposal than a ready-for-merging PR. I got
started thinking about what this might look like, and ended up just
implementing something as a proof-of-concept. Totally open to other
methods an ideas.]

As we implement more high-performance string-related functions, we have
found a need for better control over their selection than the big-hammer
LIBC_CONF_STRING_LENGTH_WIDE_READ. For example, I have a memchr
implementation coming, and unless I implement it in every variant, a
simple binary value doesn't work.

This PR makes gives finer-grained control over high-performance
functions than the generic LIBC_CONF_UNSAFE_WIDE_READ option. For any
function they like, the user can now select one of four implementations
at build time:

1. element, which reads byte-by-byte (or wchar by wchar)
2. wide, which reads by unsigned long
3. generic, which uses standard clang vector implemenations, if
available
4. arch, which uses an architecture-specific implemenation

(Reading the code carefully, you may note that a user can actually
specify any namespace they want, so we aren't technically limited to
those 4.)

We may also want to switch from command-line #defines as it is currently
done, to something more like
llvm-project/llvm/include/llvm/Config/llvm-config.h.cmake, and
#including the resulting file, which would move quite a bit of
complexity out of the command-line. But that's a future problem.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications