[llvm-dev] Evaluation order of short-circuited comparisons

[Marius Hillenbrand via llvm-dev]

Hi,

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
happen.

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
https://bugs.llvm.org/show_bug.cgi?id=48529).

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)?

Marius
-- 
Marius Hillenbrand
Linux on Z development
IBM Deutschland Research & Development GmbH
Vors. des Aufsichtsrats: Gregor Pillen / Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart, HRB 243294