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.

1 files changed, 2 insertions, 1 deletions

diff --git a/opnames.h b/opnames.h
index 4b9bd8cab8..5502ba4d15 100644
--- a/opnames.h
+++ b/opnames.h
@@ -390,10 +390,11 @@ typedef enum opcode {
 	OP_PADCV	 = 373,
 	OP_INTROCV	 = 374,
 	OP_CLONECV	 = 375,
+	OP_PADRANGE	 = 376,
 	OP_max		
 } opcode;
 
-#define MAXO 376
+#define MAXO 377
 #define OP_FREED MAXO
 
 /* the OP_IS_* macros are optimized to a simple range check because