Front page | perl.perl5.porters |
Postings from December 2021
On Sat, 4 Dec 2021 14:16:37 +0000
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:
> My plan is to create two new .c files to contain subsections of what
> is currently in op.c:
>
> peep.c: to contain the finalizer and peephole optimiser
I now have an (as-yet unpushed) branch which does this part; it doesn't
seem too bad. I had to make a few static functions into internal API,
but that didn't seem too bad.
Sizes now:
> ck.c: to contain the opchecker functions (Perl_ck_*)
This part seems like it might go roughly the same way, requiring some
more currently-static functions to be exposed. But here I find more of
a question: it's intended that custom operators can provide their own
opchecker functions. Several of the currently-static functions used by
existing opcheckers feel like they would be useful to custom checkers
too. Perhaps for at least some of these, a case might be made to make
them exposed API so that custom ops can use them too?
All the functions needed are:
new_entersubop
modkids
set_has_eval
op_varname_subscript [I already partly exposed op_varname as part of
the peephole optimiser change]
op_sibling_newUNOP
handle_constructor
scalarkids
force_list
ref_array_or_hash
newONCEOP
fold_constants
op_integerize
op_std_init
If (some of) these became public API that would help move the
opcheckers to their own file, as well as allowing custom code in CPAN
modules to make use of them as well.
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Thread Previous
|
Thread Next