Re: Should multideref be disabled if OP_EXISTS/OP_DELETE customcheck functions are set?

On Sat, Apr 25, 2015 at 10:13:54PM -0300, Vincent Pit (VPIT) wrote:
> While porting autovivification.pm to the new multideref optimization, I
> realized that while the module was loaded the OP_MULTIDEREF ops were
> actually pretty rare :
[snip]
> 
> Basically, they only happen for exists and delete constructs, and just for
> the last dereferencing. What causes this is this conditional in
> S_maybe_multideref() :
> 
>             /* if something like arybase (a.k.a $[ ) is in scope,
>              * abandon optimisation attempt */
>             if (  (o->op_type == OP_AELEM || o->op_type == OP_HELEM)
>                && PL_check[o->op_type] != Perl_ck_null)
>                 return;
> 
> This makes a lot of sense, but I wonder if this shouldn't be extended to
> topmost OP_EXISTS and OP_DELETE, so that the multideref optimization is also
> disabled when they define their own check functions.

Sounds like a good idea, although I'd prefer to leave it until after 5.22

-- 
My Dad used to say 'always fight fire with fire', which is probably why
he got thrown out of the fire brigade.

• Should multideref be disabled if OP_EXISTS/OP_DELETE custom checkfunctions are set? by perl
• Re: Should multideref be disabled if OP_EXISTS/OP_DELETE customcheck functions are set? by Dave Mitchell
• Re: Should multideref be disabled if OP_EXISTS/OP_DELETE custom checkfunctions are set? by perl
• Re: Should multideref be disabled if OP_EXISTS/OP_DELETE customcheck functions are set? by Dave Mitchell