develooper Front page | perl.perl5.porters | Postings from March 2015


Thread Previous | Thread Next
Steffen Mueller
March 10, 2015 19:56
Message ID:
On 03/10/2015 07:53 PM, Dave Mitchell wrote:
> Ok everyone, how about this compromise proposal:
> I'm thinking in terms of accommodating the suggestion that the 'pre-peep'
> API should be 'firmer' than the post-peep API, with funky ops like
> OP_SIGNATURE only emitted at the peephole stage.

I think that if we want to pretend that the OP tree is an AST (which 
would be the natural conclusion of considering pre-peep a firmer API of 
sorts), we're over a decade too late.

If we seriously want an AST, we should add an AST stage. Exercise left 
to the readers that actually NEED it[1].

> Suppose we create some new "API" ops, whose individual actions are short
> and constrained, and typically act on only a single parameter. Things
> along the lines of what was suggested earlier, e.g. ops to check the arity
> of @_, assign an arg with an integer default, slurp an array etc. (exact
> details of the ops still to be designed).
> The signature parsing code in Perl_parse_subsignature() would emit these
> intermediate-level ops, rather than the low-level ops of the existing
> implementation or the high-level OP_SIGNATURE op of my branch.
> Since such ops will be generally emitted per param (with the exception of
> checkarity), that still allows a hypothetical sig parser hook to be be
> called at the param level rather than the sig level.
> Once the peephole optimiser is called, if it sees a series of these
> mid-level ops that conform to something OP_SIGNATURE can handle more
> efficiently, it replaces them with a single OP_SIGNATURE op. Similarly,
> a series of lower-level ops that look like my (...) = @_ get replaced
> with a single OP_SIGNATURE.

To be honest, I think this adds more complexity than it's worth.

[snip considerations]

> This op scheme might preclude a later option of skipping setting up and
> breaking down @_. This is a considerable part of the overhead of
> pp_entersub / pp_leavesub, and I could envisage (either specified by new
> syntax, or by fiat) situations where we would like to enter the sub with
> the args still on the stack rather than being put into @_.  With
> OP_SIGNATURE,handling this would be trivial.

The considerations in this last paragraph are important, IMO. Dave's 
work already gives us a huge speed-up for function calls. I'm honestly 
flabbergasted that people aren't dancing naked on tables in celebration 
over that to begin with. ON TOP OF THAT, we could shave off a bunch of 
extra work by avoiding @_ construction. I had discussed that whole topic 
with Dave, and one of the reasons why he went for OP_SIGNATURE first was 
because he deemed it mostly uncontroversial[2].

> I've also given a lot of thought to whether OP_SIGNATURE can be used in
> places other than at the start of the sub, and whether it could use arrays
> other than @_.  I've come to the conclusion that it can't.  The basic
> issue is that if OP_SIGNATURE is expanded to handle all the extra cases
> that pp_aassign() etc handles (such as @slurpy not being empty, @_ being
> tied, common vars on both side etc - see my recent OPpASSIGN_COMMON
> thread) then it will become as slow and bloated as pp_aassign(), which I
> note, compiles to more than twice the size of pp_signature().
> This is not to say that OP_SIGNATURE must be exactly positioned as
> CvSTART(cv)->op_next and CvROOT(cv)->op_first->op_first->op_sibling
> in the op-tree (I intend to fix Deparse to not assume this), but that any
> code which is injected ahead of the op must be very limited in what it
> does (e.g. not calling a closure that populates any of the param
> lexicals). In fact I would assume that the peepholer would avoid
> converting to OP_SIGNATURE unless the candidate code *was* at the start of
> the sub.
> But note that this just means that hooks etc that mess with the start of
> the sub's optree just causes OP_SIGNATURE generation to be skipped (rather
> than OP_SIGNATURE precluding hooks).


I'd like to propose to go one step further: Rather than by default 
creating hooks for everything at any cost, we should wait with adding 
hooks for a significant use case. YAGNI. I do understand that it's not 
always easy to retrofit hooks. But a little bit of "we'll try to not 
make it extra hard" can probably go a long ways towards being able to 
retrofit them WHERE SENSIBLE without too much pain.

> I hope that this post demonstrates that various strawmen written about me
> are false; specifically:

I think those claims were ludicrous to begin with. But I really hope 
that matters not.

--Steffen, speaking only for himself

[1] I'd like to point to Perl::JIT at as 
at least an interesting exercise in constructing something much closer 
to an AST from the information that's present in the POST PEEP OP tree. 
It was a bunch of work, but MOSTLY a SMOP.

[2] I suppose hoping for anything to not be controversial here is 
getting less and less viable.

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