Convert more uops to leave their inputs on the stack to be cleaned up by `_POP_TOP`

[markshannon]

Feature or enhancement

Proposal:

This is a follow up to #134584

We have, in the JIT, optimizations to eliminate many _POP_TOP operations. To take advantage of that we have converted many uops to leave their operands on the stack and added subsequent _POP_TOPs to remove them.
See #134584 for many examples of how to do this and why it works.

However, there are still a few uops yet to do. These are:

• LIST_EXTEND
• DICT_UPDATE @Sacul0457
• SET_UPDATE @Sacul0457
• DICT_MERGE @NekoAsakura
• CALL_INTRINSIC_1 @Sacul0457
• CALL_INTRINSIC_2 @KevinH15291

In addition, POP_ITER, END_FOR and END_SEND can be implemented as macro ops, using POP_TOP to gain the benefit of the the POP_TOP optimization.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Linked PRs

• gh-145866: Convert CALL_INTRINSIC_1 to leave its inputs on the stack to be cleaned up by _POP_TOP. #145964
• gh-145866: Convert SET_UPDATE to leave its inputs on the stack to be cleaned up by _POP_TOP #145979
• gh-145866 : Update JIT contributor list #146170
• gh-145866 : Update JIT contributor list (GH-146170) #146177
• gh-145866: Implement POP_ITER as macro op using POP_TOP #146185
• gh-145866: Convert DICT_UPDATE to leave its inputs on the stack to be cleaned up by _POP_TOP #146190
• gh-145866: Convert _CALL_INTRINSIC_2 to leave its inputs on the stack to be cleaned up by _POP_TOP  #146262
• gh-145866: Convert DICT_MERGE to leave its inputs on the stack to be cleaned up by _POP_TOP #146329
• gh-145866: Convert LIST_EXTEND to leave its inputs on the stack to be cleaned up by _POP_TOP be cleaned up by _POP_TOP #146383
• gh-145866: Convert _CALL_METHOD_DESCRIPTOR_NOARGS to leave its inputs on the stack to be cleaned up by _POP_TOP #148227

[markshannon]

A few more:

• UNPACK_SEQUENCE
• UNPACK_SEQUENCE_LIST
• UNPACK_SEQUENCE_TUPLE

[Fidget-Spinner]

UNPACK_SEQUENCE

I thought we were putting those off as you mentioned in #142949 ?

[Sacul0457]

Could I work on CALL_INTRINSIC_1?

[Fidget-Spinner]

Could I work on CALL_INTRINSIC_1?

Sure. I'll assign you on the issue.

[markshannon]

UNPACK_SEQUENCE

I thought we were putting those off as you mentioned in #142949 ?

We don't want to prevent the optimization of unpacking temporary variables, like #144300, but when the unpacking is from a local variable, then it would be good to skip the decref check.

[Sacul0457]

In the meantime, would it be ok if I worked on DICT_UPDATE and SET_UPDATE?

[KevinH15291]

I'm interested in working on CALL_INTRINSIC_2.