Re: riscv64 libc string function patch set -- how to proceed?

On 8/6/25 06:06, Robert Clausecker wrote:
> Greetings!
> 
> As part of last years GSoC, strajabot@ implemented [1] assembly
> variants of some of the libc string functions.  As we do not have
> support for RVV nor for fine-grained instruction set extension
> detection, it was decided to just use the basic instruction set
> with no extension.  So it's all SWAR techniques.
> 
> Back then we decided to do the same acceptance test I did for
> the AArch64 functions and the amd64 functions: build all ports
> with and without the patch set and see if anything changes.
> I started to do so in late 2024, but my build box kept crashing.
> Eventually I discovered that this crash was in fact a livelock
> in the OpenSBI firmware that would also occur on emulator [2],
> preventing any progress on the acceptance test.
> 
> These are the patches involved.  You can find them all in one
> branch on strajabot@'s github [3]:
> 
>     D47275 D46230 D46139 D46023 D46047 D45730 D45693
> 
> They pass our test suite and seem fine.  We have tried to hook
> them up to the glibc test suite, but that test suite is so
> annoying to work with that it is not really feasible to do so.
> It does not seem like the planned acceptance test can be
> completed at all in face of PR 284743, and given the lack of
> interest in getting this issue fixed, I don't see a possibility
> of getting the acceptance test completed.
> 
> How shall we proceed with these patches?
> 

Hi Robert,

I would like see this work integrated. Certainly it would be more
valuable in the tree than stuck in review.

Building a full/large suite of ports would be a comprehensive test, but
given the major blockers here I see no reason to insist on it.

Are you able to roughly quantify/estimate the risk? I.e. how much
coverage do we get from the FreeBSD test suite, and other tests you have
already exercised on these implementations? Would a self-hosted
buildworld add any value at this point?

The way I see it we have two options:
 1. Merge the changes now ahead of 15.0
 2. Merge them after stable/15 branches, keeping them only in main

Option 2 is more conservative, but the riscv user-base is so small that
we might benefit more from merging it now. Clearly, the platform still
has some major bugs/limitations in the base system, so I don't feel the
need to be precious about our release images.

I appreciate that any latent bugs in these primitives may be nasty to
debug/pinpoint in the future.

I am out-of-practice with RISC-V assembly, so I can't offer any real
review of the implementations. I will look over the changes and give my
rubber-stamp approval, but really I can only defer to your expertise here.

To summarize: I will look it over, but how we proceed with this project
is up to you.

Best,
Mitchell

> Yours,
> Robert Clausecker
> 
> [1]: https://wiki.freebsd.org/SummerOfCode2024Projects/PortAmd64SIMDLibcOptimizationsToRiscv64
> [2]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284743
> [3]: https://github.com/strajabot/freebsd-src/tree/exp-run
>