Tier2 peephole optimization: remove extraneous _CHECK_STACK_SPACE ops

[lazorchakp]

Implement a new peephole optimization for the tier2 optimizer that removes _CHECK_STACK_SPACE if we see that this check is already present

Linked PRs

• gh-116168: Remove extra _CHECK_STACK_SPACE uops #117242

[lazorchakp]

cc @Fidget-Spinner

This might need some labels. I also looked around for a parent ticket, but didn't find anything particularly obvious

[Fidget-Spinner]

I will link to #115419

[gvanrossum]

I don't know anything about the plan here, so this may not be news. :-) Couldn't you check for the needed stack space once at the beginning of the executor? And if there's a loop, lift it out of there. (And if it fits within the stack space of the code object already, drop it altogether.)

[Fidget-Spinner]

Makes sense. Let's go with consolidating them first then another follow-up PR for lifting. Lifting stuff out of loops requires _JUMP_ABSOLUTE and I can just point to the code from my old PR to copy. (Though the heuristics need someone else to work on it).

[gvanrossum]

Is anyone working on this? Otherwise I'd like to give it a go.

[Fidget-Spinner]

@gvanrossum I think @lazorchakp might be working on this, @lazorchakp do you mind if Guido takes over? If you have something with an implementation up but no tests that's okay, you can just submit a draft PR and Guido can probably take over if you don't mind.

[gvanrossum]

I'd also be happy to mentor @lazorchakp !

[lazorchakp]

Sorry everyone - I've been busier than anticipated and haven't made concrete progress on this yet. If it's alright though, I'd still like to try it, and I should be able to get a draft up tonight if that works. @Fidget-Spinner has given me some guidance over email, but I'd gladly accept as much mentoring as you both are willing to provide 🙂

That being said, @gvanrossum if you'd rather go for it yourself, that's quite alright! Just let me know.

[gvanrossum]

No, I'd love to have you do it!

My guess is that the critical trick should be to change the uop that checks for stack space to take a number indicating the amount of stack space needed, rather than digging that value out of the code object (which must be retrieved from the function object, which must be dug out of the stack at position -2-oparg, IIRC).

Maybe this number can be put in its operand field by the initial trace projection pass (which needs the code object anyway). Then a later dedicated pass can combine stack checks as long as they are within the same "scope" (i.e., _PUSH_FRAME/_POP_FRAME pair).

[lazorchakp]

That sounds great. It makes sense to me that we'd now need _CHECK_STACK_SPACE to know up-front how much space it's looking for. I'll see if I can take your suggestion and modify the uop so that this information is available for the optimization pass.