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.

Title: add new bytecodes: JUMP_IF_{FALSE|TRUE}_AND_POP
Type: enhancement Stage:
Components: Interpreter Core Versions: Python 2.6
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: doublep, rhettinger
Priority: normal Keywords:

Created on 2007-07-31 14:12 by doublep, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
new-bytecodes.diff doublep, 2007-08-01 21:52 patch, working but far from production use
Messages (3)
msg55153 - (view) Author: Paul Pogonyshev (doublep) Date: 2007-07-31 14:12
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.
msg55154 - (view) Author: Paul Pogonyshev (doublep) Date: 2007-08-01 21:52
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
msg55155 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2007-08-02 04:24
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.
Date User Action Args
2022-04-11 14:56:25adminsetgithub: 45261
2008-01-14 22:31:02rhettingersetstatus: open -> closed
resolution: rejected
2007-07-31 14:12:00doublepcreate