In perl.git, the branch smoke-me/davem/padrange has been created
<http://perl5.git.perl.org/perl.git/commitdiff/f9c5888a8389c3a59d5b22f...>
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
