[issue2260] conditional jump to a POP_TOP optimization

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: Applied simplified patch r67253 . -- assignee: georg.brandl -> resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> ___

[issue2260] conditional jump to a POP_TOP optimization

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: Georg, would you please give this a second review. It passes the whole test suite for me and triggers often. -- assignee: rhettinger -> georg.brandl nosy: +georg.brandl ___ Python tracker <[EMA

[issue2260] conditional jump to a POP_TOP optimization

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: Adding a simpler approach. It's a bit limited because some common cases have the POP_TOP JUMP_FORWARD 1 pair split across two basic blocks. Those cases should not be optimized away on a first pass. Added file: http://bugs.python.org/file

[issue2260] conditional jump to a POP_TOP optimization

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: Am taking this one back. May have a simpler approach. -- assignee: -> rhettinger ___ Python tracker <[EMAIL PROTECTED]> _

[issue2260] conditional jump to a POP_TOP optimization

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: > Antoine, the issue with JUMP_IF variants is that they interfere with > other existing byte code optimizations, resulting in a net loss. Which other byte code optimizations does it interfere with? ___ Pyt

[issue2260] conditional jump to a POP_TOP optimization

Raymond Hettinger <[EMAIL PROTECTED]> added the comment: This looks fine to me. Go ahead and uncomment the memcpy() line (I presume you commented it out in order to demonstrate the basic transformation without the dead code elimination). Be sure to add a testcase. Antoine, the issue with JUMP_

[issue2260] conditional jump to a POP_TOP optimization

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: While this patch is interesting, I think it would be more efficient to introduce variants of JUMP_IF_FALSE and JUMP_IF_TRUE which pop their argument rather than leaving it on the stack (like I did in #2459). -- nosy: +pitrou

[issue2260] conditional jump to a POP_TOP optimization

Changes by Raymond Hettinger <[EMAIL PROTECTED]>: -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue2260] conditional jump to a POP_TOP optimization

Jack Diederich <[EMAIL PROTECTED]> added the comment: +0 * The peepholer comment promises "Optimizations are restricted to simple transformations occuring within a single basic block." and this goes beyond that. You could patch that comment. * This needs a matching patch to Lib/test/test_peepho

[issue2260] conditional jump to a POP_TOP optimization

Paul Pogonyshev <[EMAIL PROTECTED]> added the comment: Also, this is the reason for while() in the patch. Consider this function: def bar(a, b, c): if a: if b: if c: return 'true' Before the patch: 11 0 LOAD_FAST0 (a)

[issue2260] conditional jump to a POP_TOP optimization

New submission from Paul Pogonyshev <[EMAIL PROTECTED]>: This optimization targets a common case of functions like this: def foo(a, b): if a: if b: return 'true' Before the optimization: 6 0 LOAD_FAST0 (a) 3 JUMP_IF_FALSE