add new bytecodes: JUMP_IF_{FALSE|TRUE}_AND_POP

[doublep]

BPO	1764638
Nosy	@rhettinger
Files	new-bytecodes.diff: patch, working but far from production use

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/rhettinger'
closed_at = <Date 2008-01-14.22:31:02.534>
created_at = <Date 2007-07-31.14:12:00.000>
labels = ['interpreter-core', 'type-feature']
title = 'add new bytecodes: JUMP_IF_{FALSE|TRUE}_AND_POP'
updated_at = <Date 2008-01-14.22:31:02.533>
user = 'https://bugs.python.org/doublep'

bugs.python.org fields:

activity = <Date 2008-01-14.22:31:02.533>
actor = 'rhettinger'
assignee = 'rhettinger'
closed = True
closed_date = <Date 2008-01-14.22:31:02.534>
closer = 'rhettinger'
components = ['Interpreter Core']
creation = <Date 2007-07-31.14:12:00.000>
creator = 'doublep'
dependencies = []
files = ['8293']
hgrepos = []
issue_num = 1764638
keywords = []
message_count = 3.0
messages = ['55153', '55154', '55155']
nosy_count = 2.0
nosy_names = ['rhettinger', 'doublep']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue1764638'
versions = ['Python 2.6']

[doublep]

In disassembled code of Python functions I often see stuff like this:

        421 JUMP_IF_FALSE           14 (to 438)
        424 POP_TOP

1178 ...
435 JUMP_FORWARD 1 (to 439)
>> 438 POP_TOP
>> 439 END_FINALLY

Note how both branches of execution after JUMP_IF_FALSE do POP_TOP. This causes the true-branch add JUMP_FORWARD, the only purpose of which is to bypass the POP_TOP command.

I propose adding two new bytecodes, JUMP_IF_FALSE_AND_POP and JUMP_IF_TRUE_AND_POP. Their semantics would be the same as that of existing JUMP_IF_FALSE/JUMP_IF_TRUE except the commands would also pop the stack once, after checking whether to jump. This would simplify the above code to just

        421 JUMP_IF_FALSE_AND_POP           14 (to 438)

1178 ...
>> 438 END_FINALLY

This shortens bytecode by 5 bytes and both execution branches, by 1 and 2 commands correspondingly.

I'm willing to create a patch, if this sounds like a worthwile improvement. Maybe it is better to skip 2.6 and target it for 3000 instead.

[doublep]

I have made first stab at this. It shows about 2% speedup on pystone, even though peephole optimizer does no related optimizations for new bytecodes yet.

Note that having separate entries in ceval.c's switch() for the new bytecodes is essential. Perhaps because they are also used for prediction, not sure.

File Added: new-bytecodes.diff

[rhettinger]

This was looked at and rejected long ago.
The main reasons were that the new code would interfere with and complicate other byte code optimizations. Also, the need was mitigated almost entirely by the predict macros.