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:
demerphq
Date:
July 12, 2010 04:40
Subject:
Re: [perl #76438] peephole optimiser could prune more dead code
Message ID:
AANLkTikuv7dowEyX1OWpu24EUER9hZeGRHisfv8p_Jjy@mail.gmail.com
On 12 July 2010 13:36, demerphq <demerphq@gmail.com> wrote:
> On 12 July 2010 13:07, David Golden <xdaveg@gmail.com> wrote:
>> On Mon, Jul 12, 2010 at 12:51 AM, Eric Brine <ikegami@adaelis.com> wrote:
>>> On Sun, Jul 11, 2010 at 10:22 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.
>>>
>>> Without that guarantee,
>>>
>>> my $x = f()
>>>    or DEBUG && warn(...);
>>> return $x;
>>>
>>> would be buggy. Dunno if that matters
>>
>> I said "... have side effects when evaluated ..." but your example has
>> a side effect (functional call) in an assignment before the logic
>> expression.  Maybe "evaluated" isn't the right term, but I was
>> intending it to mean the action of reading a value from a variable.
>
> I think this is close to something i mentioned.
>
> My thought was: given that
>
> $b=$a++ + $a++;
>
> is not defined, that we could also assume that changing fetch magic
> inside of fetch magic would only take effect after that statement
> concluded, and thus
>
> $b=$a + $a;
>
> where $a is tied/overloaded and the magic changes on invocation of the
> fetch is also undefined.

Gah. That came out all wrong.

I mean: given that $b=$a++ + $a++; is undefined, that is that an
expression using a mutator on a variable mentioned twice is undefined,
it seems to me that we can also consider a whole whack of fetch magic
to also be undefined.

> Thus we could check for magic at the beginning of the expression, and
> then cache it for the duration, although we would guarantee that the
> magic WAS called twice if there was magic.
>
> But the problem with any of these changes is that it could/would break
> stuff somewhere. Which is why i figured some kind of compiler hint was
> in order, as it would mean that new code could be optimised relatively
> sanely and old code would continue on unbroken.
>

Cheers,
yves

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

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