[PATCH v3 0/3] newlib: riscv: Add and optimize memchr() and memrchr() functions

[Kito Cheng]

v3 is LGTM, thanks :)

On Mon, May 12, 2025 at 10:53 PM Eric Salem <ericsalem@gmail.com> wrote:
>
> The RISC-V port currently does not have its own implementations of
> memchr() and memrchr(). Instead it uses the stock version that's common
> to any port that omits its own implementations.
>
> This patch series adds port-specific implementations of both. It
> improves upon the algorithm that's currently used, and also uses RISC-V
> extensions when available.
>
> The proposed implementations were benchmarked on a Raspberry Pi Pico 2.
> A 2 KB buffer was was used, and an offset into the buffer ranging from
> 0-2047 was set where the matching byte would be found.
>
> To ensure that the benchmarking is objective as possible, a range of
> addresses with various alignments were tested so neither algorithm had
> an advantage. Addresses divided by eight with a remainder of 0-7 were
> used for the benchmark. For example:
>
> 0x20002a80
> 0x20003289
> 0x20003a92
> 0x2000429b
> 0x20004aa4
> 0x200052b5
> 0x20005ac6
> 0x200062d7
>
> In all cases except two, the proposed memchr() was faster than the
> existing. For those two cases they were tied, and both had an offset of
> zero and unaligned addresses for the buffer. A total of 16,384 cases
> were tested.
>
> The existing memrchr() implementation currently does misaligned
> accesses, and so could not be benchmarked properly on the Pico 2. But
> considering that every word load is misaligned, the proposed
> implementation will be faster since it does aligned accesses only. The
> algorithm was also improved upon in the same fashion as memchr(), along
> with using RISC-V extensions when available.
>
> The final commit in this series is for regenerating a configuration
> file. As described elsewhere,[1][2] this file doesn't need to be part
> of the series. It's included only to aid in testing the changes without
> having to manually regenerate the file.
>
> [1] https://sourceware.org/newlib/faq.html#q8
> [2] https://sourceware.org/pipermail/newlib/2025/021500.html
>
> Changes in v3:
> - Don't use inline assembly for Zilsd since compilers will eventually
>   support it using only C
> - Link to v2: https://sourceware.org/pipermail/newlib/2025/021742.html
>
> Changes in v2:
> - Renamed macro used for register size
> - Link to v1: https://sourceware.org/pipermail/newlib/2025/021738.html
>
> Eric Salem (3):
>   newlib: riscv: Add memchr() and memrchr() implementations
>   newlib: riscv: Optimize memchr() and memrchr()
>   newlib: Regenerate configuration file
>
>  newlib/Makefile.in                     |  41 +++++-
>  newlib/libc/machine/riscv/Makefile.inc |   2 +-
>  newlib/libc/machine/riscv/memchr.c     | 152 ++++++++++++++++++++++
>  newlib/libc/machine/riscv/memrchr.c    | 172 +++++++++++++++++++++++++
>  newlib/libc/machine/riscv/rv_string.h  |  45 ++++++-
>  newlib/libc/machine/riscv/xlenint.h    |   7 +
>  6 files changed, 410 insertions(+), 9 deletions(-)
>  create mode 100644 newlib/libc/machine/riscv/memchr.c
>  create mode 100644 newlib/libc/machine/riscv/memrchr.c
>
> --
> 2.49.0
>