Engineering a Static Verification Tool for GPU Kernels

Bardsley, Ethel; Betts, Adam; Chong, Nathan; Collingbourne, Peter; Deligiannis, Pantazis; Donaldson, Alastair F.; Ketema, Jeroen; Liew, Daniel; Qadeer, Shaz

doi:10.1007/978-3-319-08867-9_15

Cited by 32 publications

(24 citation statements)

References 31 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…As a result, the bf entries are all 0 for 1+, and the to entries are close to 0 for this configuration (there are some timeouts because we recorded full result 9 32 9 31 9 32 122 144 20 5 20 4 7 5 4 2 626 625 1747 bf 396 0 397 0 397 0 396 0 0 0 0 33 0 33 0 70 1720 1720 0 0 5162 c 352 523 365 537 553 530 539 520 289 185 831 630 831 622 51 226 18 155 4 4 data for 1+ after completing the test generation process, using a separate test run during which some of the generated tests did time out). The other NVIDIA configurations (2,3,4) show similarly low build failure and timeout numbers without optimizations, as might be expected since they have similar performance characteristics and likely share compilation infrastructure between driver versions. The lack of build failures, and the low number of timeouts, means that most tests executed with a non-crash result on the NVIDIA configurations.…”

Section: Testing Using Clsmithmentioning

confidence: 54%

“…Finding such dynamically-dead code in OpenCL applications is hindered by (a) the lack of available code-coverage tools for OpenCL, and (b) the fact that dynamically-dead code is rare in practical OpenCL kernels: a recent study of 605 kernels shows that only a handful exhibit input-dependent behaviour [2], a necessary (but not sufficient) condition for dynamically-dead code. Problem (a) could be overcome 3 https://github.com/jrprice/Oclgrind with non-trivial engineering effort (e.g.…”

Section: Lifting Compiler Fuzzing To Openclmentioning

confidence: 99%

“…One example was the expression (int2) (1,2).y, the intent of which was to access the y component of a 2D vector. Some compilers accepted this expression, interpreting the expression as ((int2) (1,2)).…”

Section: Example Bugsmentioning

confidence: 99%

See 2 more Smart Citations

Many-core compiler fuzzing

et al. 2015

Self Cite

View full text Add to dashboard Cite

We address the compiler correctness problem for many-core systems through novel applications of fuzz testing to OpenCL compilers. Focusing on two methods from prior work, random differential testing and testing via equivalence modulo inputs (EMI), we present several strategies for random generation of deterministic, communicating OpenCL kernels, and an injection mechanism that allows EMI testing to be applied to kernels that otherwise exhibit little or no dynamically-dead code. We use these methods to conduct a large, controlled testing campaign with respect to 21 OpenCL (device, compiler) configurations, covering a range of CPU, GPU, accelerator, FPGA and emulator implementations. Our study provides independent validation of claims in prior work related to the effectiveness of random differential testing and EMI testing, proposes novel methods for lifting these techniques to the many-core setting and reveals a significant number of OpenCL compiler bugs in commercial implementations.

show abstract

Section: Testing Using Clsmithmentioning

confidence: 54%

Section: Lifting Compiler Fuzzing To Openclmentioning

confidence: 99%

See 1 more Smart Citation

Many-core compiler fuzzing

et al. 2015

Self Cite

View full text Add to dashboard Cite

show abstract

“…We make explicit how the current article significantly extends a previous conference version [Betts et al 2012] and complements other papers that have arisen from the GPUVerify project [Collingbourne et al 2013;Chong et al 2013;Bardsley et al 2014a;.…”

Section: Contributions In Relation To Prior Workmentioning

confidence: 58%

“…As well as technical articles that extend the core verification method, a recent tool paper discusses engineering experience and insight gained during the GPUVerify project [Bardsley et al 2014a], and an invited article provides a tutorial overview of the technique [Donaldson 2014]. We have also applied GPUVerify as a component in an automatic verification method for parallel prefix sum kernels .…”

Section: Contributions In Relation To Prior Workmentioning

confidence: 99%

The Design and Implementation of a Verification Technique for GPU Kernels

Betts

Chong

Donaldson

et al. 2015

ACM Trans. Program. Lang. Syst.

Self Cite

View full text Add to dashboard Cite

We present a technique for the formal verification of GPU kernels, addressing two classes of correctness properties: data races and barrier divergence. Our approach is founded on a novel formal operational semantics for GPU kernels termed synchronous, delayed visibility (SDV) semantics, which captures the execution of a GPU kernel by multiple groups of threads. The SDV semantics provides operational definitions for barrier divergence and for both inter-and intra-group data races. We build on the semantics to develop a method for reducing the task of verifying a massively parallel GPU kernel to that of verifying a sequential program. This completely avoids the need to reason about thread interleavings, and allows existing techniques for sequential program verification to be leveraged. We describe an efficient encoding of data race detection and propose a method for automatically inferring the loop invariants that are required for verification. We have implemented these techniques as a practical verification tool, GPUVerify, that can be applied directly to OpenCL and CUDA source code. We evaluate GPUVerify with respect to a set of 162 kernels drawn from public and commercial sources. Our evaluation demonstrates that GPUVerify is capable of efficient, automatic verification of a large number of real-world kernels.

show abstract

Checking Data-Race Freedom of GPU Kernels, Compositionally

Cogumbreiro

Lange

Rong

et al. 2021

Computer Aided Verification

View full text Add to dashboard Cite

GPUs offer parallelism as a commodity, but they are difficult to program correctly. Static analyzers that guarantee data-race freedom (DRF) are essential to help programmers establish the correctness of their programs (kernels). However, existing approaches produce too many false alarms and struggle to handle larger programs. To address these limitations we formalize a novel compositional analysis for DRF, based on access memory protocols. These protocols are behavioral types that codify the way threads interact over shared memory.Our work includes fully mechanized proofs of our theoretical results, the first mechanized proofs in the field of DRF analysis for GPU kernels. Our theory is implemented in , a tool that outperforms the state-of-the-art. Notably, it can correctly verify at least $$1.42{\times }$$ 1.42 × more real-world kernels, and it exhibits a linear growth in 4 out of 5 experiments, while others grow exponentially in all 5 experiments.

show abstract

Engineering a Static Verification Tool for GPU Kernels

Cited by 32 publications

References 31 publications

Many-core compiler fuzzing

Many-core compiler fuzzing

The Design and Implementation of a Verification Technique for GPU Kernels

Checking Data-Race Freedom of GPU Kernels, Compositionally

Contact Info

Product

Resources

About