That makes sense and isn't something I had considered, but a 32-bit displacement vs an 8-bit displacement just leads to bloat in binary size, it doesn't affect

That makes sense and isn't something I had considered, but a 32-bit displacement vs an 8-bit displacement just leads to bloat in binary size, it doesn't affect how many cycles your movs jumps etc. take. There are some second order effects of things where larger code size can cause you to get a worse hit rate in the instruction cache, but usually those effects are miniscule when you actually benchmark code. There are going to be some pathological programs where the instruction cache hit rate gets way worse with the large binary size, but I can't really think of many programs I've seen that are mostly stalled on instruction decoding/fetching. Here's my hypothesis of why stack-pointer offsets haven't been implemented when compiling with frame pointers. At companies like Google/Facebook that compile huge C++ binaries (usually 100MB+ stripped) it's common that production binaries would be compiled with something like -fno-omit-frame-pointer (so system-wide profiling can be done on all C++ code in production) and also generate split debug symbols using -gline-tables-only. The latter compiler flag basically just generates enough DWARF information to recover the mapping of pc -> source code line, so if you get a core dump you can figure out which line of C++ code was actually being executed in each frame of the call stack. If you're doing frame-pointer offsets it means that you can also recover the value of local variables in each frame (assuming they haven't been optimized out by the inliner) just based on the offset of the variable from the frame-pointer. So basically -fno-omit-frame-pointer and -gline-tables-only give you enough debug data to get the full call stack with line numbers and the values of local variables in each frame (except the inlined ones), while also minimizing the cost of generating/storing debug data.