Re: [PATCH] defer op_seq allocation

Abhijit Menon-Sen <ams@wiw.org> writes:
>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).

Applied in that basis as Change 11415

>
>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:
-- 
Nick Ing-Simmons
http://www.ni-s.u-net.com/

• [PATCH] defer op_seq allocation by Abhijit Menon-Sen
• Re: [PATCH] defer op_seq allocation by Nick Ing-Simmons
• Re: [PATCH] defer op_seq allocation by Arthur Bergman