"Paul Johnson" <[EMAIL PROTECTED]> wrote:
> >
> > op_seq seems to be used only as a flag : "has this OP been optimized by
> > now"
>
> It is also used by B::C. The value -1 is a flag to indicate that an op is
> statically defined and should not be freed.
So we could theorically replace op_seq by two boolean flags, as far as
the core and the bytecode compiler backend are concerned.
> >> Removing the -1 condition doesn't cause any obvious test failures.
>
> How are those compiler tests? :-/
I didn't run the special compiler test target.
> > Moreover, turning op_seq from a counter into a boolean flag doesn't cause
> > any test failure either (except for B::Concise of course, that uses
>
> After the optimisation phase it is not required. Indeed, B::Bytecode has
> an option not to fill in that field.
>
> > the value of op_seq in its output). op_seq is not related to cop_seq,
> > and I suspect it's obsolete.
>
> I use it in Devel::Cover in conjunction with the address of the op in
> order to (almost) uniquely identify the op. Without this when ops get
> freed and the address is reused they cannot be told apart. I believe that
> Devel::Dprof also suffers from this problem, though maybe there is a
> better solution.
B::Concise also uses it to identify ops.
--- op.c (revision 622)
+++ op.c (working copy)
@@ -224,6 +224,8 @@
register OP *kid, *nextkid;
OPCODE type;
+ /* The special value -1 is used by the B::C compiler backend to indicate
+ * that an op is statically defined and should not be freed. */
if (!o || o->op_seq == (U16)-1)
return;
End of patch.
