gh-141976: Protect against non-progressing specializations in tracing JIT

[Fidget-Spinner]

I do not have a test for this as it's too hard to test for. We require the following scenario to happen:

1. Non-progressing specialization
2. that deopts

We don't have that many non-progressing specializations to begin with, so any test is a futile fight between the internal implementation details and the JIT.

I have verified this fixes the test case in the issue. I'm not using the test case in the issue as it's dependent on how much stack space we reserve and consume per stack chunk. If we ever change the stack chunks size, the test will break.

• Issue: JIT: Assertion failure for WITHIN_STACK_BOUNDS() in optimize_uops #141976

[markshannon]

This doesn't look correct to me.

The tracing front-end should produce correct code. Working around it in the optimizer is a bad idea as it just hides a bug that we should be fixing.
And the workaround doesn't make a lot of sense to me. It looks like we are missing a guard. How does checking the backoff counter help?

[Fidget-Spinner]

This doesn't look correct to me.

The tracing front-end should produce correct code. Working around it in the optimizer is a bad idea as it just hides a bug that we should be fixing.

This is fixing a bug in the tracing front-end, not the optimizer. Please see that the function is _PyJit_translate_single_bytecode_to_trace.

We are not missing a guard.

[markshannon]

This is fixing a bug in the tracing front-end, not the optimizer.

Not what you said here 😉

Maybe the tracer needs its own file.

I'm still not convinced by this PR. It is probably right, but there a number of possible deopt/specialization possibilities and I'll like to see a full table/state machine to make sure we are handling all of them.