RVISmith: Fuzzing RVV Intrinsics

• RVISmith is a compiler fuzzer for RVV intrinsics, generating well-defined C programs with diverse intrinsic invocation sequences.
• It employs randomized scheduling, vector-register allocation, and differential testing across compilers, achieving 11.5× higher intrinsic coverage and uncovering critical bugs.
• The system leverages RVV-specific parameters and an agnostic-state model to ensure semantic correctness and avoid undefined behaviors in SIMD intrinsics.

RVISmith is a compiler fuzzer for RVV intrinsics, that is, the built-in C/C++ functions used to program the RISC-V Vector Extension (RVV). It was introduced as a randomized system that generates well-defined C programs containing various invocation sequences of RVV intrinsics, with the explicit goals of achieving high intrinsic coverage, improving sequence variety, and operating without known undefined behaviors. Its programs are executed under a differential-testing regime spanning compilers, optimization levels, and equivalent schedules, and the reported evaluation shows 11.5 times higher intrinsic coverage than the prior RVV-intrinsic fuzzer and 13 previously unknown bugs across GCC, LLVM, and XuanTie, of which 10 are confirmed and another 3 are fixed by the compiler developers (He et al., 4 Jul 2025).

1. Name, domain, and scope

RVISmith refers to the system introduced in “RVISmith: Fuzzing Compilers for RVV Intrinsics” (He et al., 4 Jul 2025). In that work, the target domain is not retrieval, visualization, or radio interferometry, but compiler testing for SIMD intrinsics, specifically the RVV intrinsic interface exposed by modern RISC-V toolchains.

The name is distinct from several superficially similar terms in other literatures. The geo-multimedia retrieval paper on “Efficient Region of Visual Interests Search for Geo-multimedia Data” does not define a system named RVISmith; its exact terminology is Region of Visual Interests Query (RoVIQ), region of visual interests search or RoVI Search, and quadtree based inverted visual index (QIV) (Zhang et al., 2018). The Antarctic cryosphere dashboard paper uses the name RIS-Vis, not RVISmith (Chakravarthy et al., 2024). The radio-interferometric modeling paper uses the name vis-r, and explicitly states that there is no mention of “RVISmith” in that software context (Kennedy, 24 Feb 2025).

Within compiler research, RVISmith is positioned as the first academic system focused specifically on fuzzing compilers for SIMD intrinsics, and more narrowly as a dedicated fuzzer for RVV intrinsics (He et al., 4 Jul 2025).

2. Technical setting and design objectives

The immediate motivation for RVISmith is the role of SIMD intrinsics as the programmer-facing interface between high-level languages and vector instructions. The paper distinguishes three ways to access SIMD: assembly, compiler auto-vectorization, and intrinsics. Assembly is described as tedious and nonportable, whereas auto-vectorization is often limited because the compiler lacks enough information at compile time; accordingly, performance-critical software often relies on intrinsics (He et al., 4 Jul 2025).

The RVV setting introduces a type system and execution model that materially shape the fuzzer’s design. The paper highlights VLEN, SEW, and LMUL as central RVV parameters. It also notes that bool vector types encode the ratio SEW / LMUL rather than literal storage width, and that intrinsic names combine a prefix, an RVV mnemonic, vector-type information, and an optional policy suffix. Semantically, RVV also contains masked-off elements and tail elements that may be agnostic, meaning their value is unknown. This matters directly for fuzzing, because a syntactically valid program can still be semantically unsuitable as a differential-testing oracle if it reads agnostic values (He et al., 4 Jul 2025).

RVISmith is therefore organized around three explicit objectives: high intrinsic coverage, improved sequence variety, and generation without known undefined behavior. These are tied to the ratified RVV intrinsic specification version 1.0, from which the implementation parses intrinsic definitions and semantic metadata (He et al., 4 Jul 2025).

The strip-mining model of RVV is also fundamental. The paper gives the formulas

$$vsetvl(avl) = \min(avl, vlmax), \qquad vsetvlmax() = vlmax$$

and

$vlmax = VLEN \times LMUL \div SEW.$

These relations are not merely background; they govern whether an intrinsic sequence can be embedded correctly into a vector-length-agnostic loop (He et al., 4 Jul 2025).

3. Generation pipeline and sequence construction

RVISmith’s workflow consists of four code-generation stages followed by differential testing: preprocessing and sequence selection, data-flow construction, intrinsic scheduling, and final code generation (He et al., 4 Jul 2025).

In preprocessing, the system parses the RVV intrinsic specification and classifies intrinsics into four categories: load intrinsics, store intrinsics, ignored intrinsics, and operation intrinsics. The sequence-selection stage is governed by ratio-aligned constraints. The paper defines a ratio-aligned intrinsic as one whose vector types share the same SEW / LMUL ratio, and a ratio-aligned intrinsic sequence as one in which the compatible intrinsics all share a common ratio while non-ratio-aligned intrinsics still include at least one vector type with that same ratio. This restriction preserves correct strip-mining behavior; without it, a loop may process incompatible vector widths under a single vl, causing some elements to be skipped or processed more than once (He et al., 4 Jul 2025).

After operation-sequence selection, RVISmith performs randomized vector-register allocation. It maintains a VregTable keyed by vector type and chooses, for each vector parameter or return value, whether to allocate a new variable or reuse an existing one. The stated purpose is to generate all four dependency scenarios: read-read, read-write, write-read, and write-write. Newly allocated parameter variables receive a _mem suffix, marking them as values that must later be produced by a load intrinsic during scheduling (He et al., 4 Jul 2025).

The next stage inserts loads and stores while preserving legality. For each operation intrinsic $I[i]$, RVISmith constructs prefix sets $P[i]$ and suffix sets $S[i]$ and then applies one of three schedulers. All-in scheduling places all prefixes first, then all operations, then all suffixes. Unit scheduling wraps each operation with its own prefixes and suffixes. Random scheduling inserts operations, prefixes, and suffixes at random legal positions while preserving precedence constraints. The paper treats programs produced from the same operation sequence but with different schedulers as equivalent programs, and this equivalence becomes a testing oracle in its own right (He et al., 4 Jul 2025).

Final code generation adds global memory buffers, random initialization, strip-mining loop scaffolding, and print statements. Scalar initialization is specified precisely: bool values in [0, 1], signed integers in $[ -2^{n-1}, 2^{n-1}-1 ]$, unsigned integers in $[0, 2^n-1]$, and floating-point values generated from random unsigned bit patterns and normalized so that NaNs are replaced with zero. The emitted program is therefore not a fragment but a complete C test case suitable for compilation and execution (He et al., 4 Jul 2025).

4. Well-definedness, agnostic-state control, and oracle design

A major contribution of RVISmith is its treatment of RVV-specific undefined behavior. The paper explicitly argues that conventional UB detectors such as UBSan are insufficient in this domain because RVV intrinsics introduce semantics around agnostic values, mask/tail policy, and vectorized memory accesses that are not captured by ordinary C-level UB reasoning (He et al., 4 Jul 2025).

The most important mechanism is the agnostic-state model. RVISmith tracks which elements are active and whether they remain non-agnostic through the intrinsic sequence. The rule given in the paper is concise: an element is non-agnostic iff this element is active and all source elements are non-agnostic. Only such elements are printed and compared during differential testing. This prevents false positives arising from correct but implementation-dependent bits in masked-off or tail positions (He et al., 4 Jul 2025).

The generator also distinguishes classes of intrinsically problematic operations. For conditionally undefined intrinsics—including vrgather, vslide, vcompress, vcpop, vfirst, vmsif, vmsbf, vmsof, and viota—RVISmith uses rule-based generation of “absolutely correct” values so that outputs are well-defined. For always-undefined intrinsics—including vundefined intrinsics, the extended portion produced by vlmul_ext intrinsics, and vreinterpret intrinsics—the returned vector register is removed from the active variable table so that later operations do not consume contaminated data (He et al., 4 Jul 2025).

Array safety is handled conservatively. Every vl argument comes from a vsetvl intrinsic, indices for indexed load/store intrinsics are derived from vid intrinsics, and additional fine-grained adjustments are applied to keep accesses in bounds. The paper links this to a broader correctness-security gap, noting that compilers do not perform bounds checks for intrinsic-level accesses and citing an out-of-bounds write issue found during development (He et al., 4 Jul 2025).

Oracle construction also depends on memory separation. To ensure that programs produced under different scheduling algorithms remain semantically equivalent, RVISmith separates the memory used for loads from the memory used for stores. This prevents a store in one legal schedule from perturbing a later load that, under another legal schedule, was intended to read the original input state (He et al., 4 Jul 2025).

5. Differential testing protocol, metrics, and empirical results

RVISmith applies three differential-testing strategies: cross-compiler, cross-optimization, and equivalent-program testing. A discrepancy is defined as a compiler crash, a runtime crash, or a different printed execution result. The tested compilers are GCC version 14+, LLVM/Clang version 17+, and XuanTie, and the generated RISC-V ELF binaries are executed under QEMU 9.1.0. The reported flags include -march=rv64gcv_zvfh, -mabi=lp64d, -Wno-psabi, and -static, with optimization levels -O0, -O1, -O2, -O3, and -Os (He et al., 4 Jul 2025).

The paper defines an approximate intrinsic-coverage metric: $$Intrinsic \ coverage = \frac{ \sum_{i=0}^{n} \min(count_i, weight_i) }{ \sum_{i=0}^{n} weight_i }.$$ Here, $count_i$ is the number of appearances of the $i$-th intrinsic name in generated code, and $vlmax = VLEN \times LMUL \div SEW.$0 is the number of times that intrinsic name appears in the intrinsic-definition list. This metric is deliberately name-based because overloaded intrinsics are hard to distinguish statically without a more complex analyzer (He et al., 4 Jul 2025).

The main quantitative findings are compactly summarized below.

Aspect	RVISmith result	Comparison or note
Total intrinsic coverage at $vlmax = VLEN \times LMUL \div SEW.$1 seeds	74.08%	RIF: 6.39%
Explicit intrinsics at $vlmax = VLEN \times LMUL \div SEW.$2 seeds	78.69%	RIF: 15.18%
Implicit intrinsics at $vlmax = VLEN \times LMUL \div SEW.$3 seeds	78.65%	RIF: 0.00%
Previously unknown bugs	13	10 confirmed; 3 fixed
GCC code coverage	26.88% function, 23.77% line, 14.90% branch	10,000 programs
LLVM code coverage	21.51% function, 14.46% line, 13.64% branch	10,000 programs
Added line coverage over Csmith+RIF	GCC: 124,948; LLVM: 91,987	10,000 RVISmith programs
Generation cost in profiling	0.021% of CPU time; 0.022% of real time	Compilation and QEMU dominate

The coverage result underlies the paper’s headline claim of 11.5× higher intrinsic coverage than RIF. The study also reports that RVISmith reaches over 90% coverage on most intrinsic functional groups except segment load/store intrinsics, which are described as both extremely numerous and relatively unlikely to be inserted by the current random generator (He et al., 4 Jul 2025).

The bug-finding results are similarly specific. RVISmith found 13 previously unknown bugs across the three compilers: 3 compiler crashes, 5 runtime crashes, and 5 wrong results. By compiler, the paper reports GCC: 7, LLVM: 1, and XuanTie: 5. It further estimates that more than 20,000 RVV intrinsics are affected by the discovered bugs, including 4416 fixed-point intrinsics with vxrm, 7376 masked widening intrinsics, and 9020 floating-point intrinsics with frm (He et al., 4 Jul 2025).

Several concrete bug classes illustrate the failure modes. One GCC bug causes half the data are lost because pointer updates use vlenb configured incorrectly under vsetvli. Another GCC bug mishandles frm, so an intrinsic that should use default round-to-nearest instead inherits the previous explicit round-down mode. A GCC LMUL-extension intrinsic triggers an internal compiler error via null-pointer dereference. An LLVM case involving __riscv_vlse32_v_f32m1, __riscv_vfsqrt_v_f32m1_rm, and __riscv_vfredosum_vs_f32m1_f32m1 produces an illegal fsrmi instruction and a runtime crash. The paper identifies CSR state mishandling—especially around frm, vxrm, and vector-configuration state—as a recurring theme (He et al., 4 Jul 2025).

6. Significance, limitations, and future directions

RVISmith’s significance lies in its specialization. General compiler fuzzers such as Csmith do not generate SIMD intrinsics, and the prior RVV-specific tool RIF supports less than 7% of intrinsics and generates only a single operation per strip-mining loop. RVISmith instead supports almost all RVV intrinsics according to the ratified specification, generates complex combinations of RVV intrinsics in strip-mining loops, and combines semantic constraints, register-allocation diversity, multiple schedulers, and UB avoidance into a single end-to-end testing workflow (He et al., 4 Jul 2025).

The paper is also explicit about its limits. Sequence generation is purely random within its constraints and is not coverage-guided. The current generator focuses on a single strip-mining loop, leaving more complex control flow and broader program structure outside scope. For conditionally undefined intrinsics and indexed load/store intrinsics, it relies on rule-based “absolutely correct” data generation, which reduces false positives but also leaves some valid behaviors unexplored. The authors additionally note blind spots involving emulator correctness, intentionally UB-triggering programs, and scenarios outside the current generation coverage (He et al., 4 Jul 2025).

The stated future directions are correspondingly concrete: improve RVV program generation, adapt the approach to other SIMD-intrinsic ecosystems such as x86 SSE/AVX and ARM Neon, and use similar ideas to fuzz emulators and hardware for SIMD instructions. Within the compiler-testing literature, RVISmith therefore stands as a domain-specific randomized fuzzer whose central contribution is not just broader generation, but the generation of well-defined, semantically meaningful, diverse sequences of RVV intrinsic calls that can expose miscompilations, crashes, and CSR-state errors that general-purpose fuzzers and earlier RVV tools largely miss (He et al., 4 Jul 2025).