[all-commits] [llvm/llvm-project] 70c68a: [NFC] Factor out utilities for manipulating widena...

[Philip Reames via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 70c68a6b0e515967dba5b30f6a60e220a8cd8d2c
      https://github.com/llvm/llvm-project/commit/70c68a6b0e515967dba5b30f6a60e220a8cd8d2c
  Author: Philip Reames <listmail at philipreames.com>
  Date:   2019-11-19 (Tue, 19 Nov 2019)

  Changed paths:
    M llvm/include/llvm/Analysis/GuardUtils.h
    M llvm/include/llvm/Transforms/Utils/GuardUtils.h
    M llvm/lib/Analysis/GuardUtils.cpp
    M llvm/lib/Transforms/Scalar/GuardWidening.cpp
    M llvm/lib/Transforms/Scalar/LoopPredication.cpp
    M llvm/lib/Transforms/Utils/GuardUtils.cpp

  Log Message:
  -----------
  [NFC] Factor out utilities for manipulating widenable branches

With the widenable condition construct, we have the ability to reason about branches which can be 'widened' (i.e. made to fail more often).  We've got a couple o transforms which leverage this.  This patch just cleans up the API a bit.

This is prep work for generalizing our definition of a widenable branch slightly.  At the moment "br i1 (and A, wc()), ..." is considered widenable, but oddly, neither "br i1 (and wc(), B), ..." or "br i1 wc(), ..." is.  That clearly needs addressed, so first, let's centralize the code in one place.