Ugh. :-( The reason why the stack_ptr global approach is so great is that it’s only needed for frames that point pointers at stack allocated storage in a manne

Ugh. :-( The reason why the stack_ptr global approach is so great is that it’s only needed for frames that point pointers at stack allocated storage in a manner that eludes SROA. That’s rare. In fact I once saw results from A:B tests of some llvm based stack protector that used a thread-local stack_ptr thing for exactly the same cases to create some (more) secure shadow stack. The results suggested that this kind of instrumentation is perf-neutral. I think that it’s perf-neutral because it’s an uncommon case that tends to happen in large procedures in which the prologue/epilogue execution frequency is too low for prologue/epilogue instrumentation to have measurable cost. So. It’s cool to complain about seeing atrocious machine code emitted from pathological code examples. But in the end it’s all about end to end performance and to my knowledge stack_ptr is neutral on real code. (Edit: added details.)