GH-91095: Specialize calls to normal python classes

[markshannon]

Performance impact is small, but positive

• Issue: Specialize calls for Python classes #91095

[Fidget-Spinner]

I get the rough idea of this, and to save some time for the other reviewers, here's how it goes:

Frames before a Python class instantiation
__main__ -> NULL

Frames when a Python class is instantiated:
__main__ -> shim -> __init__ -> NULL
(Shim is responsible for replacing None returned by __init__ with self. It contains a special instruction EXIT_INIT_CHECK to verify the None.)

I'm not confident that I can catch any subtle errors with this much code. Let's test this with buildbots.

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @markshannon for commit e70711a 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

[Fidget-Spinner]

The code LGTM. But whether the perf improvement is worth the +300 lines of code I don't feel so sure. You'll have to decide that for yourself.

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @markshannon for commit b75b1aa 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

[iritkatriel]

This needs to be added to the opcodes list in the docs.

[markshannon]

I'd rather not. It shouldn't appear in any disassembly or traceback.
Once we have some sort of assembler, I want to replace

    EXIT_INIT_CHECK
    RETURN_VALUE

with

    POP_JUMP_IF_NOT_NONE error
    RETURN_VALUE
error:
    PUSH_NULL
    LOAD_CONST TypeError
    LOAD_CONST "__init__() should not return a value"
    CALL 1
    RAISE_VARARGS 1

So I expect it to removed before 3.12beta.

[markshannon]

There were too many conflicts after the many changes to the interpreter.
Closing in favour of #99331