For performance we keep the stack pointer in a register, however this means that the stack pointer is invisible to debuggers and other tools. If we spill the stack pointer across "escaping" calls, then most of the time we want to inspect the evaluation the stack pointer should be in memory.
Spilling the stack pointer is also a necessary precursor to deferred reference counting: https://github.com/faster-cpython/ideas/issues/677, https://github.com/python/cpython/issues/117139, as it means there is no need to redundantly set the unused part of the stack to `NULL`.

Since the C compiler needs to spill values around calls, manually spilling the stack pointer has quite a low cost. It limits the freedom of the C compiler to allocate registers, but not that much.



<!-- gh-linked-prs -->
### Linked PRs
* gh-119875
<!-- /gh-linked-prs -->

Spill the stack pointer across calls in the interpreter.
This is a GitHub Issue
repo:cpython
owner:python
Title : Spill the stack pointer across calls in the interpreter.
Issue date:

--- start body ---
For performance we keep the stack pointer in a register, however this means that the stack pointer is invisible to debuggers and other tools. If we spill the stack pointer across "escaping" calls, then most of the time we want to inspect the evaluation the stack pointer should be in memory.
Spilling the stack pointer is also a necessary precursor to deferred reference counting: https://github.com/faster-cpython/ideas/issues/677, https://github.com/python/cpython/issues/117139, as it means there is no need to redundantly set the unused part of the stack to `NULL`.

Since the C compiler needs to spill values around calls, manually spilling the stack pointer has quite a low cost. It limits the freedom of the C compiler to allocate registers, but not that much.



<!-- gh-linked-prs -->
### Linked PRs
* gh-119875
<!-- /gh-linked-prs -->

--- end body ---
