develooper Front page | perl.perl5.porters | Postings from July 2001

[PATCH] defer op_seq allocation

Thread Next
Abhijit Menon-Sen
July 19, 2001 09:42
[PATCH] defer op_seq allocation
Message ID:
Perl_peep() sometimes mistakenly assumes that some parts of the op tree
have been optimised, because previous runs have allocated an op_seq for
the op. Although this shouldn't matter, some things which peep() does
are essential, such as moving constants to the pad under ithreads, and
compile-time HELEM optimisations for pseudo-hashes.

I wrote the following patch, which defers op_seq allocation for OP_NULL,
when Ton Hospel reported some pseudo-hash bugs in 20010220.007. I didn't
release it then, because it clearly doesn't address the real problem.

In light of Arthur Bergman's recent "pad target under 5.7.2 ithreads,"
however, I request that my old patch be applied as a temporary measure
with the comments below (it passes all tests, and shouldn't break
anything else).

I am investigating the problem again, and will try to get a real fix out
as soon as I can.

- ams

--- current/op.c~	Thu Jul 19 21:22:36 2001
+++ current/op.c	Thu Jul 19 21:43:48 2001
@@ -6779,7 +6779,15 @@
 		PL_curcop = ((COP*)o);
-	    goto nothin;
+	    /* XXX: We avoid setting op_seq here to prevent later calls
+	       to peep() from mistakenly concluding that optimisation
+	       has already occurred. This doesn't fix the real problem,
+	       though (See 20010220.007). AMS 20010719 */
+	    if (oldop && o->op_next) {
+		oldop->op_next = o->op_next;
+		continue;
+	    }
+	    break;
 	case OP_SCALAR:
 	case OP_LINESEQ:
 	case OP_SCOPE:

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About