[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