Do any languages make evaluation of the right-hand of an "AND" operation optional?

Question

The C# language has two "AND" operators when dealing with Boolean values, & and &&. (Leaving aside the bit-wise operators.)

When the left-hand value is False, the difference between these two operators regards the evaluation of the right operand.

Consider (false && x) vs (false & x)
&& means the right hand side must not be evaluated.
& means the right hand side must be evaluated.

Decades ago, you'd always use the equivalent of && because it would avoid spending the time uselessly processing that right-hand-side when we already know the answer. In this day and age however, we have CPUs that are already processing the next line of code before the previous line has finished. This has to come to a stop when a branch is reached, so you might want to use & to avoid that branch in the code and allow the CPU to speed ahead unimpeded.

(Two quick side-bars: Sometimes, you need to use && because the left hand side protects against unwanted side effects of the right hand side, such as checking NULL to avoid a null-reference error. I'll also acknowledge that the compiler may be smart enough to sometimes know that the right-hand of a && operation is side-effect-free so it can eliminate the branch instruction. These are beyond the scope of this question.)

So there's the background, here's my question.

Are there any languages or environments that have established a compromise between && and & that leave it up to the compiler/run-time to decide if the right-hand side needs to be evaluated?

Given a AND b, the programmer would be saying that the compiler/run-time may evaluate b if a branch is too costly, but is also explicitly permitted to branch around the work of evaluating b if doing so would be greater than the work of the branch instruction.

Answer 1

There are languages like Haskell which make very little guarantees about evaluation. Haskell only guarantees that evaluation is non-strict, i.e. that

f a b = b
f undefined 2

evaluates to 2. That is pretty much everything Haskell guarantees. Any (sub-)expression may be evaluated any number of times (or never).

However, languages which do this are usually pure, which means that you cannot actually tell how often any particular (sub-)expression was evaluated.

This is also done in some superscalar or parallel CPUs, where the condition of a branch may depend on some data that is computed by some other (part of the) CPU and isn't available yet, and instead of stalling the pipeline, the CPU will execute both branches and simply throw away one of two execution strands as soon as the condition becomes available. This is called speculative execution.

An extremely aggressive implementation of this is found in Intel's Itanium CPUs, which may on some benchmarks throw away up to 80% of results. (This is one of the reasons they are so power hungry, after all, this means that it produces 5 times more heat than necessary to compute the result.)