Compilers should get over themselves and respect semantic dependencies!
summary
Argues that C/C++ compilers must preserve meaningful runtime dataflow because no real system exhibits OOTA and physics plus hardware practice constrain executions; analyzes relaxed-load/store examples and shows semantic dependency is often per-execution not a static property; inspects compiler behaviors (speculative load insertion, prior-specialization) and kernel pragmas (forcing unsigned char) as tools and mitigations; cites 15 years of memory-model work and papers exposing buggy optimizations (e.g. CAS-based stack push) to show practical failures when dependencies break, and urges temporal checks in code generation.
AI-written summary · about
chapters (6)
- 0:00Introduction and poll
- 2:34Defining semantic dependency
- 5:22Language standards and behavior
- 10:02Challenges in formal modeling
- 13:33Compiler optimization concerns
- 16:13Q&A and closing remarks
related talks
01h 11mProgramming language memory models: Problems, solutions, and directions
01h 27mDangerous Optimizations! in C++ - Part Deux
01h 30mDangerous Optimizations in C and C++ Programming Languages
25mSource-level debugging of compiler-optimised code: ill-posed, but not impossible
58mGarbage In, Garbage Out: Arguing about Undefined Behavior...
10mClear as Mud
59mCompilers can be surprising
18mThe Semantics of Transactions and Weak Memory in x86, Power, ARM, and C++