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 12, 2010 04:36
Re: [perl #76438] peephole optimiser could prune more dead code
Message ID:
On 12 July 2010 13:07, David Golden <> wrote:
> On Mon, Jul 12, 2010 at 12:51 AM, Eric Brine <> wrote:
>> On Sun, Jul 11, 2010 at 10:22 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.
>> 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.

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.


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