On Fri, Apr 27, 2018 at 4:07 AM, Larry Hastings <la...@hastings.org> wrote:
> * I assume that--if we don't already have one--we'll add a new
> DUP_AND_STORE_FAST opcode for binding expressions. On the other hand,
> "STORE_FAST n" followed by "LOAD_FAST n" is a common enough bytecode idiom
> that the peephole optimizer could notice it and pretty easily swap it for
> DUP_AND_STORE_FAST.
In the reference implementation, it's just DUP_TOP followed by
STORE_FAST (well, technically by "whatever the assignment compiles
to", as it could be affected by global/nonlocal, closures, etc). Is
there much advantage to creating a new opcode?
OTOH, I noticed a lot of STORE_FAST followed by LOAD_FAST in list
comprehensions. For instance, [x+1 for x in items] translates to:
1 0 BUILD_LIST 0
2 LOAD_FAST 0 (.0)
>> 4 FOR_ITER 12 (to 18)
6 STORE_FAST 1 (x)
8 LOAD_FAST 1 (x)
10 LOAD_CONST 0 (1)
12 BINARY_ADD
14 LIST_APPEND 2
16 JUMP_ABSOLUTE 4
>> 18 RETURN_VALUE
In theory, STORE_FAST followed by LOAD_FAST could be transformed into
DUP_TOP followed by STORE_FAST, and then if there is any variable that
is stored fast and never loaded, it could be optimized out. That'd
leave this with just a DUP_TOP and no variable named 'x'. No idea
whether it'd be worth the effort though.
ChrisA
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
