[all-commits] [llvm/llvm-project] aca335: [ValueTracking] Let analyses assume a value cannot...
Juneyoung Lee via All-commits
all-commits at lists.llvm.org
Wed Apr 22 16:09:12 PDT 2020
Branch: refs/heads/master
Home: https://github.com/llvm/llvm-project
Commit: aca335955c0dfe5dc783bf21e1d883c1aae33abc
https://github.com/llvm/llvm-project/commit/aca335955c0dfe5dc783bf21e1d883c1aae33abc
Author: Juneyoung Lee <aqjune at gmail.com>
Date: 2020-04-23 (Thu, 23 Apr 2020)
Changed paths:
M llvm/include/llvm/Analysis/ValueTracking.h
M llvm/lib/Analysis/ScalarEvolution.cpp
M llvm/lib/Analysis/ValueTracking.cpp
M llvm/lib/Transforms/Instrumentation/PoisonChecking.cpp
M llvm/lib/Transforms/Scalar/IndVarSimplify.cpp
M llvm/lib/Transforms/Scalar/SeparateConstOffsetFromGEP.cpp
M llvm/test/Analysis/ScalarEvolution/flags-from-poison.ll
Log Message:
-----------
[ValueTracking] Let analyses assume a value cannot be partially poison
Summary:
This is RFC for fixes in poison-related functions of ValueTracking.
These functions assume that a value can be poison bitwisely, but the semantics
of bitwise poison is not clear at the moment.
Allowing a value to have bitwise poison adds complexity to reasoning about
correctness of optimizations.
This patch makes the analysis functions simply assume that a value is
either fully poison or not, which has been used to understand the correctness
of a few previous optimizations.
The bitwise poison semantics seems to be only used by these functions as well.
In terms of implementation, using value-wise poison concept makes existing
functions do more precise analysis, which is what this patch contains.
Reviewers: spatel, lebedev.ri, jdoerfert, reames, nikic, nlopes, regehr
Reviewed By: nikic
Subscribers: fhahn, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78503
More information about the All-commits
mailing list