In-order execution nails every weak memory behavior
summary
Claims that an in-order, view-based model (an operational V‑IC1 semantics) captures all weak‑memory behaviors typically attributed to out‑of‑order models and that this can be done with no performance cost. Proofs show the in‑order model is stronger than RC11 and an IR strategy makes common compiler optimizations sound by having the IR use promising semantics for non‑atomics while source uses in‑order atomics. Empirical testing finds load→store buffering rare on modern CPUs, and adding an RLOAD‑STORE‑FENCE before relaxed loads prevents hardware reorderings with negligible overhead.
AI-written summary · about
chapters (8)
- 0:00In-order execution models
- 1:04Weak memory behaviors
- 3:57In-order vs out-of-order
- 7:09In-order performance issues
- 11:10Compiler IR semantics solution
- 12:39Load-store reordering
- 19:04Mapping to hardware with fences
- 20:26Q&A
related talks
01h 11mProgramming language memory models: Problems, solutions, and directions
01h 03mUsing weakly ordered C++ atomics correctly
22mRelaxed Memory Concurrency Re-executed
20mThe RISC-V Zjid Extension
01h 02mMemory and Compilers
30mA Tale of Shared Memory Concurrency in Programming Languages
24mTowards Understanding the Costs of Avoiding Out-of-Thin-Air Results
18mThe Semantics of Transactions and Weak Memory in x86, Power, ARM, and C++