GH-131798: Remove JIT guards for dict, frozenset, list, set, and tuple

[brandtbucher]

According to the stats, this removes:

• 144 million tuple guards (25%)
• 280 million set/frozenset guards (19%)
• 484 million dict guards (42%)
• 1.3 billion list guards (34%)

It also fixes a bug that I encountered in the optimizer's logic for _UNPACK_SEQUENCE_TUPLE, which puts items on the stack in reverse order.

• Issue: Better uop coverage in the JIT optimizer #131798

[brandtbucher]

@Zheaoli and @tomasr8, you might be interested in checking this out. Specifically, see the changes in Python/bytecodes.c which use the same syntax as Python/optimizer_bytecodes.c, but describes the actual implementations of these instructions.

You can see that this PR breaks up the old, larger instr definitions into smaller op definitions combined into a macro. This doesn't change the semantics of the instruction itself, but allows the JIT to remove parts of the instruction as it sees fit (in this case, separating out the type checks allows the JIT to remove them).

[Fidget-Spinner]

Just one concern.

[Fidget-Spinner]

Does CONTAIN_OP_SET and CONTAIN_OP_DICT need to remove their sym setting type as well? Or is that not even happening at the moment?

[brandtbucher]

Not happening currently,. _CONTAINS_OP_SET can't even set anything, since it handles both set and frozenset (this might be worth re-evaluating, or splitting up).

[Zheaoli]

@Zheaoli and @tomasr8, you might be interested in checking this out. Specifically, see the changes in Python/bytecodes.c which use the same syntax as Python/optimizer_bytecodes.c, but describes the actual implementations of these instructions.

You can see that this PR breaks up the old, larger instr definitions into smaller op definitions combined into a macro. This doesn't change the semantics of the instruction itself, but allows the JIT to remove parts of the instruction as it sees fit (in this case, separating out the type checks allows the JIT to remove them).

Thanks! I think I might need some time to understand this PR! Thanks for your patience!

[brandtbucher]

Going to go ahead and merge this to reduce the risk of merge conflicts, but let me know if you have any questions @Zheaoli!