[PATCH] D69916: [WC] Fix a subtle bug in our definition of widenable branch

[Philip Reames via Phabricator via llvm-commits]

reames created this revision.
reames added reviewers: apilipenko, fedor.sergeev, ebrevnov.
Herald added subscribers: bollu, hiraditya, mcrosier.
Herald added a project: LLVM.

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.


Repository:
  rL LLVM

https://reviews.llvm.org/D69916

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D69916.228120.patch
Type: text/x-patch
Size: 11886 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20191106/0268bf5d/attachment.bin>