[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