Integer Overflow Checking Cost
2 days ago
- #integer-overflow
- #performance-benchmarking
- #compiler-optimization
- Enabling integer overflow checks should theoretically result in less than a 2x penalty per add/sub operation due to conditional branch overhead, assuming correct branch prediction.
- A pessimistic estimate suggests a 3% overall performance penalty for typical integer workloads like SPECint, with John Regehr's analysis estimating around 5%.
- Benchmarking bzip2 with clang's overflow sanitizers shows a 28% slowdown in compression and 9% in decompression when enabling diagnostics, but almost no penalty with -fsanitize-undefined-trap-on-error.
- Microbenchmarks indicate a 4x-6x slowdown for simple addition loops when using overflow checks, partly due to compiler inefficiencies in generating optimal assembly code.
- Compiler-generated code for overflow checks can be suboptimal, with clang and gcc both showing issues in register allocation and unnecessary instructions, though later versions (clang 3.8+, gcc 5+) have improved.
- Integer overflow checks are feasible with minimal overhead if error messages are not required, but current diagnostic mechanisms can significantly impact performance due to optimization limitations.