Added RISC-V Vector Support for selected functions

[grigohas]

Description

This pull request introduces RISC-V Vector (RVV 1.0) support for selected functions, extending the project with vectorized implementations inspired by my research. The goal is to leverage the RVV extension in order to improve performance in computationally intensive routines. The changes are based on my findings, which explored the acceleration of homomorphic encryption primitives on RISC-V processors using the Vector Extension. It is focused on BFV, the general techniques of instruction fusion and vectorization proved effective in accelerating arithmetic kernels.

Changes

• Added RVV intrinsics for selected functions.
• Introduced vectorized code paths while preserving scalar fallbacks for non-RVV targets.
• Optimized arithmetic routines to reduce instruction overhead and exploit data parallelism.
• Enable compiler optimizations (-O3)

Results

According to experiments in a Gem5 simulated RISC-V system, vectorization can provide up to 13× theoretical speedup, though practical results vary depending on workload. This PR lays the groundwork for further improvements by integrating RVV support directly into the codebase.

The RISC-V Vector intrinsics support is added for the following functions

divide_uint128_uint64_inplace_generic
multiply_poly_scalar_coeffmod
dyadic_product_coeffmod
dot_product_mod
transform_to_rev
transform_from_rev

[Compilation]

Ubuntu: 24.04
Build environment:

• Target: riscv64-linux-gnu (glibc)
• GCC version: 13.3.0

To compile the project with RISC-V RVV extension support enabled, make sure to enable the appropriate target flags during the build stage.

Directly on RISC-V cpu

cmake -S . -B build -DRISCVRVV=ON

For Cross Compilation

cmake -S . -B build -DRISCVRVV=ON -DCMAKE_C_COMPILER=riscv64-linux-gnu-gcc -DCMAKE_CXX_COMPILER=riscv64-linux-gnu-g++

Notes

• Code has been tested on an RVV-enabled RISC-V simulator and verified against baseline results.
• Future work could extend RVV coverage to additional kernels and explore deeper pipeline optimizations.

[grigohas]

@microsoft-github-policy-service agree