Front page | perl.perl5.porters |
Postings from February 2017
Re: more process_optree
Thread Previous
|
Thread Next
From:
Dave Mitchell
Date:
February 15, 2017 16:58
Subject:
Re: more process_optree
Message ID:
20170215165826.GO8149@iabyn.com
On Wed, Feb 15, 2017 at 09:19:30AM -0700, Jim Cromie wrote:
> OK. Begging your forbearance, heres what Im trying to do:
>
> usage of op-sibling and op-ppaddr are almost mutually exclusive,
> and they can be unionized.
> opsibling is set early, and used heavily in optimization,
> but rarely afterwards.
> ppaddr is set early too, but can be deferred until after optimization,
But some CPAN modules hook into the peephole optimiser or possibly earlier
to set the op_ppaddr address to a non-standard value. So I don't think
that scheme would work.
> At finalization, opsibling can be saved to an HV,
> so its available at runtime for the occasional need.
But that would use far more storage than having a separate op_sibling
field. The HV for every CV would also have to be duplicated for each new
thread created (whereas optrees are shared).
> Ive got the above mostly fleshed out,
> but the sticking point so far has been the subtrees
> produced by fold-constants and gen-const-list;
> theyre not getting visited by finalize_op,
> (despite being attached to the larger tree?)
I just tried single-stepping through Perl_finalize_optree for
perl -e'exit 1+2'
which has the following constant-folded optree:
5 <@> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 1 -e:1) v:{ ->3
4 <1> exit vK/1 ->5
3 <$> const[IV 3] s/FOLD ->4
and S_finalize_op() was called with that const[IV 3] op as its arg.
So I'm not sure why it isn't for you.
> If this is all crazytalk, I'll delete the branch and shut up.
It would seem to be heading in that direction I'm afraid.
--
A problem shared is a problem doubled.
Thread Previous
|
Thread Next