This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
[MERGE] add PADRANGE op and $B::overlay
authorDavid Mitchell <davem@iabyn.com>
Sat, 10 Nov 2012 11:35:46 +0000 (11:35 +0000)
committerDavid Mitchell <davem@iabyn.com>
Sat, 10 Nov 2012 13:39:34 +0000 (13:39 +0000)
commit0fe870f5e3a70e7203df3b415bb5e16f873463b0
treef190c696008217b9265af11906df9e8fb44c5573
parent11911e219c403b8773ab8f4e97d5fb23c092aa86
parentaa0b6d222413658ae4aa5d25a8bc475ba92abae2
[MERGE] add PADRANGE op and $B::overlay

This commit implements three optimisations and one new feature.

The new feature is $B::overlay, which can be set to a hash ref, indexed by
op address, that allows you to override the values returned by the various
B::*OP methods for a particular op. This specifically allows Deparse to be
tricked into seeing a pre-optimisation view of the optree, and so makes
adding new optimisations (like the one in this commit) a lot easier.

As regards optimisations: first, a new save type is added:
SAVEt_CLEARPADRANGE, which is like SAVEt_CLEARSV but specifies a range of
targs to be cleared. The save type, target base and range all fit within a
single integer pushed on the save stack.

Second, a pushmark followed by one or more pad[ahs]v ops (and possibly
some mixed-in null, list and nextstate ops) will sometimes be replaced by
a single padrange op. Like other pad ops, this specifies a targ, but in
addition the bottom 7 bits of op_private indicate a target range.
pp_padrange has two main actions: with OPpLVAL_INTRO, it pushes a
SAVEt_CLEARPADRANGE onto the save stack and turns off SvPADSTALE on all
the lexicals; and in non-void context, it pushes all the lexicals onto the
stack.

Third, for the specific case of the construct my(...) = @_, the
ops to push @_ onto the stack (pushmark/gv[*_]/rv2sv) are skipped,
and the OPf_SPECIAL flag on the padrange op is set: this tells
pp_padrange to push @_ directly.

Note that not sequences of pad ops are consolidated into a single
padrange op; the chief constraints are that:

* they must form a list (i.e. start with pushmark);
* the targs must form a contiguous range;
* the flags of the ops must all be similar; e.g. all INTRO or all not,
   all void or all not, etc;
* only a subset of flags are allowed; e.g. we don't optimise with
  OPpPAD_STATE or OPpMAYBE_LVSUB present.

For the specific case of void/INTRO, we consolidate across nextstate
boundaries (keeping only the last nextstate); i.e.

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

becomes a single padrange op. Note that the padrange optimisation is
particularly efficient for the void/INTRO combination: formerly,
my($a,$b,@c,%d); would be compiled as

    pushmark; padsv[$a]; padsv[$b]; padav[@c]; padhv[%d]; list; nextstate

which would have the effect of pushing $a, $b onto the stack, then
pushing the (non-existent) elements of @c, then pushing the %d HV; then
pp_list would pop all the elements except the last, %h; finally, nextstate
would pop %h.  Instead, padrange skips all the pushing and popping in void
context.  Note that this means that there is one user-visible change caused
by this optimisation:

    f();
    my @a;
    sub f { tie @a, ...; push @a, .... }

Here, @a is tied and already has elements by the time the 'my @a' is
executed; formerly, FETCH would be called repeatedly to push the elements
of @a onto the stack, then they would all be popped again at the end of the
'my @a' statement; now FETCH is never called.

The optimisation itself is implemented by converting the initial pushmark
op into a padrange, and updating its op_next. The skipped ops are *not*
cleared; this makes it easier for S_find_uninit_var() and Deparse.pm to do
their stuff. Deparse is implemented by using the new $B::overlay facility
to make the padrange op look like a pushmark op again; the rest of the
Deparse code just sees the original unoptimised optree and so doesn't
require any knowledge of the padrange op.