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

Hi Pincheng,

I generally think this is a good thing to do.
Taking a cautious approach of not implementing too many functions, but only what is not reasonably taken care off by auto-vectorization.
The math functions you mentioned are a great starting point for that.

Christian


> -----Original Message-----
> From: Pincheng Wang <[email protected]>
> Sent: Thursday, 27 November 2025 07:03
> To: [email protected]
> Subject: [RFC] riscv: RVV-based vector math support in newlib
> 
> [You don't often get email from [email protected]. Learn why this
> is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> 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