[PATCH v1 2/3] riscv: Add RVV implementation __strcpy_vector

[Jeff Law]

On 9/18/25 23:00, Yao Zihong wrote:
> Hi Jeff,
> 
> Thanks for the feedback. I believe you are referring to:
> 
> https://patchwork.sourceware.org/project/glibc/patch/20230504074851.38763-4-hau.hsu@sifive.com/
> 
> That simpler version was tested before. The following results were observed
> on the test platforms (measured using the same method as described in the
> cover letter):
> 
> - Platform: K230
>      Overall:   [1.571778, 1.572332]
>      0–8B:      [0.777493, 0.795009]
>      8–16B:     [0.696411, 0.709073]
>      16–32B:    [0.853012, 0.864697]
>      32–64B:    [1.005175, 1.014216]
>      64–128B:   [1.240943, 1.246175]
>      128–256B:  [1.471738, 1.474692]
>      256–512B:  [1.546868, 1.547473]
>      512–1024B: [1.728939, 1.730251]
> 
> - Platform: SpacemiT M1
>      Overall:   [0.785986, 0.786187]
>      0–8B:      [0.733097, 0.739368]
>      8–16B:     [0.545642, 0.549409]
>      16–32B:    [0.541668, 0.544200]
>      32–64B:    [0.616717, 0.618165]
>      64–128B:   [0.702261, 0.703109]
>      128–256B:  [0.763475, 0.763887]
>      256–512B:  [0.795325, 0.795567]
>      512–1024B: [0.942046, 0.943050]
Thanks.  Good to know.


> 
> In previous measurements, reading the vl CSR appears to add noticeable
> latency, and on some micro-architectures vle8ff.v was slightly slower
> than vle8.v. The primary goal of current implementation is to minimize
> CSR reads and ff variants whenever possible.
So that seems more uarch dependent than we're likely going to want in a 
generic RVV implementation.  Both in tems of avoiding VL reads and any 
penalty for FoF loads.


> 
> Of course, these two platforms may not represent the diversity of RISC-V
> implementations — the ecosystem is quite heterogeneous. I’d be happy to
> collect and share additional benchmark results from more platforms if
> others have access to them.
Absolutely correct.  In fact, I would argue that what we want to do for 
these early RVV uarchs is highly likely very different than what we'll 
want to do with future generations on both the high and low end designs.

Or to put it another way, we should make the first implementations at 
these routines fairly generic RVV.  If we then find (as I expect we 
will) there are material gains to be made for specific uarchs, then we 
can expand the hwprobe interface to provide additional information to 
allow us to select those uarch specific implementations.

Jeff