gh-117457: Correct pystats uop "miss" counts

[mdboom]

These were "broken" after trace stitching because only "_DEOPT" and "_SIDE_EXIT" opcodes were being counted, rather than the instruction that jumped there.

• Issue: pystats: Uop "miss" counts are incorrect #117457

[brandtbucher]

Looks good! Do you have an example of the new stats?

[mdboom]

Looks good! Do you have an example of the new stats?

I'll run the whole thing on our infra (just to confirm it works there) and then post here.

[mdboom]

Here's some stats from this PR: https://github.com/faster-cpython/benchmarking-public/blob/main/results/bm-20240402-3.13.0a5%2B-ee60448-JIT/bm-20240402-azure-x86_64-mdboom-tier2_pystats_misses-3.13.0a5%2B-ee60448-pystats.md#uop-execution-stats

[erlend-aasland]

I now get a complaint regarding generated files on my PRs. Did you forget to make regen-all?

Here's what I get if I do make regen-all on current main (HEAD at 9c1dfe2):

diff --git a/Python/executor_cases.c.h b/Python/executor_cases.c.h
index 9c6e42a1a8..a3447da004 100644
--- a/Python/executor_cases.c.h
+++ b/Python/executor_cases.c.h
@@ -3984,8 +3984,14 @@
         case _CHECK_STACK_SPACE_OPERAND: {
             uint32_t framesize = (uint32_t)CURRENT_OPERAND();
             assert(framesize <= INT_MAX);
-            if (!_PyThreadState_HasStackSpace(tstate, framesize)) JUMP_TO_JUMP_TARGET();
-            if (tstate->py_recursion_remaining <= 1) JUMP_TO_JUMP_TARGET();
+            if (!_PyThreadState_HasStackSpace(tstate, framesize)) {
+                UOP_STAT_INC(uopcode, miss);
+                JUMP_TO_JUMP_TARGET();
+            }
+            if (tstate->py_recursion_remaining <= 1) {
+                UOP_STAT_INC(uopcode, miss);
+                JUMP_TO_JUMP_TARGET();
+            }
             break;
         }
 

PR:

• gh-117457: Regen executor cases post PR #117477 #117559

[gvanrossum]

I'm surprised this didn't fail a CI test.

[erlend-aasland]

I'm surprised this didn't fail a CI test.

Yes. IIRC, similar things have happened before, and I think we have an open issue for it.

[mdboom]

I'm surprised this didn't fail a CI test.

Yes. IIRC, similar things have happened before, and I think we have an open issue for it.

I imagine it's something that falls through the cracks between a new opcode being added, and the merge conflict detection not picking that up in this PR.

[brandtbucher]

Yeah, probably the CI for this PR ran on an older merge commit, then somebody pushed something that didn't conflict at the source level but changes after regen. (Exactly the sort of thing merge queues are meant to solve!)

Thanks for the fix!