Message63422
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_FAST 0 (a)
3 JUMP_IF_FALSE 16 (to 22)
6 POP_TOP
7 7 LOAD_FAST 1 (b)
10 JUMP_IF_FALSE 5 (to 18)
13 POP_TOP
8 14 LOAD_CONST 1 ('true')
17 RETURN_VALUE
>> 18 POP_TOP
19 JUMP_FORWARD 1 (to 23)
>> 22 POP_TOP
>> 23 LOAD_CONST 0 (None)
26 RETURN_VALUE
After:
6 0 LOAD_FAST 0 (a)
3 JUMP_IF_FALSE 16 (to 22)
6 POP_TOP
7 7 LOAD_FAST 1 (b)
10 JUMP_IF_FALSE 9 (to 22)
13 POP_TOP
8 14 LOAD_CONST 1 ('true')
17 RETURN_VALUE
18 POP_TOP
19 JUMP_FORWARD 1 (to 23)
>> 22 POP_TOP
>> 23 LOAD_CONST 0 (None)
26 RETURN_VALUE
Note that size of bytecode doesn't become smaller, however one execution
branch (jump from offset 10) becomes shorter by one JUMP_FORWARD.
Additionally, two commands at offset 18 become unreachable. However,
they will not be removed by the patch in issue1394 currently, because
there is a basic-block change at 18, where JUMP_IF_FALSE previously had
its target. If we want unreachable code be removed in such cases, we
need to make peepholer make two passes with recomputing blocks[] in
between. This would enable more optimizations. |
|
Date |
User |
Action |
Args |
2008-03-09 15:36:00 | _doublep | set | spambayes_score: 0.0353203 -> 0.03532027 recipients:
+ _doublep |
2008-03-09 15:36:00 | _doublep | set | spambayes_score: 0.0353203 -> 0.0353203 messageid: <1205076960.06.0.224700727301.issue2260@psf.upfronthosting.co.za> |
2008-03-09 15:35:59 | _doublep | link | issue2260 messages |
2008-03-09 15:35:58 | _doublep | create | |
|