7 1. The lit test runner is required to run the tests. You can either use one
11 % <path to llvm build>/bin/llvm-lit --version
15 An alternative is installing it as a python package in a python virtual
22 % pip install svn+http://llvm.org/svn/llvm-project/llvm/trunk/utils/lit
27 2. Check out the `test-suite` module with:
30 % git clone https://github.com/llvm/llvm-test-suite.git test-suite
33 3. Create a build directory and use CMake to configure the suite. Use the
34 `CMAKE_C_COMPILER` option to specify the compiler to test. Use a cache file
35 to choose a typical build configuration:
38 % mkdir test-suite-build
40 % cmake -DCMAKE_C_COMPILER=<path to llvm build>/bin/clang \
41 -C../test-suite/cmake/caches/O3.cmake \
45 4. Build the benchmarks:
49 Scanning dependencies of target timeit-target
50 [ 0%] Building C object tools/CMakeFiles/timeit-target.dir/timeit.c.o
51 [ 0%] Linking C executable timeit-target
55 5. Run the tests with lit:
58 % llvm-lit -v -j 1 -o results.json .
59 -- Testing: 474 tests, 1 threads --
60 PASS: test-suite :: MultiSource/Applications/ALAC/decode/alacconvert-decode.test (1 of 474)
61 ********** TEST 'test-suite :: MultiSource/Applications/ALAC/decode/alacconvert-decode.test' RESULTS **********
64 hash: "59620e187c6ac38b36382685ccd2b63b"
67 PASS: test-suite :: MultiSource/Applications/ALAC/encode/alacconvert-encode.test (2 of 474)
71 6. Show and compare result files (optional):
74 # Make sure pandas is installed. Prepend `sudo` if necessary.
76 # Show a single result file:
77 % test-suite/utils/compare.py results.json
78 # Compare two result files:
79 % test-suite/utils/compare.py results_a.json results_b.json
86 The test-suite contains benchmark and test programs. The programs come with
87 reference outputs so that their correctness can be checked. The suite comes
88 with tools to collect metrics such as benchmark runtime, compilation time and
91 The test-suite is divided into several directories:
95 Contains test programs that are only a single source file in size. A
96 subdirectory may contain several programs.
100 Contains subdirectories which entire programs with multiple source files.
101 Large benchmarks and whole applications go here.
105 Programs using the [google-benchmark](https://github.com/google/benchmark)
106 library. The programs define functions that are run multiple times until the
107 measurement results are statistically significant.
111 Contains descriptions and test data for code that cannot be directly
112 distributed with the test-suite. The most prominent members of this
113 directory are the SPEC CPU benchmark suites.
114 See [External Suites](#external-suites).
118 These tests are mostly written in LLVM bitcode.
122 Contains symbolic links to other benchmarks forming a representative sample
123 for compilation performance measurements.
127 Every program can work as a correctness test. Some programs are unsuitable for
128 performance measurements. Setting the `TEST_SUITE_BENCHMARKING_ONLY` CMake
129 option to `ON` will disable them.
135 The test-suite has configuration options to customize building and running the
136 benchmarks. CMake can print a list of them:
139 % cd test-suite-build
140 # Print basic options:
146 ### Common Configuration Options
150 Specify extra flags to be passed to C compiler invocations. The flags are
151 also passed to the C++ compiler and linker invocations. See
152 [https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_FLAGS.html](https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_FLAGS.html)
156 Select the C compiler executable to be used. Note that the C++ compiler is
157 inferred automatically i.e. when specifying `path/to/clang` CMake will
158 automatically use `path/to/clang++` as the C++ compiler. See
159 [https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER.html](https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER.html)
163 Select a build type like `OPTIMIZE` or `DEBUG` selecting a set of predefined
164 compiler flags. These flags are applied regardless of the `CMAKE_C_FLAGS`
165 option and may be changed by modifying `CMAKE_C_FLAGS_OPTIMIZE` etc. See
166 [https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html]](https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html)
168 - `TEST_SUITE_RUN_UNDER`
170 Prefix test invocations with the given tool. This is typically used to run
171 cross-compiled tests within a simulator tool.
173 - `TEST_SUITE_BENCHMARKING_ONLY`
175 Disable tests that are unsuitable for performance measurements. The disabled
176 tests either run for a very short time or are dominated by I/O performance
177 making them unsuitable as compiler performance tests.
179 - `TEST_SUITE_SUBDIRS`
181 Semicolon-separated list of directories to include. This can be used to only
182 build parts of the test-suite or to include external suites. This option
183 does not work reliably with deeper subdirectories as it skips intermediate
184 `CMakeLists.txt` files which may be required.
186 - `TEST_SUITE_COLLECT_STATS`
188 Collect internal LLVM statistics. Appends `-save-stats=obj` when invocing the
189 compiler and makes the lit runner collect and merge the statistic files.
191 - `TEST_SUITE_RUN_BENCHMARKS`
193 If this is set to `OFF` then lit will not actually run the tests but just
194 collect build statistics like compile time and code size.
196 - `TEST_SUITE_USE_PERF`
198 Use the `perf` tool for time measurement instead of the `timeit` tool that
199 comes with the test-suite. The `perf` is usually available on linux systems.
201 - `TEST_SUITE_SPEC2000_ROOT`, `TEST_SUITE_SPEC2006_ROOT`, `TEST_SUITE_SPEC2017_ROOT`, ...
203 Specify installation directories of external benchmark suites. You can find
204 more information about expected versions or usage in the README files in the
205 `External` directory (such as `External/SPEC/README`)
207 ### Common CMake Flags
211 Generate build files for the ninja build tool.
213 - `-Ctest-suite/cmake/caches/<cachefile.cmake>`
215 Use a CMake cache. The test-suite comes with several CMake caches which
216 predefine common or tricky build configurations.
219 Displaying and Analyzing Results
220 --------------------------------
222 The `compare.py` script displays and compares result files. A result file is
223 produced when invoking lit with the `-o filename.json` flag.
230 % test-suite/utils/compare.py baseline.json
231 Warning: 'test-suite :: External/SPEC/CINT2006/403.gcc/403.gcc.test' has No metrics!
237 INT2006/456.hmmer/456.hmmer 1222.90
238 INT2006/464.h264ref/464.h264ref 928.70
251 - Show compile_time or text segment size metrics:
254 % test-suite/utils/compare.py -m compile_time baseline.json
255 % test-suite/utils/compare.py -m size.__text baseline.json
258 - Compare two result files and filter short running tests:
261 % test-suite/utils/compare.py --filter-short baseline.json experiment.json
263 Program baseline experiment diff
265 SingleSour.../Benchmarks/Linpack/linpack-pc 5.16 4.30 -16.5%
266 MultiSourc...erolling-dbl/LoopRerolling-dbl 7.01 7.86 12.2%
267 SingleSour...UnitTests/Vectorizer/gcc-loops 3.89 3.54 -9.0%
271 - Merge multiple baseline and experiment result files by taking the minimum
275 % test-suite/utils/compare.py base0.json base1.json base2.json vs exp0.json exp1.json exp2.json
278 ### Continuous Tracking with LNT
280 LNT is a set of client and server tools for continuously monitoring
281 performance. You can find more information at
282 [http://llvm.org/docs/lnt](http://llvm.org/docs/lnt). The official LNT instance
283 of the LLVM project is hosted at [http://lnt.llvm.org](http://lnt.llvm.org).
289 External suites such as SPEC can be enabled by either
291 - placing (or linking) them into the `test-suite/test-suite-externals/xxx` directory (example: `test-suite/test-suite-externals/speccpu2000`)
292 - using a configuration option such as `-D TEST_SUITE_SPEC2000_ROOT=path/to/speccpu2000`
294 You can find further information in the respective README files such as
295 `test-suite/External/SPEC/README`.
297 For the SPEC benchmarks you can switch between the `test`, `train` and
298 `ref` input datasets via the `TEST_SUITE_RUN_TYPE` configuration option.
299 The `train` dataset is used by default.
305 You can build custom suites using the test-suite infrastructure. A custom suite
306 has a `CMakeLists.txt` file at the top directory. The `CMakeLists.txt` will be
307 picked up automatically if placed into a subdirectory of the test-suite or when
308 setting the `TEST_SUITE_SUBDIRS` variable:
311 % cmake -DTEST_SUITE_SUBDIRS=path/to/my/benchmark-suite ../test-suite
315 Profile Guided Optimization
316 ---------------------------
318 Profile guided optimization requires to compile and run twice. First the
319 benchmark should be compiled with profile generation instrumentation enabled
320 and setup for training data. The lit runner will merge the profile files
321 using `llvm-profdata` so they can be used by the second compilation run.
325 # Profile generation run:
326 % cmake -DTEST_SUITE_PROFILE_GENERATE=ON \
327 -DTEST_SUITE_RUN_TYPE=train \
331 # Use the profile data for compilation and actual benchmark run:
332 % cmake -DTEST_SUITE_PROFILE_GENERATE=OFF \
333 -DTEST_SUITE_PROFILE_USE=ON \
334 -DTEST_SUITE_RUN_TYPE=ref \
337 % llvm-lit -o result.json .
340 The `TEST_SUITE_RUN_TYPE` setting only affects the SPEC benchmark suites.
343 Cross Compilation and External Devices
344 --------------------------------------
348 CMake allows to cross compile to a different target via toolchain files. More
349 information can be found here:
351 - [http://llvm.org/docs/lnt/tests.html#cross-compiling](http://llvm.org/docs/lnt/tests.html#cross-compiling)
353 - [https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html](https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html)
355 Cross compilation from macOS to iOS is possible with the
356 `test-suite/cmake/caches/target-target-*-iphoneos-internal.cmake` CMake cache
357 files; this requires an internal iOS SDK.
361 There are two ways to run the tests in a cross compilation setting:
363 - Via SSH connection to an external device: The `TEST_SUITE_REMOTE_HOST` option
364 should be set to the SSH hostname. The executables and data files need to be
365 transferred to the device after compilation. This is typically done via the
366 `rsync` make target. After this, the lit runner can be used on the host
367 machine. It will prefix the benchmark and verification command lines with an
373 % cmake -G Ninja -D CMAKE_C_COMPILER=path/to/clang \
374 -C ../test-suite/cmake/caches/target-arm64-iphoneos-internal.cmake \
375 -D TEST_SUITE_REMOTE_HOST=mydevice \
379 % llvm-lit -j1 -o result.json .
382 - You can specify a simulator for the target machine with the
383 `TEST_SUITE_RUN_UNDER` setting. The lit runner will prefix all benchmark
387 Running the test-suite via LNT
388 ------------------------------
390 The LNT tool can run the test-suite. Use this when submitting test results to
392 [http://llvm.org/docs/lnt/tests.html#llvm-cmake-test-suite](http://llvm.org/docs/lnt/tests.html#llvm-cmake-test-suite)
395 Running the test-suite via Makefiles (deprecated)
396 -------------------------------------------------
398 **Note**: The test-suite comes with a set of Makefiles that are considered
399 deprecated. They do not support newer testing modes like `Bitcode` or
400 `Microbenchmarks` and are harder to use.
402 Old documentation is available in the
403 [test-suite Makefile Guide](TestSuiteMakefileGuide).