Task Introduction

This verification task requires participants to complete a vector computing compilation verification workflow based on the RISC-V “V” extension. Through end-to-end practical testing, you will gain an in-depth understanding of the complete compilation chain from high-level operators to RISC-V assembly and its functional verification methods.

The RISC-V “V” (Vector) extension aims to significantly improve processor performance in scientific computing, machine learning, multimedia processing and other fields through Single Instruction Multiple Data (SIMD) parallel processing. The core idea of vector processors is to use one instruction to perform the same operation on all elements in a group of data (a “vector”). By introducing a set of specialized vector registers and rich vector instructions, vector processors can efficiently parallel-process large amounts of data.

The core of this verification is to build a complete Triton operator → MLIR → LLVM → RISC-V assembly → Spike simulation verification loop. Participants will use high-performance operators written in Triton, which undergo multi-layer intermediate representation transformations through the MLIR compilation framework, and are eventually lowered to LLVM IR to generate RISC-V assembly code containing vector instructions. By writing C test programs in the Spike simulator, setting input data and executing result comparison, you will verify the functional correctness of the compiled vector kernel.

This task will provide a complete compilation toolchain and necessary linking files, including the operator kernel’s LLVM IR file, RISC-V assembly file, and cross-compilation environment.

Welcome everyone to participate. Please fill out the registration questionnaire and join the discussion groups:

• Wanzhong Yixin Verification Exchange Group (QQ): 600480230
• Vector Computing Verification Exchange Group (QQ): 946483102

RISC-V Vector Computing Verification Workflow Document

1 Verification Targets

1.1 Introduction to RISC-V “V” Extension

The RISC-V “V” (Vector) extension aims to significantly improve processor performance in scientific computing, machine learning, multimedia processing and other fields through Single Instruction Multiple Data (SIMD) parallel processing. The core idea of vector processors is to use one instruction to perform the same operation on all elements in a group of data (a “vector”). By introducing a set of specialized vector registers and rich vector instructions, vector processors can efficiently parallel-process large amounts of data, making them especially suitable for high-performance computing, artificial intelligence, signal processing and other data-intensive application scenarios.

1.2 Introduction to Spike Simulator

Spike is a functional simulator developed by RISC-V official, commonly used as the “golden reference model” for the RISC-V software stack. It can simulate various RISC-V architecture variants including RV32 and RV64, and supports multiple standard extensions including the “V” vector extension (requires compilation-time enablement). Spike can run complete operating systems (such as Linux) or bare-metal programs, providing developers with an ideal environment for debugging, verification and teaching. Due to its open-source, lightweight and standardized behavior, Spike is widely used in RISC-V ecosystem development and education scenarios, making it an important tool for learning and testing RISC-V instructions (including vector instructions).

2 Test Functions and Task Requirements

You will participate in an end-to-end RISC-V vector computing verification workflow. Specifically, a high-performance operator (kernel) written in Triton will first undergo multi-layer Intermediate Representation (IR) transformations through the MLIR compilation framework, and finally be lowered to LLVM Dialect, generating standard LLVM IR (.ll file). When the compilation target enables RISC-V’s “V” vector extension, the LLVM backend will further compile this IR into RISC-V assembly code (.s file) containing vector instructions.

To verify the functional correctness of the vector kernel generated by this compilation chain, you need to write a C language test program in the Spike simulator environment: this program should be able to call and execute the above-generated assembly kernel, set reasonable input data, calling conventions and result comparison mechanisms, and confirm that its output matches the expected behavior. This task not only requires you to understand the basic usage of RISC-V vector extension, but also to master how to build a complete test environment in Spike, thereby completing the verification loop from high-level operators to low-level hardware simulation.

2.1 Test Workflow 1: Provide Environment and Process Description

RISC-V Cross-Compilation Toolchain

This toolchain is used to compile code for the RISC-V target platform on a host machine (such as x86 Linux or macOS). In this task, you need to use it to process two source files separately, and finally link them to generate an executable file that can run in the simulator (note: all subsequent workflows use the add operator as an example, please pay attention to naming conventions):

• Compile the provided operator kernel’s .s assembly file into kernel.o (if add.s is provided, compile and name it add.o);
• Compile your own C test main program (named test_add.c) into a .o file (named test_add.o);
• Finally, use the linker of the same toolchain to link these two .o files with the four provided files into a complete ELF executable file (named test_add.elf).

Required linking files:

• add.o
• test_add.o
• crt.o
• syscalls.o
• mlir_memrefcopy_spike.o
• test_compact.ld

Spike RISC-V Simulator

You will load the above-generated test_add.elf file as input into Spike for execution. Spike will execute the instructions (including vector instructions) one by one and output the program’s running results (such as print information, return values, etc.). By comparing the actual output with expected results, you can determine whether the kernel generated by Triton’s MLIR → LLVM → RISC-V assembly compilation chain is functionally correct.

2.2 Test Workflow 2: Provide File Description

Operator Kernel’s LLVM IR File (add.ll)

This file is the LLVM Intermediate Representation (IR) generated by the Triton operator through the MLIR compilation workflow. It describes the complete computational logic, control flow structure and function signature of the operator in a readable text form. By reading this file, you can clarify the following key information:

• The operator function’s name and parameter list (including parameter types, quantity and order);
• The semantic role of each parameter in the computation (for example: input tensor pointer, output buffer, dimension size, stride, etc.);
• The core operational logic inside the operator (such as loops, memory access, vector operations, etc.). This information is crucial for writing correct C test code—you need to construct input data that conforms to the calling convention based on this, and design expected outputs for result comparison, thereby verifying the kernel’s functional correctness.

Operator Kernel’s RISC-V Assembly File (add.s)

This file is the RISC-V assembly code further compiled by the LLVM backend from the above .ll file with the RISC-V “V” vector extension enabled. It contains the actual instruction sequence that will be executed on the target hardware (or simulator), which may include vector instructions such as vsetvli, vle32.v, vadd.vv.

Your task is to use the RISC-V cross-compilation toolchain (riscv64-unknown-elf-gcc) to compile this .s file into a relocatable object file (.o), then link it with your written C test main program to generate a complete executable file that can run in the Spike simulator. Through this method, you can actually run and verify whether the vectorized kernel’s behavior under the RISC-V architecture matches expectations.

Four Required Compilation Files

• crt.o
• syscalls.o
• mlir_memrefcopy_spike.o
• test_compact.ld

As required compilation files, they need to be compiled and linked together with add.o and test_add.o when generating test_add.elf. For specific reference, please refer to the workflow example documentation.

3 Acceptance Requirements

To comprehensively verify the functional correctness of the operator kernel, the test code needs to cover various typical and boundary input cases, and clearly reflect the kernel’s output behavior under different scenarios. We do not require exhaustive coverage of all combinations, but we expect the tests to demonstrate understanding of the kernel’s core logic, including responses to key parameter changes (such as vector length, data type, memory layout, etc.). All tests should include comparison with theoretically expected results, and display verification conclusions through readable output. As stated in the reference design, as long as the tests systematically reflect the basic correctness requirement of “results are consistent with the reference model” and demonstrate consideration of different running scenarios, they are considered to meet the acceptance criteria.

The following images all use the add operator as an example. Please replace the operator name according to your specific situation, and package all submitted files named Name_OperatorName.zip (xxx_add.zip).