[all-commits] [llvm/llvm-project] ed7e66: Reland Refactor WIDE_READ to allow finer control o...

[Sterling-Augustine via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ed7e66a41d084ca442e6425a29dddfab1e647751
      https://github.com/llvm/llvm-project/commit/ed7e66a41d084ca442e6425a29dddfab1e647751
  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:
  -----------
  Reland Refactor WIDE_READ to allow finer control over high-performance function selection (#165613) (#170738)

[Previous commit had an incorrect default case when
FIND_FIRST_CHARACTER_WIDE_READ_IMPL was not specified in config.json.
This PR is identical to that one with one line fixed.]

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