Re: [PATCH v2 0/1] riscv: add vectorized memset, memcpy and memmove

On Sat, 3 Jan 2026 at 16:22, Pincheng Wang
<[email protected]> wrote:
> Hi all,
>
> Happy new year!
>
> Just a gentle ping on this patch series. Please let me know if there are
> any remaining concerns that I can help address. Happy to update the
> series if needed. :)

Dear Pincheng,

I have some high-level questions from a purely user perspective.
Please do not consider this as a "review". :)

> On 2025/12/26 0:08, Pincheng Wang wrote:
> > This v2 patch adds RISC-V Vector (RVV) optimized implementations for
> > memset, memcpy and memmove.
> >
> > Changes since v1:
> > - Switch the conditional compilation macro from __riscv_v to __riscv_vector.
> > - Replaced '.option arch,+v' with '.option arch,+zve32x'.
What is the implication of this change? I'm a newbie to RVV, and
"Zve32x" looks like a subset implementation. Is it possible to compile
the standard library post-patch if a target usually blanket-enables
"+v"? ("rv64imafdcv")

> > - Removed an unnecessary unconditional jump instruction in memmove-asm.S
> > - In memcpy and memmove, when __riscv_misaligned_fast is not defined,
> >    the destination address is now aligned to SZREG to improve performance
> >    on systems with slow misaligned accesses.
> >
> > These implementations use the RVV extension with e8 element size and m8
> > LMUL, and are conditionally compiled only when __riscv_vector is
> > defined, ensuring compatibility with non-vector RISC-V systems.
Is the condition for this conditional compilation decided at the
moment of compiling 'newlib'? So, if someone wants to create a
distribution where it is possible to compile for both non-RVV and
RVV-capable target configurations, this essentially means having to
distribute two versions of the newlib binary archive? Am I right to
think that "pre-compiling" newlib with vectorised mem{cpy,move,set}
and linking it with a binary that is otherwise non-RVV, and execute
the whole image on a non-RVV platform would simply result in a
corrupted execution?

> > Benchmark results on Spacemit X60 (Muse-pi) and Canaan K230 show significant
> > improvements.
> >
> > memcpy: Up to 4.84x on Muse-pi and 4.66x on K230.
> > memset: Up to 4.31x on Muse-pi and 3.14x on K230.
> > memmove: Up to 2.87x on Muse-pi and 1.48x on K230.
> >
> > With newly added alignment handling, these improvements are consistent
> > across both aligned and misaligned memory acesses.