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

[Jeff Law]

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.

Jeff