The Design and Implementation of a Verification Technique for GPU Kernels

Betts, Adam; Chong, Nathan; Donaldson, Alastair F.; Ketema, Jeroen; Qadeer, Shaz; Thomson, Paul; Wickerson, John

doi:10.1145/2743017

Cited by 54 publications

(42 citation statements)

References 53 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…We also plan to use our memory model as a basis for reasoning about OpenCL programs, extending the capabilities of tools such as GPUVerify [12], where existing support for atomic operations is limited and not based on formal foundations [5].…”

Section: Resultsmentioning

confidence: 99%

Overhauling SC atomics in C11 and OpenCL

2016

Self Cite

View full text Add to dashboard Cite

Despite the conceptual simplicity of sequential consistency (SC), the semantics of SC atomic operations and fences in the C11 and OpenCL memory models is subtle, leading to convoluted prose descriptions that translate to complex axiomatic formalisations. We conduct an overhaul of SC atomics in C11, reducing the associated axioms in both number and complexity. A consequence of our simplification is that the SC operations in an execution no longer need to be totally ordered. This relaxation enables, for the first time, efficient and exhaustive simulation of litmus tests that use SC atomics. We extend our improved C11 model to obtain the first rigorous memory model formalisation for OpenCL (which extends C11 with support for heterogeneous many-core programming). In the OpenCL setting, we refine the SC axioms still further to give a sensible semantics to SC operations that employ a ‘memory scope’ to restrict their visibility to specific threads. Our overhaul requires slight strengthenings of both the C11 and the OpenCL memory models, causing some behaviours to become disallowed. We argue that these strengthenings are natural, and that all of the formalised C11 and OpenCL compilation schemes of which we are aware (Power and x86 CPUs for C11, AMD GPUs for OpenCL) remain valid in our revised models. Using the HERD memory model simulator, we show that our overhaul leads to an exponential improvement in simulation time for C11 litmus tests compared with the original model, making *exhaustive* simulation competitive, time-wise, with the *non-exhaustive* CDSChecker tool.

show abstract

Section: Resultsmentioning

confidence: 99%

Overhauling SC atomics in C11 and OpenCL

2016

Self Cite

View full text Add to dashboard Cite

show abstract

“…GPU program analysis Current GPU program analysis tools focus on data-race freedom, barrier properties and memory safety: GKLEE [28] uses concolic execution, while GPUVERIFY [10,11] is based on verification conditions and invariant generation. Extensions of these methods support atomic operations to a limited extent [9,14], but neither provides a precise analysis accounting for weak behaviours.…”

Section: Related Workmentioning

confidence: 99%

Exposing errors related to weak memory in GPU applications

Sorensen

Donaldson

2016

Proceedings of the 37th ACM SIGPLAN Conference on Programming Language Design and Implementation

Self Cite

View full text Add to dashboard Cite

We present the systematic design of a testing environment that uses stressing and fuzzing to reveal errors in GPU applications that arise due to weak memory effects. We evaluate our approach on seven GPUs spanning three Nvidia architectures, across ten CUDA applications that use fine-grained concurrency. Our results show that applications that rarely or never exhibit errors related to weak memory when executed natively can readily exhibit these errors when executed in our testing environment. Our testing environment also provides a means to help identify the root causes of such errors, and automatically suggests how to insert fences that harden an application against weak memory bugs. To understand the cost of GPU fences, we benchmark applications with fences provided by the hardening strategy as well as a more conservative, sound fencing strategy.

show abstract

“…In our study, we target GPU programs written in CUDA, the environment and language for GPU programs, and use ordinary symbolic execution. In Utah university's study, they target GPU In Imperial College London, A. Betts et al study verification for GPU programs with Boogie [3]. Boogie is the verification language proposed by Microsoft Research [4].…”

Section: Related Workmentioning

confidence: 99%

Detecting Bank Conflict of GPU Programs Using Symbolic Execution—Case Study

Hamaya¹,

Yamane²

2017

JSEA

View full text Add to dashboard Cite

GPU (Graphics Processing Unit) is used in various areas. Therefore, the demand for the verification of GPU programs is increasing. In this paper, we suggest the method to detect bank conflict by using symbolic execution. Bank conflict is one of the bugs happening in GPU and it leads the performance of programs lower. Bank conflict happens when some processing units in GPU access the same shared memory. Symbolic execution is the method to analysis programs with symbolic values. By using it, we can detect bank conflict on GPU programs which use many threads. We implement a prototype of the detector for bank conflict and evaluate it with some GPU programs. The result states that we can detect bank conflict on the programs with no loop regardless of the number of threads.

show abstract

The Design and Implementation of a Verification Technique for GPU Kernels

Cited by 54 publications

References 53 publications

Overhauling SC atomics in C11 and OpenCL

Overhauling SC atomics in C11 and OpenCL

Exposing errors related to weak memory in GPU applications

Detecting Bank Conflict of GPU Programs Using Symbolic Execution—Case Study

Contact Info

Product

Resources

About