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

[Andrew Waterman]

On Fri, Sep 19, 2025 at 9:46 AM Jeff Law <jlaw@ventanamicro.com> wrote:
>
> On 9/19/25 10:26, Sergei Lewis wrote:
> >     In previous measurements, reading the vl CSR appears to add noticeable
> >     latency
> >
> >
> > Why do we ever need to read the vl CSR at all? Sure, vle8ff adjusts it
> > if there is a fault. However, consider: strcpy() behaviour is undefined
> > if the buffer is not null terminated, so no particular behaviour is
> > required in that situation and we are free to choose whatever is
> > cheapest; and if it /is/ null terminated, the null byte will be
> > available to subsequent operations as normal regardless of what else
> > vle8ff does or does not do, and the subsequent comparison and store
> > operations will behave correctly without us needing to explicitly
> > interact with VL.
> My understanding is the VL can be adjusted even when there is _not_ a
> fault.  For example, to simplify the hardware design a page crossing but
> not faulting FoF load can stop the load at the page boundary, updating
> VL appropriately and the next load will start on the new page boundary.

Your understanding is correct, but FWIW, I've yet to hear of an
implementation actually doing this.

>
> We considered (in a different context) if we could just say those
> scenarios should happen rarely and let subsequent iterations just use
> the lower VL.  I don't think we actually ever bothered to benchmark that
> behavior.

This will usually work fine, but will exhibit pathologically poor
performance when a long string happens to cross a page boundary and
the next page is paged out.  In most cases, you can reasonably argue
that the performance doesn't matter in this case because the cost of
servicing the page fault--even a soft page fault--is greater than the
overhead of processing the string at reduced VL.  The scary, but
presumably rare, case is an extremely long string where just one page
somewhere in the middle is paged out; in that case, the overhead of
reduced VL will dominate.  Still, it seems prudent to avoid a glass
jaw.

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.

>
>
> Jeff