develooper Front page | perl.perl5.porters | Postings from December 2017

make PERL_OP_PARENT compulsory?

Thread Next
Dave Mitchell
December 15, 2017 14:26
make PERL_OP_PARENT compulsory?
Message ID:
I propose for 5.28.0 that we remove the ability to disable
the PERL_OP_PARENT build option (currently on by default).


In the optree, the children of an op are connected in a linked list
formed using the op_sibling fields of the ops.

Prior to 5.22, the last sibling was was indicated by a NULL op_sibling

5.22.0 introduced a new build define, PERL_OP_PARENT (not enabled by
default), which instead indicated the last op using a flag bit, and freed
up the last op_sibling field to use as a pointer back to the parent op.
This is useful for code which examines and manipulates optrees, as
previously there was no easy way go up the tree from the current op.

5.26.0 enabled PERL_OP_PARENT by default, and introduced a PERL_NO_OP_PARENT
build option to allow it to be disabled.

Currently we can't make any significant use of the parent pointer in core,
since we can't guarantee that it will be present.

So I would like to remove the ability to disable it.

For 5.27.7+, this would involve changing these lines in perl.h:

    /* enable PERL_OP_PARENT by default */
    #if !defined(PERL_OP_PARENT) && !defined(PERL_NO_OP_PARENT)
    #  define PERL_OP_PARENT

to just 

    #if !defined(PERL_OP_PARENT)
    #  define PERL_OP_PARENT

then sometime early in 5.29.*, remove all use of PERL_OP_PARENT from the
source and start making use of the parent pointer.

For example, the recursive tree walks currently done during compilation
can blow the C stack: this SEGVs:

    eval join '+', ('$a') x 100_000;

these walks could be made non-recursive if after visiting the deepest
child we can find the parent and continue the walk.

"Emacs isn't a bad OS once you get used to it.
It just lacks a decent editor."

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