The Solidity Optimizooooor
summary
Claim: the Yul/IR pipeline applies optimizations the legacy bytecode pass cannot, turning a multiplication-by-two into a shift across basic blocks and hoisting invariant storage reads (pulling array length out of loops) to save about 100 gas per iteration. Practical notes: copying storage into memory is often redundant under --via-ir, inspect generated assembly with --asm or online at codevault.org, always benchmark different function dispatch layouts, and rely on built-in assertions plus fuzzing and symbolic checks for correctness—no known on-chain compiler-caused failures.
AI-written summary · about
chapters (16)
- 0:00Solidity optimizer intro
- 1:55Need for Solidity optimizer
- 2:37Solidity compilation
- 5:31Bytecode optimizations
- 8:21Bytecode optimizer limits
- 10:31Yul optimizer benefits
- 12:15Storage access in loops
- 14:24Benchmarking optimizations
- 17:37Future optimizer improvements
- 20:08Compiler safety
- 23:42Use Yul optimizer
- 24:23Q&A: Storage caching
- 26:30Q&A: Yul vs legacy
- 27:12Q&A: Yul in old versions
- 28:17Q&A: Function dispatch
- 29:04Q&A: Fuzzing results
related talks
16m`via IR` speedrun
22mReconciling High-level Optimizations and Low-level Code in LLVM
33mRuby the Hard Way: Writing Bytecode to Optimize Plain Ruby
24mTowards Understanding the Costs of Avoiding Out-of-Thin-Air Results
19mExploiting Undefined Behavior in C/C++ Programs for Optimization: A Study on the(…)
20mHEaaN.MLIR: An Optimizing Compiler for Fast Ring-Based Homomorphic Encryption
20mCacheIR: The Benefits of a Structured Representation for Inline Caches
51mSwift 2 Under the Hood