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

[Yao Zihong]

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]

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.

The first unrolled step (with LMUL=1) mainly targets very short strings
(0–32 B). The second unrolled step is for alignment, so that the main
loop can avoid .ff variants entirely. For longer strings, the loop
continues until the terminating zero is found, but still avoids extra
CSR overhead. I also experimented with making the m4_vector_loop exit
only when a zero was actually found, but that approach did not improve
overall throughput.

The number of conditional branches is indeed higher than in the simpler
loop, but the measured impact so far appears manageable on the tested
platforms, so this complexity currently seems justified.

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.

I’d welcome feedback on whether this direction seems reasonable before
wiring it into IFUNC.

Best,
Zihong