René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Specialization of some instructions does not conform to PEP 659, and prevents PEP 669","articleBody":"As written, PEP 659 says that individual specializations are restricted to a single instruction.\r\nPEP 669 relies on this, as it also wants to replace instructions at runtime, and it would break if specialization occurs across multiple instructions.\r\n\r\nCurrently there are a two places where we break this design by specializing pairs of instructions together:\r\n* `COMPARE_OP` `POP_JUMP_IF_` pairs are specialized together\r\n* `FOR_ITER` `STORE_FAST` are specialized together\r\n\r\nThe second will go away with the register VM, and doesn't seem to be an issue in practice.\r\nIt is the `COMPARE_OP` `POP_JUMP_IF_` specialization that is problematic, as PEP 669 wants to instrument branches.\r\nInstrumenting the `POP_JUMP_IF_` doesn't work if the `COMPARE_OP` specialization jumps over it.\r\n\r\nThe solution is to replace the `COMPARE_OP` `POP_JUMP_IF_` pair with a single `COMPARE_AND_BRANCH` instruction that can be specialized or instrumented atomically.\n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-100983\n* gh-101985\n* gh-102801\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/markshannon","@type":"Person","name":"markshannon"},"datePublished":"2023-01-12T13:44:05.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":10},"url":"https://github.com/100982/cpython/issues/100982"}