Re: Should multideref be disabled if OP_EXISTS/OP_DELETE custom checkfunctions are set?

Le 27/04/2015 09:31, Dave Mitchell a écrit :
> 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
>

Ok, then I'll change it when 5.22 is released.


Vincent

• 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