This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author iritkatriel
Recipients iritkatriel
Date 2022-03-30.17:28:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1648661334.4.0.0596431149271.issue47172@roundup.psfhosted.org>
In-reply-to
Content
There are a few "virtual opcodes" which are internal to the compiler. They can have values > 256. This way we don't waste any valid opcodes on them, and it is easier to detect when one of them escapes the compiler into the assemble stage.

In addition, there is an is_jump() function that treats the exception handling opcodes as jumps (and also assumes that any opcode >= SETUP_WITH is a jump):

static inline int
 is_jump(struct instr *i)
 {
    return i->i_opcode >= SETUP_WITH || is_bit_set_in_table(_PyOpcode_Jump, i->i_opcode);
 }

Then there is is_block_push just for the three virtual exception block opcodes:

static inline int
is_block_push(struct instr *instr)
{
    int opcode = instr->i_opcode;
    return opcode == SETUP_FINALLY || opcode == SETUP_WITH || opcode == SETUP_CLEANUP;
}

We can make is_jump return true just for jumps, and call is_block_push as well when it is needed (currently sometimes we call is_jump when there cannot be virtual opcodes anymore so we can assert that instead, and in one place we call is_jump and then exclude the virtual opcodes. Both of these will become clearer after we make this change).
History
Date User Action Args
2022-03-30 17:28:54iritkatrielsetrecipients: + iritkatriel
2022-03-30 17:28:54iritkatrielsetmessageid: <1648661334.4.0.0596431149271.issue47172@roundup.psfhosted.org>
2022-03-30 17:28:54iritkatriellinkissue47172 messages
2022-03-30 17:28:54iritkatrielcreate