develooper Front page | perl.perl5.porters | Postings from June 2022

Re: Optimised lexical assignments / faster macroöps

Thread Previous | Thread Next
Dave Mitchell
June 7, 2022 13:46
Re: Optimised lexical assignments / faster macroöps
Message ID:
On Mon, Jun 06, 2022 at 11:44:13AM +0100, Paul "LeoNerd" Evans wrote:
> On Thu, 2 Dec 2021 15:55:56 +0000
> "Paul \"LeoNerd\" Evans" <> wrote:
> > A few other situations that come to mind:
> > 
> >   * Giving OP_CONST the OA_TARGMY flag; so situations like
> > 
> >        $idx = 1;
> > 
> >     Could optimise away the OP_PADSV and OP_SASSIGN into a single
> >     void-context OP_CONST with a TARG set in it. 
> Well... This did not go well.
> Having made this the subject of my latest TPF grant proposal[1], I
> didn't get very far into implementing it when I hit upon a huge snag.
> Namely, that OP_CONST is an SVOP and so on threaded builds of perl, the
> op_targ field is (ab)used to store not the target of the op's result,
> but the source SV holding the actual constant.

The situation with consts on threaded builds is a bit of mess. For OPs
containing a pointer to a GV (such as OP_GVSV), the type of the op varies
between unthreaded and threaded builds, from an SVOP (which has an op_sv
field) to a PADOP (which has an op_padix field) - for both these op
types, that field is in addition to the always-present op_targ field.

However for OP_CONST, its always an SVOP, with a NULL op_sv indicating
that op_targ should be used instead.

In theory the way forward would be to first regularlise OP_CONST to be
like the GV ops and become a PADOP on threaded builds. I think this may be
complicated by when pad slots are located for consts - I think this is
done quite late in the compilation of a sub. If it were done earlier (like
however GVs are moved to the pad) then perhaps this becomes possible.

Even better might be to eliminate the PADOP type altogether, and just
make the op_sv field of the SVOP an SV* or PADOFFSET depending on whether
the build is threaded.

> >   * Extending the "op_targ" concept into the incoming argument. I
> >     notice that a few ops currently abuse that field, which is
> > supposed to be about the "target" (i.e. output destination) of an op,
> > to really encode where its source argument comes from. A few ops have
> >     the OPf_STACKED flag optionally set, and if absent it means they
> >     take their incoming argument from the pad in op_targ.
> > 
> >     This would add a new field to every UNOP to store the pad offset
> >     of its incoming argument, and then optimise every UNOP whose
> >     op_first is a PADSV into having no KID and putting the pad offset
> >     in that field instead. I suspect this would apply in many more
> >     cases in real code, than the current OA_TARGMY optimisation does
> >     now, and would give benefits to optree size and execution time, at
> >     the small cost of memory for every UNOP. This one would need some
> >     more in-depth benchmarking to make a case justifying it, but if we
> >     had some good benchmarking test cases it could show a good win.
> I therefore wonder whether this part might need to be done first,
> performing a somewhat more radical overhaul of the op system by tidying
> up the meaning of op_targ to really mean the "target" (i.e. output
> destination) of every op, and never to mean the source even in UNOP or
> SVOP cases. Having done *that*, then an assigning form of OP_CONST
> could then use both fields in this case.

Not sure I understand that proposal.

If life gives you lemons, you'll probably develop a citric acid allergy.

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