[RFC] riscv: RVV-based vector math support in newlib

[Pincheng Wang]

Hi all,

I am considering work on RVV-based vector math support for RISC-V in 
newlib and would like to hear your views before I proceed.

The idea is to add optional RVV implementations for a small set of hot 
libm functions (for example, sin/cos/exp/log in float and double), while 
keeping the existing scalar APIs and ABI unchanged. The long-term goal 
would be similar in spirit to glibc’s libmvec: with appropriate 
toolchain support, the compiler could select vector math routines when 
it detects profitable patterns (e.g. repetitive calls to the same 
function), so applications can benefit without source changes. This 
would require some changes and coordination on the toolchain side (e.g. 
in GCC/Clang) in addition to any work in newlib.

In parallel, RISC-V currently does not have a vector function ABI 
comparable to what exists on x86_64 and aarch64. My colleagues and I are 
also looking into this topic; if the community has views on how such an 
ABI should look, or how it should interact with newlib, we would be very 
happy to discuss and help move it forward.

At a high level, I see the following trade-offs:
Pros:
- Higher math throughput on RVV-capable RISC-V edge/embedded systems for 
workloads with many transcendental function calls or batched data.
- A clear path for future compiler support to make use of vector math 
automatically when it is profitable.
Cons:
- Extra code size and build complexity in newlib, even if the support is 
kept strictly optional and only enabled for RVV targets.
- Additional testing and maintenance burden for RVV-specific math code.
- Real performance benefits depend on corresponding toolchain work to 
emit calls to these routines.

Before I start any implementation, I would appreciate your feedback on 
whether such a contribution would be welcome in newlib, provided it 
remains optional, well-scoped, and does not affect existing scalar 
behavior. If this is considered out of scope for newlib (for size, 
complexity, or other reasons), it would be very helpful to know that up 
front.

Best regards,
Pincheng Wang