develooper Front page | perl.perl5.porters | Postings from October 2012

DAVEM TPF bug-grant report #137

From:
Dave Mitchell
Date:
October 22, 2012 07:44
Subject:
DAVEM TPF bug-grant report #137
Message ID:
20121022144409.GG8925@iabyn.com
This week I continued working on an optimisation that turns multiple PAD
ops and miscellanea into a single PADRANGE op.

I have this fully working now (I have some other optimisations to add, but
the basic functionality is there).

I've also done the next step, which is to add a new save type,
SAVEt_CLEARPADRANGE which allows you to specify a range of targs as single
SAVE action, rather than pushing individual SAVEt_CLEARSVs.

The combination of these two make for considerable savings when calling
lightweight subs that have lists of my declarations or usage.

Last week I was also working on a way to add an 'overlay' view of the
optree to Deparse, meaning Deparse could see a view of the optree without
the optimisation, and thus wouldn't need modifying all over the place to
handle pad ops being converted into padrange ops etc. I almost had it
working as a pure-perl proof-of-concept implementation within Deparse
itself. This week I finished it off, confirmed that it worked, but was
very slow; and have spent this week converting it into XS within B.xs
itself.

This is now almost complete - I mainly need to test it against old perls
and add documentation.

To give you an idea how easy this potentially makes things: with the
new overlay infrastructure in place in B, and with a pessimise-scan
tree-walker in place in Deparse.pm, the only code that has to be added to
Deparse.pm to support the new PADRANGE op is:

	if ($ppname eq "padrange") {
	    $B::overlay->{$$op} = {
		    name => 'pushmark',
		    private => ($op->private & OPpLVAL_INTRO),
		    next    => $op->sibling,
	    };

which makes the padrange op once again look like the pushmark op it once
was.

The other thing I spent a bit of time on was a regex bug reported by Reini
that was doing an out-of-bound access to a fold buffer. There are two
aspects to this. First, there was a specific case where the code wasn't
checking that the 'nextchr' variable wasn't the special EOF value (-10),
and thus it accessd fold_buffer[-10]. It turns out that this is harmless,
but I of course fixed it anyway.
The other issue was that Reini's ticket showed that nectchr actually had
a completely wild negative value rather than -10; however I can't
reproduce that, so am stalled awaiting further information.



Report for period 2012/10/15 to 2012/10/21 inclusive

SUMMARY
-------

    Effort (HH::MM):

        0:00 diagnosing bugs
       31:35 fixing bugs
        0:00 reviewing other people's bug fixes
        0:00 reviewing ticket histories
        0:00 review the ticket queue (triage)
       -----
       31:35 TOTAL

    Numbers of tickets closed:

           0 tickets closed that have been worked on
           0 tickets closed related to bugs that have been fixed
           0 tickets closed that were reviewed but not worked on (triage)
       -----
           0 TOTAL


DETAIL
------

[perl #114536] Optimize assigning to scalars from @_

    2012/10/15  3:15 fix

    2012/10/16  7:20 fix

    2012/10/17  5:15 fix

    2012/10/18  1:50 fix

    2012/10/19  6:10 fix

    2012/10/20  1:55 fix

    2012/10/21  1:20 fix

[perl #115332] fold_array overflow in regmatch

    2012/10/18  2:45 fix

    2012/10/19  1:45 fix

-- 
Red sky at night - gerroff my land!
Red sky at morning - gerroff my land!
    -- old farmers' sayings #14



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About