[all-commits] [llvm/llvm-project] 08d153: [ValueTracking] computeKnownBits - attempt to use ...

[Simon Pilgrim via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 08d153d806b500a3d819bbc57d8c4ddcb568f26e
      https://github.com/llvm/llvm-project/commit/08d153d806b500a3d819bbc57d8c4ddcb568f26e
  Author: Simon Pilgrim <llvm-dev at redking.me.uk>
  Date:   2022-08-16 (Tue, 16 Aug 2022)

  Changed paths:
    M llvm/lib/Analysis/ValueTracking.cpp
    M llvm/test/Transforms/InstCombine/known-phi-br.ll
    M llvm/test/Transforms/InstCombine/remove-loop-phi-fastmul.ll
    M llvm/test/Transforms/PhaseOrdering/X86/pr38280.ll

  Log Message:
  -----------
  [ValueTracking] computeKnownBits - attempt to use a branch condition feeding a phi to improve known bits range (PR38280)

If computeKnownBits encounters a phi node, and we fail to determine any known bits through direct analysis, see if the incoming value is part of a branch condition feeding the phi.

Handle cases where icmp(IncomingValue PRED Constant) is driving a branch instruction feeding that phi node - at the moment this only handles EQ/ULT/ULE predicate cases as they are the most straightforward to handle and most likely for branch-loop 'max upper bound' cases - we can extend this if/when necessary.

I investigated a more general icmp(LHS PRED RHS) KnownBits system, but the hard limits we put on value tracking depth through phi nodes meant that we were mainly catching constants anyhow.

Fixes the pointless vectorization in PR38280 / Issue #37628 (excessive unrolling still needs handling though)

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