Skip to content

test_rv: functional tester

Simon Moll edited this page Aug 9, 2018 · 3 revisions

RV integrated test suite

test_rv is a functional tester for RV based on rvTool the command line interface to RV. A test case for test_rv requires three things:

  • a test case (suite/*-[wfv|loop].[c|cpp])
  • a configuration line
  • a test launcher

test_rv.py will take the test case file, vectorize it with rvTool, and link it against a matching test launcher. In order to run test_rv, execute ./test_rv.py in the test/ folder. test_rv optionally accepts file patterns to c/cpp system tests on the command line.

Anatomy of a test case

Test case files have the structure suite/*-[wfv|loop].[c|cpp] and always export a function foo that contains the functional test. The suffix -wfv or -loop indicates whether this is a whole-function or outer-loop vectorization test. The first line of the test case file is the configuration line, which specifies the options that should be passed to rvTool and which launcher this test should be linked against to run it.

Test flow

Whole-function vectorization

In whole-function vectorization a scalar function is vectorized into a SIMD function declaration. In the test_rv setting this always means that the scalar function foo is vectorized into a declaration foo_SIMD. rvTool will automatically generate a canonical foo_SIMD declaration based on the provided vector shapes of the function's arguments. These shapes and the vectorization width are specified in the test case configuration line (see below). Test launchers for whole-function vectorization have to call both functions foo and foo_SIMD to check whether the foo_SIMD works as intended.

Outer-loop vectorization

Test launchers for outer-loop vectorization only call the function foo inf the test case. The test launchers output a hash code to std::cerr. A test passes in test_rv, if the launcher prints the same hash output for the scalar foo and foo with the first outer-loop vectorized (vectorization width is specified in the configuration line).

Test file configuration line

test_rv will parse the first line in the test case files. This line encodes how the test shall be vectorized and which test launcher it should be linked against. The line is always structured as a list of key-value pairs. The key refers to a specific option name. The value has to be written without any in-between spaces. // A: <value>, B: <value>

Common options

  • // LaunchCode: <launchCode> Identifies the launcher module that has to be linked against this test to actually run it. All launchers are in the folder "rv/test/launchers". loopverify_.cpp (verify_.cpp) will be used for in OuterLoop (WFV mode). There are also profiling launchers when running test_rv in profiling mode.

  • // Width: <Width> The vectorization factor used to vectorize this function (outer loop).

WFV options

  • // InputShape: <SIMD Shape Signature> The SIMD Shape Signature is a list of vector shapes sepearted by the character _. Every shape in the list defines the kind of shape the corresponding test function argument (the first, the second, ..) will have once the test function (foo) is vectorized. We explain the syntax of shapes below. It the test function returns a value, its shape can be defined by appending r<Shape> to the signature.

For example, U_TrU refers to a test function that receives a uniform input as its first argument, a varying argument as its second argument and returns a uniform value again. rvTool will automatically create a SIMD declaration from the scalar function type of the test function and its SIMD shape signature.

Vector shape encoding

rvTool implements a simple syntax to encode Vector Shapes. Shapes consist of a base shape specifier, optionally followed by an alignment specifier.

Base shape specifier

  • U : uniform
  • C : contiguous
  • T : varying
  • S<n>: the value has an affine stride of (single digit). For example, "S1" is equivalent to "C". "S0" is equivalent to "U".

Alignment specifier

a<n> indicates that the alignment of the shape is n.

For example, the alignment specifier "a4" indicates that the first lane will always have an alignment of "4". If the base shape is varying, every lane is an independent multiple of "4".