A case for an SC-preserving compiler

Abstract

The most intuitive memory consistency model for shared-memory multi-threaded programming is sequential consistency (SC). However, current concurrent programming languages support a relaxed model, as such relaxations are deemed necessary for enabling important optimizations. This paper demonstrates that an SC-preserving compiler, one that ensures that every SC behavior of a compiler-generated binary is an SC behavior of the source program, retains most of the performance benefits of an optimizing compiler. The key observation is that a large class of optimizations crucial for performance are either already SC-preserving or can be modified to preserve SC while retaining much of their effectiveness. An SC-preserving compiler, obtained by restricting the optimization phases in LLVM, a state-of-the-art C/C++ compiler, incurs an average slowdown of 3.8% and a maximum slowdown of 34% on a set of 30 programs from the SPLASH-2, PARSEC, and SPEC CINT2006 benchmark suites.While the performance overhead of preserving SC in the compiler is much less than previously assumed, it might still be unacceptable for certain applications. We believe there are several avenues for improving performance without giving up SC-preservation. In this vein, we observe that the overhead of our SC-preserving compiler arises mainly from its inability to aggressively perform a class of optimizations we identify as eager-load optimizations. This class includes common-subexpression elimination, constant propagation, global value numbering, and common cases of loop-invariant code motion. We propose a notion of interference checks in order to enable eager-load optimizations while preserving SC. Interference checks expose to the compiler a commonly used hardware speculation mechanism that can efficiently detect whether a particular variable has changed its value since last read.

Towards understanding the costs of avoiding out-of-thin-air results

“…Researchers [Marino et al 2011;Singh et al 2012] have suggested stronger memory models, e.g., sequential consistency, in which out-of-thin-air behaviors are prohibited. They show that the cost is low when they implement such memory models on specialized hardware.…”

“…Indeed, programs with data races have undefined semantics under the C/C++11 memory model. While researchers have explored providing stronger guarantees to racy programs [Marino et al 2011;Singh et al 2012], these approaches may require hardware support to achieve competitive performance.…”

A concurrency semantics for relaxed atomics that permits optimisation and avoids thin-air executions

“…There is also work suggesting that stronger memory models, like sequential consistency, could be implementable with low overhead [18,26]. However, it relies on specialised hardware, whereas we target existing hardware.…”

CompCertTSO

“…That makes ClightTSO a good match for concurrent algorithms above those architectures, but guaranteeing TSO behavior for all (possibly racy) loads and stores prevents some compiler optimisations, and efficiently implementing TSO semantics above ARM or POWER (not in SAO mode) would be challenging. The impact of the first point is not yet clear; for example, recent work by Marino et al [2011] argues that the cost of requiring a compiler to preserve sequential consistency (a more severe restriction than preserving TSO) is modest. But Java and C/C++11 both take a DRF approach [Adve and Hill 1990], requiring the programmer to avoid races for normal accesses (thereby licensing more compiler optimisations on those) and providing Java volatiles [Manson et al 2005] and C/C++11 atomics [Batty et al 2011;Becker 2011;Boehm and Adve 2008;ISO 2011] to use for racy code.…”