[all-commits] [llvm/llvm-project] 686f44: [WC] Fix a subtle bug in our definition of widenab...

[Philip Reames via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 686f449e3d4ecad6413427aef35557f5adac100c
      https://github.com/llvm/llvm-project/commit/686f449e3d4ecad6413427aef35557f5adac100c
  Author: Philip Reames <listmail at philipreames.com>
  Date:   2019-11-06 (Wed, 06 Nov 2019)

  Changed paths:
    M llvm/lib/Analysis/GuardUtils.cpp
    M llvm/lib/Transforms/Scalar/GuardWidening.cpp
    M llvm/lib/Transforms/Scalar/LoopPredication.cpp
    M llvm/test/Transforms/GuardWidening/basic_widenable_condition_guards.ll
    M llvm/test/Transforms/GuardWidening/mixed_guards.ll
    M llvm/test/Transforms/SimplifyCFG/wc-widen-block.ll

  Log Message:
  -----------
  [WC] Fix a subtle bug in our definition of widenable branch

We had a subtle, but nasty bug in our definition of a widenable branch, and thus in the transforms which used that utility. Specifically, we returned true for any branch which included a widenable condition within it's condition, regardless of whether that widenable condition also had other uses.

The problem is that the result of the WC() call is defined to be one particular value. As such, all users must agree as to what that value is. If we widen a branch without also updating *all other users* of the WC in the same way, we have broken the required semantics.

Most of the textual diff is updating existing transforms not to leave dead uses hanging around. They're largely NFC as the dead instructions would be immediately deleted by other passes. The reason to make these changes is so that the transforms preserve the widenable branch form.

In practice, we don't get bitten by this only because it isn't profitable to CSE WC() calls and the lowering pass from guards uses distinct WC calls per branch.

Differential Revision: https://reviews.llvm.org/D69916