GH-95113: Don't use EXTENDED_ARG_QUICK in unquickened code

[brandtbucher]

• Issue: gh-95113

Automerge-Triggered-By: GH:brandtbucher

[markshannon]

In theory the unquickened form of EXTENDED_ARG should be very rare, so this should have no effect on performance.
So I'm not worried about that.

Could you add a comment to EXTENDED_ARG explaining why it uses _PyOpcode_Deopt[opcode] rather than opcode.
Other than that LGTM.

[bedevere-bot]

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

[markshannon]

One other thing that might merit a comment.
If RESUME were prefixed by EXTENDED_ARG then the RESUME would not trace correctly.
Since RESUME only has a meaningful oparg in range(3) this shouldn't happen, but might be worth making that explicit somewhere.

[sweeneyde]

I think this makes things conceptually simpler:

• EXTENDED_ARG/EXTENDED_ARG_QUICK is now more similar to the JUMP_BACKWARD/JUMP_BACKWARD_QUICK situation.
• It avoids special-casing EXTENDED_ARG with a separate opcode table.
• It avoids leaking the _QUICK terminology to dis users that theoretically shouldn't have to care.

The tiny downside is that unquickened EXTENDED_ARGs need one more _PyOpcode_Deopt[...] memory access, which should be totally insignificant, so LGTM.

[miss-islington]

Thanks @brandtbucher for the PR 🌮🎉.. I'm working now to backport this PR to: 3.11.
🐍🍒⛏🤖

[miss-islington]

Sorry, @brandtbucher, I could not cleanly backport this to 3.11 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker e402b26b7fb953a2f0c17a0044bb6d6cbd726e54 3.11

[bedevere-bot]

GH-95143 is a backport of this pull request to the 3.11 branch.