Dealing with aliasing using contracts
summary
Shows that LLVM emits extra loads when parameters may alias and that C’s restrict enables vectorization, then proposes using contracts plus a new unique span type so the compiler can treat element accesses as non‑aliasing (e.g. an disjoint(a,b,num) precondition) and unlock optimizations otherwise missed. Demonstrates current mitigations like runtime checks, static analysis, optimization remarks and LLVM look‑versioning (loop versioning) already generate alternate fast paths, but the contracts+type approach is a prototype idea not yet standardized or fully implemented.
AI-written summary · about
chapters (12)
- 0:00Introduction and talk overview
- 1:11Aliasing in function arguments
- 3:48Why aliasing matters for performance
- 5:36C’s restrict qualifier limitations
- 7:50Contracts for aliasing preconditions
- 12:15Extending contracts for disjoint arrays
- 14:05User-defined types and aliasing
- 17:24Unique span for non-aliasing views
- 20:46Benefits of separate types for guarantees
- 23:17Passing arguments by value vs reference
- 25:20Audience questions and discussion
- 35:44Q&A on aliasing optimizations
related talks
25mThe Road Not Taken: Exploring Alias Analysis Based Optimizations Missed by the Compiler
57mAliasing: Risks, Opportunities and Techniques
20mRelaxing Alias Analysis: Exploring the Unexplored Space
16mSemiring Optimizations: Dynamic Elision of Expressions with Identity and Absorbing Elements
37mMemory Safety Everywhere with Both Rust and Carbon
22mReconciling High-level Optimizations and Low-level Code in LLVM
01h 21mProgramming with Contracts in C++20
27mCompiler Support for Control-Flow Linearization Using Architectural Mimicry