RetroSearch Browse

Thu Apr 26 14:18:43 EDT 2018 · https://mail.python.org/pipermail/python-dev/2018-April/153145.html

On Fri, Apr 27, 2018 at 4:07 AM, Larry Hastings <larry at 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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2018-April/153145.html below:

[Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!