---
title: 'RVISmith: Fuzzing RVV Intrinsics'
url: https://www.emergentmind.com/topics/rvismith
type: topic
---

# RVISmith: Fuzzing RVV 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** [2507.03773].

## 1. Name, domain, and scope

RVISmith refers to the system introduced in **“RVISmith: Fuzzing Compilers for RVV Intrinsics”** [2507.03773]. 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)** [1808.09610]. The Antarctic cryosphere dashboard paper uses the name **RIS-Vis**, not RVISmith [2408.12106]. The radio-interferometric modeling paper uses the name **vis-r**, and explicitly states that there is no mention of “RVISmith” in that software context [2502.17619].

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** [2507.03773].

## 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 [2507.03773].

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 [2507.03773].

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 [2507.03773].

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 [2507.03773].

## 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** [2507.03773].

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 [2507.03773].

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 [2507.03773].

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 [2507.03773].

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 [2507.03773].

## 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 [2507.03773].

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 [2507.03773].

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 [2507.03773].

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 [2507.03773].

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 [2507.03773].

## 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` [2507.03773].

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 \(weight_i\) 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 [2507.03773].

The main quantitative findings are compactly summarized below.

| Aspect | RVISmith result | Comparison or note |
|---|---:|---|
| Total intrinsic coverage at \(10^5\) seeds | 74.08% | RIF: 6.39% |
| Explicit intrinsics at \(10^5\) seeds | 78.69% | RIF: 15.18% |
| Implicit intrinsics at \(10^5\) 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 [2507.03773].

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`** [2507.03773].

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 [2507.03773].

## 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 [2507.03773].

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 [2507.03773].

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 [2507.03773].

Source: https://www.emergentmind.com/topics/rvismith