<http://perl5.git.perl.org/perl.git/commitdiff/82fc14db3e9c8dfdf6c76b9...>

        at  82fc14db3e9c8dfdf6c76b9d38537a1327bd771c (commit)

- Log -----------------------------------------------------------------
commit 82fc14db3e9c8dfdf6c76b9d38537a1327bd771c
Author: David Mitchell <da...@iabyn.com>
Date:   Fri Nov 2 16:18:20 2012 +0000

    Consolidate any single pad ops after a padrange

    Given something like
        my ($a,$b); my $c; my $d;
    then after having detected that we can create a padrange op for $a,$b,
    extend it to include $c,$d too.

    Together with the previous commit that consolidates adjacent padrange
    ops, this means that any contiguous sequence of void 'my' declarations
    that starts with a list (i.e. my ($x,..) rather than my $x) will
    all be compressed into a single padrange op. For example

        my ($a,$b);
        my @c;
        my %d;
        my ($e,@f);

    becomes the two ops

        padrange[$a;$b;@c;%d;$e;@f]
        nextstate

    The restriction on the first 'my' being a list is that we only ever
    convert pushmarks into padranges, to keep things manageable (both for
    compiling and for Deparse). This simply means that

        my $x; my ($a,$b); my @c; my %d; my ($e,@f)

    becomes

        padsv[$x]
        nextstate
        padrange[$a;$b;@c;%d;$e;@f]
        nextstate

M       ext/B/t/optree_misc.t
M       op.c

commit bbb1eb7b9ecdcff152a0b6e1d39d58886812aa12
Author: David Mitchell <da...@iabyn.com>
Date:   Fri Nov 2 14:37:29 2012 +0000

    Consolidate adjacent padrange ops

    In something like

        my ($a,$b);
        my ($c,$d);

    when converting $c,$d into a padrange op, check first whether we're
    immediately preceded by a similar padrange (and nextstate) op,
    and if so re-use the existing padrange op (by increasing the count).
    Also, skip the first nextstate and only use the second nextstate.

    So

        pushmark;
        padsv[$a]; padsv[$b]; list;
        nextstate 1;
        pushmark;
        padsv[$c]; padsv[$c]; list;
        nextstate 2;

    becomes

        padrange[$a,$b]
        nextstate 1;
        pushmark;
        padsv[$c]; padsv[$c]; list;
        nextstate 2;

    which then becomes

        padrange[$a,$b,$c,$d];
        nextstate 2;

M       ext/B/t/optree_misc.t
M       op.c

commit a4713aa2a64287de98b35ab488c129b7dd9f56cf
Author: David Mitchell <da...@iabyn.com>
Date:   Tue Oct 30 15:10:06 2012 +0000

    padrange: handle @_ directly

    In a construct like
        my ($x,$y) = @_
    the pushmark/padsv/padsv is already optimised into a single padrange
    op. This commit makes the OPf_SPECIAL flag on the padrange op indicate
    that in addition, @_ should be pushed onto the stack, skipping an
    additional pushmark/gv[*_]/rv2sv combination.

    So in total (including the earlier padrange work), the above construct
    goes from being

        3  <0> pushmark s
        4  <$> gv(*_) s
        5  <1> rv2av[t3] lK/1
        6  <0> pushmark sRM*/128
        7  <0> padsv[$x:1,2] lRM*/LVINTRO
        8  <0> padsv[$y:1,2] lRM*/LVINTRO
        9  <2> aassign[t4] vKS

    to

        3  <0> padrange[$x:1,2; $y:1,2] l*/LVINTRO,2 ->4
        4  <2> aassign[t4] vKS

M       dist/B-Deparse/Deparse.pm
M       dist/B-Deparse/t/deparse.t
M       ext/B/t/optree_misc.t
M       ext/B/t/optree_varinit.t
M       op.c
M       op.h
M       pp.c
M       pp_hot.c

commit a223b261b460cce98cbc3c2f0c99d641422a7513
Author: David Mitchell <da...@iabyn.com>
Date:   Sun Oct 28 12:58:22 2012 +0000

    reindent block in leave_scope

    The previous commit added a loop round a block of code; now increase
    the indent of the body of the loop.

M       scope.c

commit f39a6024e76dc95a7e720c2549413ed70917d48f
Author: David Mitchell <da...@iabyn.com>
Date:   Wed Oct 17 19:45:38 2012 +0100

    add SAVEt_CLEARPADRANGE

    Add a new save type that does the equivalent of multiple SAVEt_CLEARSV's
    for a given target range. This makes the new padange op more efficient.

M       op.c
M       op.h
M       pp_hot.c
M       scope.c
M       scope.h

commit c1158d4adc3dc070234ed1f2669c8d36e2369035
Author: David Mitchell <da...@iabyn.com>
Date:   Mon Sep 24 13:50:22 2012 +0100

    add padrange op

    This single op can, in some circumstances, replace the sequence of a
    pushmark followed by one or more padsv/padav/padhv ops, and possibly
    a trailing 'list' op, but only where the targs of the pad ops form
    a continuous range.

    This is generally more efficient, but is particularly so in the case
    of void-context my declarations, such as:

        my ($a,@b);

    Formerly this would be executed as the following set of ops:

        pushmark  pushes a new mark
        padsv[$a] pushes $a, does a SAVEt_CLEARSV
        padav[@b] pushes all the flattened elements (i.e. none) of @a,
                  does a SAVEt_CLEARSV
        list      pops the mark, and pops all stack elements except the last
        nextstate pops the remaining stack element

    It's now:

        padrange[$a..@b] does two SAVEt_CLEARSV's
        nextstate        nothing needing doing to the stack

    Note that in the case above, this commit changes user-visible behaviour in
    pathological cases; in particular, it has always been possible to modify a
    lexical var *before* the my is executed, using goto or closure tricks.
    So in principle someone could tie an array, then could notice that FETCH
    is no longer being called, e.g.

        f();
        my ($s, @a); # this no longer triggers two FETCHES
        sub f {
        tie @a, ...;
        push @a, 1,2;
        }

    But I think we can live with that.

    Note also that having a padrange operator will allow us shortly to have
    a corresponding SAVEt_CLEARPADRANGE save type, that will replace multiple
    individual SAVEt_CLEARSV's.

M       dist/B-Deparse/Deparse.pm
M       dist/B-Deparse/t/deparse.t
M       dump.c
M       ext/B/B/Concise.pm
M       ext/B/B/Xref.pm
M       ext/B/t/optree_sort.t
M       ext/B/t/optree_varinit.t
M       ext/Opcode/Opcode.pm
M       op.c
M       op.h
M       opcode.h
M       opnames.h
M       pp_hot.c
M       pp_proto.h
M       regcomp.c
M       regen/opcodes
M       sv.c
M       t/op/sort.t

commit 38ef356ad4d5100a1450b1d9294f23a8897dc6b8
Author: David Mitchell <da...@iabyn.com>
Date:   Tue Sep 25 12:47:51 2012 +0100

    pad_free(): don't clear SVs_PADSTALE

    pad_free() clears the SVs_PADTMP bit. Since that bit is now shared
    with SVs_PADSTALE, that gets cleared on state vars. It didn't matter up
    till now, but the next commit will start optimising away pad ops, and
    op_null() will call pad_free() which would clear the SVs_PADSTALE bit.

    So only clear SVs_PADTMP/SVs_PADSTALE for non-lexical var ops.

M       pad.c

commit 6fd74e33ad2f4ccb53c3829a9cbcc59d4e85b4b1
Author: David Mitchell <da...@iabyn.com>
Date:   Tue Oct 23 21:39:10 2012 +0100

    add $B::overlay feature

    This allows you to alter the read-only "view" of an optree, by making
    particular B::*OP methods on particular op nodes return customised values.
    Intended to be used by B::Deparse to "undo" optimisations, thus making it
    easier to add new optree optimisations without breaking Deparse.

M       ext/B/B.pm
M       ext/B/B.xs
M       ext/B/t/b.t
-----------------------------------------------------------------------

--
Perl5 Master Repository