Feature Requests item #1764638, was opened at 2007-07-31 17:12
Message generated for change (Comment added) made by doublep
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1764638&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Paul Pogonyshev (doublep)
Assigned to: Nobody/Anonymous (nobody)
Summary: add new bytecodes: JUMP_IF_{FALSE|TRUE}_AND_POP

Initial Comment:
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.


----------------------------------------------------------------------

>Comment By: Paul Pogonyshev (doublep)
Date: 2007-08-02 00:52

Message:
Logged In: YES 
user_id=1203127
Originator: YES

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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1764638&group_id=5470
_______________________________________________
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to