The optimizing behaviour further suggests that it's possible that ($var || 2) can evaluate as false - otherwise I would expect that (at least) the else{} would be optimized away.

You're giving the optimiser too much credit.

(I think; on the basis of the behaviour I've observed rather than analysis of the code) the optimiser has a relatively simple rule: if a conditional expression is a simple compile-time constant, it will optimise away any code that will never be reached as a result. Full stop.

It doesn't make any attempt to reduce a non-simple expression to a simple one:

$x = 1; if( $x ) { } else { }
^Z
$x = 1;
if ($x) {
    ();
}
else {
    ();
}
- syntax OK
[download]

Even:

C:\Users\HomeAdmin>perl -MO=Deparse
my $x = 1; if($x, 1){ } else{ }
^Z
my $x = 1;
if ($x, 1) {
    ();
}
else {
    ();
}
- syntax OK
[download]

Given that both branches of the if are empty; both of those ought to be reduced to just:$x;, just to cover the tied var side-effect case.

I think that the reality is not "the optimiser", but rather "a few, simple, optimisations".

There are hundreds of possibilities for compile time optimisations, but whilst the structure and formatting of the code remains so messy; it takes brave men to venture there looking for them.

You're giving the optimiser too much credit

Ok ... and I'm somewhat relieved about that :-)
But can ($var || 2) ever be false ?

The code provided initially by the OP was:

if ($var || 2) {
    # do stuff here
}
else {
    # won't do stuff 
}
[download]

If ($var || 2) is inevitably true, then that code is a rather silly (even obfuscating) construct.
All that was really needed was:

$var || 2;
# do stuff here
[download]

or simply:

$var;
# do stuff here
[download]

Is it safe for the OP to make such alterations, or do I overlook something ?
Afterthought: I'm actually now wondering whether the original code was in fact ($var | 2) and not ($var || 2)

Cheers,
Rob

Nope, but a method of a tied variable could raise an exception or goto label.

A tied variable could also have side effects, like logging each access.

IOW the FETCH can't be short circuited, even if the result is of no interest.

Anyway optimizer rules are very simplistic, and if wanted such exotic edge cases could be forbidden in documentation.

Tied variables are hell for any optimizer, I remember a talk of Reini Urban in Kiev where he presented details of his optimizer with factor 2 speed gain. I was so puzzled how one technique works and asked how this can handle tied variables.

His answer was simple: tied variables are not allowed! :)

Anyway JS shows that JIT compiling is the way to go.

(NB no tied vars in ECMA JS)

update

There are several cases where optimization already causes strange effects.

For instance try to goto into a code chunk which is optimized away with 'if(0)'