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

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

Thread Previous | Thread Next
Reini Urban
July 12, 2010 09:06
Re: [perl #76438] peephole optimiser could prune more dead code
Message ID:
2010/7/12 David Golden <>:
> On Sun, Jul 11, 2010 at 5:58 PM, Joshua ben Jore <> wrote:
>> On Sun, Jul 11, 2010 at 2:56 PM, Eric Brine <> wrote:
>>> On Sun, Jul 11, 2010 at 3:40 PM, David Golden <> wrote:
> I'm suggesting that we disclaim any implicit guarantee that the
> compiler won't optimize away expressions that have side effects when
> evaluated.
> Whether any particular optimization is "worth it" is open for later
> debate, but at least the door would be open.

That's not the point.
Even with sideeffects from mg_get we can optimize this conditional
to $a only.

 perl -MO=Concise,-exec -e'$a and "cmp" eq "cc"'
1  <0> enter
2  <;> nextstate(main 1 -e:1) v:{
3  <#> gvsv[*a] s
4  <|> and(other->5) vK/1
5  <@> leave[1 ref] vKP/REFC

can be optimized to
perl -MO=Concise,-exec -e'$a'
1  <0> enter
2  <;> nextstate(main 1 -e:1) v:{
3  <#> gvsv[*a] s
4  <@> leave[1 ref] vKP/REFC

gvsv is just checking magic and doing the sideeffect, and there would
be no better op to cut through that.

So the question if we should assert for less magic is bogus, as gvsv
is doing the needed run.time check super cheap.
We could gain a little if we know about the lvalue context, to get rid of
if (PL_op->op_private & OPpLVAL_INTRO)

> Notwithstanding that Nicholas points out that this example isn't what
> he was talking about, the question that has been raised is whether we
> could just short-circuit an *entire* logical operation if "static"
> analysis can determine whether it is true or false.
> Effectively:
>    if ($a && 0) { ... } # could be optimized away entirely

Not entirely.
The pp_and the {} block could be optimized away to gvsv $a - for the get magic.

if ($a && 0) { ... }

This would nullify a lot of ops if the {} block is large, where we
would come to a state
where copying this part of the optree to exec order and running the
tree without null ops would be actually faster then nullify it at
compile-time and running
the nullified original tree at run-time.
This could be known in advance in the optimizer by some heuristic,
when the cost of compile-time defragmentation is less than nullifiying
and skipping the null ops.

Bad that the optimizer module needs some core support. op_seq is gone.
But I can try that in the XS first.

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