develooper Front page | perl.perl5.porters | Postings from July 2010

Re: [perl #76438] peephole optimiser could prune more dead code

Thread Previous | Thread Next
July 10, 2010 07:17
Re: [perl #76438] peephole optimiser could prune more dead code
Message ID:
On 10 July 2010 13:36, James Mastros <> wrote:
> On 9 July 2010 16:56, Nicholas Clark <> wrote:
>> $ ./perl -Ilib -MO=Deparse -e 'if ("Pie" eq "Good") {print}'
>> '???';
>> -e syntax OK
>> but
>> $ ./perl -Ilib -MO=Deparse -e 'if ($a && "Pie" eq "Good") {print}'
>> if ($a and !1) {
>>    print $_;
>> }
>> -e syntax OK
>> which demonstrates that "Pie" eq "Good" is constant folded, but that the
>> optree for the block still exists.
>> The peephole optimiser is correct not to optimise this to nothing, as it
>> can't know that $a is neither tied nor overloaded, so cannot assume that
>> the lookup of $a has no side effects.
>> However, it can know that the conditional to the if block is always false,
>> and so could optimise away the ops for the block, freeing up their memory.
>> Hence the code should become
>>    $a and !1;
>> or even the perl equivalent of
>>    (void) (bool) $a;
>> Wishlist, because I've no idea how much real world perl code ends up with
>> constructions like this, and would benefit
> I do wonder, sometimes, if we worry entirely too much about just when
> tie and overload calls or done.  Would it break actual real-world code
> to not retrieve the value of $a (tie) or not boolify it (overload)
> when the value will be thrown away anyway?  Clearly, we can't do this
> in a maintance release, but perhaps we should add warnings that we are
> planning on doing it to 5.14.0?  It seems to me that doing this would
> allow all sorts of optimizations that we currently think of, and then
> say "that'd change overloading", and throw out, with very little
> impact on real-world code, which either doesn't use overloading, or
> would be happy if overloading were made faster by avoiding it where
> possible.

This came up in another thread. JIT compilation techniques combined
with smaller less generic ops would give us the opportunity to rewrite
this as a more efficient structure.

I also proposed a "no magic" pragma/syntax that would allow the
optimiser to assume that all variables were "normal", and that funky
stuff wasnt going to occur during the scope of the pragma. And in such
a block i would expect this to block to be optimised away.


perl -Mre=debug -e "/just|another|perl|hacker/"

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