Front page | perl.perl5.porters |
Postings from July 2010
2010/7/12 David Golden <xdaveg@gmail.com>:
> On Sun, Jul 11, 2010 at 5:58 PM, Joshua ben Jore <twists@gmail.com> wrote:
>> On Sun, Jul 11, 2010 at 2:56 PM, Eric Brine <ikegami@adaelis.com> wrote:
>>> On Sun, Jul 11, 2010 at 3:40 PM, David Golden <xdaveg@gmail.com> 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
pp_hot:pp_gvsv
if (PL_op->op_private & OPpLVAL_INTRO)
PUSHs(save_scalar(cGVOP_gv));
else
PUSHs(GvSV(cGVOP_gv));
RETURN;
> 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) { ... }
=>
$a
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
defragmented
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.
--
Reini
Thread Previous
|
Thread Next