[perl.git] branch smoke-me/davem/padrange, created. v5.17.5-166-gf9c5888

[Dave Mitchell]

In perl.git, the branch smoke-me/davem/padrange has been created

<http://perl5.git.perl.org/perl.git/commitdiff/f9c5888a8389c3a59d5b22fd688ad463d0384a79?hp=0000000000000000000000000000000000000000>

at f9c5888a8389c3a59d5b22fd688ad463d0384a79 (commit)

- Log -----------------------------------------------------------------
commit f9c5888a8389c3a59d5b22fd688ad463d0384a79
Author: David Mitchell <da...@iabyn.com>
Date: Mon Nov 5 13:54:51 2012 +0000

ext/B/t/OptreeCheck.pm: fix hint stripping

The code that strips hints from a nextstate couldn't handle
the 'next' pointer being '-', e.g. v:>,<,% ->-

M ext/B/t/OptreeCheck.pm

commit e7cb267f7e891c00a49b73d020cdea4adf610983
Author: David Mitchell <da...@iabyn.com>
Date: Mon Nov 5 13:06:38 2012 +0000

fix optree_misc.t test after smoke

Some of the unicode setting in a smoke environment sets the open hints
output on nextstate lines.

M ext/B/t/optree_misc.t

commit acfb99bda8736e33d69be6fb8f707cad1ba26de3
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 6b44688e589f60dff75ac8591ec5e5077e6075cd
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 ff6995202202ba6bdf7cfeb9e0ae34651d96324a
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 67333861a6a9f7e36393667b4e44fad4b681246e
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 6b600f72b2bbc6436033399ede9f1af10a72acbd
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 4cc4575a196f48a388ea69ec490c0f9e33eb1335
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 ce3f2d7582107aff9aa61a4687901b285dcc9a53
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 998b4bfd73ddf46ad725f98dad360e790ec40006
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