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

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

Thread Previous | Thread Next
From:
David Golden
Date:
July 11, 2010 19:22
Subject:
Re: [perl #76438] peephole optimiser could prune more dead code
Message ID:
AANLkTin-t_MUWMBDaL8M8e1j_Krvt30xoNkSgkPmaNVl@mail.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:
>>
>>> Then maybe we could use the less pragma when that isn't desired.  (
>>> e.g. "use less 'optimization'"
>>>
>>
>> Sounds great to me, except there are backward compatibility issues to
>> defaulting to aggressive optimisation.
>
> Sounds like you want some instrumentation for where your magic is
> actually happening at.

(Insert xdg rant on backwards compatibility)

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.

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

I don't know how much code *relies* on something like $a being tied
and getting evaluated first in a logic operation.  Likewise, I don't
know how much code actually relies on something like C<< && 0 >>.  The
only thing that comes to mind is C<< && DEBUG >> where DEBUG is a
constant.

    warn "..." if $something && DEBUG;

-- David

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About