[all-commits] [llvm/llvm-project] dd48a9: [ValueTracking] Handle conflicts when computing kn...

goldsteinn via All-commits all-commits at lists.llvm.org
Fri Sep 1 00:12:22 PDT 2023


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: dd48a9b0561cc65b8597d618f8b286682866c66d
      https://github.com/llvm/llvm-project/commit/dd48a9b0561cc65b8597d618f8b286682866c66d
  Author: Noah Goldstein <goldstein.w.n at gmail.com>
  Date:   2023-09-01 (Fri, 01 Sep 2023)

  Changed paths:
    M llvm/lib/Analysis/ValueTracking.cpp
    A llvm/test/Analysis/ValueTracking/knownbits-phi-deadcode.ll

  Log Message:
  -----------
  [ValueTracking] Handle conflicts when computing knownbits of PHI nodes in deadcode; PR65022

Bug was introduced in: https://reviews.llvm.org/D157807

The prior logic assumed that the information from the knownbits
returned from analyzing the `icmp` and its operands in the context
basicblock would be consistent.

This is not necessarily the case if we are analyzing deadcode.

For example with `(icmp sgt (select cond, 0, 1), -1)`. If we take
knownbits for the `select` using knownbits from the operator, we will
know the signbit is zero. If we are analyzing a not-taken from based
on the `icmp` (deadcode), we will also "know" that the `select` must
be negative (signbit is one). This will result in a conflict in
knownbits.

The fix is to just give up on analying the phi-node if its deadcode. We 1) don't want to waste time continuing to analyze it and 2) will be removing it (and its dependencies) later.

Reviewed By: nikic

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




More information about the All-commits mailing list