[all-commits] [llvm/llvm-project] 5cdf6e: [CodeGen] recognize select form of and/ors when sp...
Juneyoung Lee via All-commits
all-commits at lists.llvm.org
Thu Dec 31 11:55:45 PST 2020
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: 5cdf6ed744896a23ebc3f723ee2abcfc88137da0
https://github.com/llvm/llvm-project/commit/5cdf6ed744896a23ebc3f723ee2abcfc88137da0
Author: Juneyoung Lee <aqjune at gmail.com>
Date: 2021-01-01 (Fri, 01 Jan 2021)
Changed paths:
M llvm/lib/CodeGen/CodeGenPrepare.cpp
M llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
M llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
M llvm/test/CodeGen/AArch64/GlobalISel/irtranslator-condbr-lower-tree.ll
M llvm/test/CodeGen/AArch64/arm64_32.ll
M llvm/test/CodeGen/AArch64/fast-isel-branch-cond-split.ll
Log Message:
-----------
[CodeGen] recognize select form of and/ors when splitting branch conditions
Recently a few patches are made to move towards using select i1 instead of and/or i1 to represent "a && b"/"a || b" in C/C++.
"a && b" in C/C++ does not evaluate b if a is false whereas 'and a, b' in IR evaluates b and uses its result regardless of the result of a.
This is problematic because it can cause miscompilation if b was an erroneous operation (https://llvm.org/pr48353).
In C/C++, the result is simply false because b is not evaluated, but in IR the result is poison.
The discussion at D93065 has more context about this.
This patch makes two branch-splitting optimizations (one in SelectionDAGBuilder, one in CodeGenPrepare) recognize
select form of and/or as well using m_LogicalAnd/Or.
Since it is CodeGen, I think this is semantically ok (at least as safe as what codegen already did).
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D93853
More information about the All-commits
mailing list