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

[Andrew Waterman]

On Mon, Sep 22, 2025 at 5:44 AM Jeff Law <jlaw@ventanamicro.com> wrote:
>
> On 9/22/25 5:40 AM, Yao Zihong wrote:
>
> >> FWIW, reading vl should not be a slow operation on most
> >> implementations, even in the presence of fault-only-first loads.
> >> Performant implementations will speculate that fault-only-first loads
> >> don't fault, so that the CSR read doesn't need to wait for the
> >> fault-only-first load to execute.  (Of course, such implementations
> >> need to flush the pipeline following a misspeculation, but that will
> >> happen whether or not software reads vl--it is a sunk cost.)  Going
> >> out of one's way to avoid reading vl is probably an over-optimization
> >> for a particular microarchitecture's quirks.
> >
> > That makes sense – if avoiding vl reads is really only relevant for a few
> > specific implementations, then it might be seen as an over-optimization.
> > In that case, would it make sense to agree on a small set of representative
> > RVV platforms (e.g. covering low-end, mid-range, and high-end) to guide such
> > decisions? That might help provide common reference points and make future
> > RVV optimization discussions smoother. For example, would something like
> > SG2044 be considered representative on the high-end side?
>
> In general things like fast read access to VL, VLENB, fast write access
> to VXRM are all things I would expect to be common in the near future.
> The quirks of current designs are just that -- performance quirks of
> early designs and not necessarily a good indicator of what we should
> code for going forward.

I'd add that I would expect them to be fast in all classes of
implementation going forward.  Optimizing these in low-end cores is
not costly in terms of area; it just takes a bit more engineering
effort.

>
> Jeff