Evaluation order of short-circuited comparisons


What is the intention in LLVM for the evaluation order of
short-circuited comparisons?

In Reassociate, a check aims to leave such comparisons untouched and a
comment states that their evaluation order should be preserved as in the
source (added by 27dfb1e1a4e6). Is that still the intention? If yes,
then df8f2a23cbaf introduced a bug that can cause such reorderings to

Specifically, clang lowers the comparisons to control flow, then
SimplifyCFG folds these to AND or OR expressions, and CodeGen may lower
them back to control flow. Reassociate could reorder the operands of the
AND/OR before a check a few lines later identifies them as boolean
expression that should be left alone. As a result, the resulting control
flow in machine code would perform the comparisons in an accidentally
changed order (see the example in

Would/should LLVM deliberately reorder such comparisons in other passes
if it has information about their probabilities (and there are no side
effects to consider)?