2014-11-21 19:58:23 +01:00
|
|
|
//===- LazyValueInfo.cpp - Value constraint analysis ------------*- C++ -*-===//
|
2009-11-11 01:22:30 +01:00
|
|
|
//
|
2019-01-19 09:50:56 +01:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2009-11-11 01:22:30 +01:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file defines the interface for lazy computation of value constraint
|
|
|
|
// information.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "llvm/Analysis/LazyValueInfo.h"
|
2012-12-03 17:50:05 +01:00
|
|
|
#include "llvm/ADT/DenseSet.h"
|
2018-11-21 06:24:12 +01:00
|
|
|
#include "llvm/ADT/Optional.h"
|
2012-12-03 17:50:05 +01:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2016-12-19 09:22:17 +01:00
|
|
|
#include "llvm/Analysis/AssumptionCache.h"
|
2012-12-03 17:50:05 +01:00
|
|
|
#include "llvm/Analysis/ConstantFolding.h"
|
2017-08-03 23:11:30 +02:00
|
|
|
#include "llvm/Analysis/InstructionSimplify.h"
|
2015-01-15 03:16:27 +01:00
|
|
|
#include "llvm/Analysis/TargetLibraryInfo.h"
|
2017-09-28 13:09:22 +02:00
|
|
|
#include "llvm/Analysis/ValueLattice.h"
|
Sink all InitializePasses.h includes
This file lists every pass in LLVM, and is included by Pass.h, which is
very popular. Every time we add, remove, or rename a pass in LLVM, it
caused lots of recompilation.
I found this fact by looking at this table, which is sorted by the
number of times a file was changed over the last 100,000 git commits
multiplied by the number of object files that depend on it in the
current checkout:
recompiles touches affected_files header
342380 95 3604 llvm/include/llvm/ADT/STLExtras.h
314730 234 1345 llvm/include/llvm/InitializePasses.h
307036 118 2602 llvm/include/llvm/ADT/APInt.h
213049 59 3611 llvm/include/llvm/Support/MathExtras.h
170422 47 3626 llvm/include/llvm/Support/Compiler.h
162225 45 3605 llvm/include/llvm/ADT/Optional.h
158319 63 2513 llvm/include/llvm/ADT/Triple.h
140322 39 3598 llvm/include/llvm/ADT/StringRef.h
137647 59 2333 llvm/include/llvm/Support/Error.h
131619 73 1803 llvm/include/llvm/Support/FileSystem.h
Before this change, touching InitializePasses.h would cause 1345 files
to recompile. After this change, touching it only causes 550 compiles in
an incremental rebuild.
Reviewers: bkramer, asbirlea, bollu, jdoerfert
Differential Revision: https://reviews.llvm.org/D70211
2019-11-13 22:15:01 +01:00
|
|
|
#include "llvm/Analysis/ValueTracking.h"
|
2017-03-22 20:27:12 +01:00
|
|
|
#include "llvm/IR/AssemblyAnnotationWriter.h"
|
2014-03-04 12:45:46 +01:00
|
|
|
#include "llvm/IR/CFG.h"
|
2014-03-04 13:24:34 +01:00
|
|
|
#include "llvm/IR/ConstantRange.h"
|
2013-01-02 12:36:10 +01:00
|
|
|
#include "llvm/IR/Constants.h"
|
|
|
|
#include "llvm/IR/DataLayout.h"
|
2014-09-07 22:29:59 +02:00
|
|
|
#include "llvm/IR/Dominators.h"
|
2013-01-02 12:36:10 +01:00
|
|
|
#include "llvm/IR/Instructions.h"
|
|
|
|
#include "llvm/IR/IntrinsicInst.h"
|
2016-08-12 17:52:23 +02:00
|
|
|
#include "llvm/IR/Intrinsics.h"
|
[LVI/CVP] Teach LVI about range metadata
Somewhat shockingly for an analysis pass which is computing constant ranges, LVI did not understand the ranges provided by range metadata.
As part of this change, I included a change to CVP primarily because doing so made it much easier to write small self contained test cases. CVP was previously only handling the non-local operand case, but given that LVI can sometimes figure out information about instructions standalone, I don't see any reason to restrict this. There could possibly be a compile time impact from this, but I suspect it should be minimal. If anyone has an example which substaintially regresses, please let me know. I could restrict the block local handling to ICmps feeding Terminator instructions if needed.
Note that this patch continues a somewhat bad practice in LVI. In many cases, we know facts about values, and separate context sensitive facts about values. LVI makes no effort to distinguish and will frequently cache the same value fact repeatedly for different contexts. I would like to change this, but that's a large enough change that I want it to go in separately with clear documentation of what's changing. Other examples of this include the non-null handling, and arguments.
As a meta comment: the entire motivation of this change was being able to write smaller (aka reasonable sized) test cases for a future patch teaching LVI about select instructions.
Differential Revision: http://reviews.llvm.org/D13543
llvm-svn: 251606
2015-10-29 04:57:17 +01:00
|
|
|
#include "llvm/IR/LLVMContext.h"
|
2014-03-04 12:08:18 +01:00
|
|
|
#include "llvm/IR/PatternMatch.h"
|
2014-03-04 12:17:44 +01:00
|
|
|
#include "llvm/IR/ValueHandle.h"
|
Sink all InitializePasses.h includes
This file lists every pass in LLVM, and is included by Pass.h, which is
very popular. Every time we add, remove, or rename a pass in LLVM, it
caused lots of recompilation.
I found this fact by looking at this table, which is sorted by the
number of times a file was changed over the last 100,000 git commits
multiplied by the number of object files that depend on it in the
current checkout:
recompiles touches affected_files header
342380 95 3604 llvm/include/llvm/ADT/STLExtras.h
314730 234 1345 llvm/include/llvm/InitializePasses.h
307036 118 2602 llvm/include/llvm/ADT/APInt.h
213049 59 3611 llvm/include/llvm/Support/MathExtras.h
170422 47 3626 llvm/include/llvm/Support/Compiler.h
162225 45 3605 llvm/include/llvm/ADT/Optional.h
158319 63 2513 llvm/include/llvm/ADT/Triple.h
140322 39 3598 llvm/include/llvm/ADT/StringRef.h
137647 59 2333 llvm/include/llvm/Support/Error.h
131619 73 1803 llvm/include/llvm/Support/FileSystem.h
Before this change, touching InitializePasses.h would cause 1345 files
to recompile. After this change, touching it only causes 550 compiles in
an incremental rebuild.
Reviewers: bkramer, asbirlea, bollu, jdoerfert
Differential Revision: https://reviews.llvm.org/D70211
2019-11-13 22:15:01 +01:00
|
|
|
#include "llvm/InitializePasses.h"
|
2009-11-12 02:22:16 +01:00
|
|
|
#include "llvm/Support/Debug.h"
|
2017-03-22 20:27:12 +01:00
|
|
|
#include "llvm/Support/FormattedStream.h"
|
2020-09-20 21:07:52 +02:00
|
|
|
#include "llvm/Support/KnownBits.h"
|
2012-12-03 17:50:05 +01:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2012-01-12 00:43:34 +01:00
|
|
|
#include <map>
|
2009-11-11 01:22:30 +01:00
|
|
|
using namespace llvm;
|
2012-03-02 16:34:43 +01:00
|
|
|
using namespace PatternMatch;
|
2009-11-11 01:22:30 +01:00
|
|
|
|
2014-04-22 04:48:03 +02:00
|
|
|
#define DEBUG_TYPE "lazy-value-info"
|
|
|
|
|
LVI: Add a per-value worklist limit to LazyValueInfo.
Summary:
LVI is now depth first, which is optimal for iteration strategy in
terms of work per call. However, the way the results get cached means
it can still go very badly N^2 or worse right now. The overdefined
cache is per-block, because LVI wants to try to get different results
for the same name in different blocks (IE solve the problem
PredicateInfo solves). This means even if we discover a value is
overdefined after going very deep, it doesn't cache this information,
causing it to end up trying to rediscover it again and again. The
same is true for values along the way. In practice, overdefined
anywhere should mean overdefined everywhere (this is how, for example,
SCCP works).
Until we get around to reworking the overdefined cache, we need to
limit the worklist size we process. Note that permanently reverting
the DFS strategy exploration seems the wrong strategy (temporarily
seems fine if we really want). BFS is clearly the wrong approach, it
just gets luckier on some testcases. It's also very hard to design
an effective throttle for BFS. For DFS, the throttle is directly related
to the depth of the CFG. So really deep CFGs will get cutoff, smaller
ones will not. As the CFG simplifies, you get better results.
In BFS, the limit is it's related to the fan-out times average block size,
which is harder to reason about or make good choices for.
Bug being filed about the overdefined cache, but it will require major
surgery to fix it (plumbing predicateinfo through CVP or LVI).
Note: I did not make this number configurable because i'm not sure
anyone really needs to tweak this knob. We run CVP 3 times. On the
testcases i have the slow ones happen in the middle, where CVP is
doing cleanup work other things are effective at. Over the course of
3 runs, we don't see to have any real loss of performance.
I haven't gotten a minimized testcase yet, but just imagine in your
head a testcase where, going *up* the CFG, you have branches, one of
which leads 50000 blocks deep, and the other, to something where the
answer is overdefined immediately. BFS would discover the overdefined
faster than DFS, but do more work to do so. In practice, the right
answer is "once DFS discovers overdefined for a value, stop trying to
get more info about that value" (and so, DFS would normally cache the
overdefined results for every value it passed through in those 50k
blocks, and never do that work again. But it don't, because of the
naming problem)
Reviewers: chandlerc, djasper
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29715
llvm-svn: 294463
2017-02-08 16:22:52 +01:00
|
|
|
// This is the number of worklist items we will process to try to discover an
|
|
|
|
// answer for a given value.
|
|
|
|
static const unsigned MaxProcessedPerValue = 500;
|
|
|
|
|
2016-06-14 00:01:25 +02:00
|
|
|
char LazyValueInfoWrapperPass::ID = 0;
|
Sink all InitializePasses.h includes
This file lists every pass in LLVM, and is included by Pass.h, which is
very popular. Every time we add, remove, or rename a pass in LLVM, it
caused lots of recompilation.
I found this fact by looking at this table, which is sorted by the
number of times a file was changed over the last 100,000 git commits
multiplied by the number of object files that depend on it in the
current checkout:
recompiles touches affected_files header
342380 95 3604 llvm/include/llvm/ADT/STLExtras.h
314730 234 1345 llvm/include/llvm/InitializePasses.h
307036 118 2602 llvm/include/llvm/ADT/APInt.h
213049 59 3611 llvm/include/llvm/Support/MathExtras.h
170422 47 3626 llvm/include/llvm/Support/Compiler.h
162225 45 3605 llvm/include/llvm/ADT/Optional.h
158319 63 2513 llvm/include/llvm/ADT/Triple.h
140322 39 3598 llvm/include/llvm/ADT/StringRef.h
137647 59 2333 llvm/include/llvm/Support/Error.h
131619 73 1803 llvm/include/llvm/Support/FileSystem.h
Before this change, touching InitializePasses.h would cause 1345 files
to recompile. After this change, touching it only causes 550 compiles in
an incremental rebuild.
Reviewers: bkramer, asbirlea, bollu, jdoerfert
Differential Revision: https://reviews.llvm.org/D70211
2019-11-13 22:15:01 +01:00
|
|
|
LazyValueInfoWrapperPass::LazyValueInfoWrapperPass() : FunctionPass(ID) {
|
|
|
|
initializeLazyValueInfoWrapperPassPass(*PassRegistry::getPassRegistry());
|
|
|
|
}
|
2016-06-14 00:01:25 +02:00
|
|
|
INITIALIZE_PASS_BEGIN(LazyValueInfoWrapperPass, "lazy-value-info",
|
2011-12-02 02:26:24 +01:00
|
|
|
"Lazy Value Information Analysis", false, true)
|
2016-12-19 09:22:17 +01:00
|
|
|
INITIALIZE_PASS_DEPENDENCY(AssumptionCacheTracker)
|
2015-01-15 11:41:28 +01:00
|
|
|
INITIALIZE_PASS_DEPENDENCY(TargetLibraryInfoWrapperPass)
|
2016-06-14 00:01:25 +02:00
|
|
|
INITIALIZE_PASS_END(LazyValueInfoWrapperPass, "lazy-value-info",
|
2010-10-08 00:25:06 +02:00
|
|
|
"Lazy Value Information Analysis", false, true)
|
2009-11-11 01:22:30 +01:00
|
|
|
|
|
|
|
namespace llvm {
|
2016-06-14 00:01:25 +02:00
|
|
|
FunctionPass *createLazyValueInfoPass() { return new LazyValueInfoWrapperPass(); }
|
2009-11-11 01:22:30 +01:00
|
|
|
}
|
|
|
|
|
2016-11-23 18:53:26 +01:00
|
|
|
AnalysisKey LazyValueAnalysis::Key;
|
2009-11-11 03:08:33 +01:00
|
|
|
|
2016-02-02 23:03:19 +01:00
|
|
|
/// Returns true if this lattice value represents at most one possible value.
|
|
|
|
/// This is as precise as any lattice value can get while still representing
|
|
|
|
/// reachable code.
|
2017-09-28 13:09:22 +02:00
|
|
|
static bool hasSingleValue(const ValueLatticeElement &Val) {
|
2016-02-02 23:03:19 +01:00
|
|
|
if (Val.isConstantRange() &&
|
|
|
|
Val.getConstantRange().isSingleElement())
|
|
|
|
// Integer constants are single element ranges
|
|
|
|
return true;
|
|
|
|
if (Val.isConstant())
|
|
|
|
// Non integer constants
|
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Combine two sets of facts about the same value into a single set of
|
|
|
|
/// facts. Note that this method is not suitable for merging facts along
|
|
|
|
/// different paths in a CFG; that's what the mergeIn function is for. This
|
|
|
|
/// is for merging facts gathered about the same value at the same location
|
|
|
|
/// through two independent means.
|
|
|
|
/// Notes:
|
|
|
|
/// * This method does not promise to return the most precise possible lattice
|
|
|
|
/// value implied by A and B. It is allowed to return any lattice element
|
|
|
|
/// which is at least as strong as *either* A or B (unless our facts
|
2016-07-04 03:26:27 +02:00
|
|
|
/// conflict, see below).
|
2016-02-02 23:03:19 +01:00
|
|
|
/// * Due to unreachable code, the intersection of two lattice values could be
|
|
|
|
/// contradictory. If this happens, we return some valid lattice value so as
|
|
|
|
/// not confuse the rest of LVI. Ideally, we'd always return Undefined, but
|
|
|
|
/// we do not make this guarantee. TODO: This would be a useful enhancement.
|
2017-09-28 13:09:22 +02:00
|
|
|
static ValueLatticeElement intersect(const ValueLatticeElement &A,
|
|
|
|
const ValueLatticeElement &B) {
|
2016-02-02 23:03:19 +01:00
|
|
|
// Undefined is the strongest state. It means the value is known to be along
|
|
|
|
// an unreachable path.
|
2020-03-14 17:50:09 +01:00
|
|
|
if (A.isUnknown())
|
2016-02-02 23:03:19 +01:00
|
|
|
return A;
|
2020-03-14 17:50:09 +01:00
|
|
|
if (B.isUnknown())
|
2016-02-02 23:03:19 +01:00
|
|
|
return B;
|
|
|
|
|
|
|
|
// If we gave up for one, but got a useable fact from the other, use it.
|
|
|
|
if (A.isOverdefined())
|
|
|
|
return B;
|
|
|
|
if (B.isOverdefined())
|
|
|
|
return A;
|
|
|
|
|
|
|
|
// Can't get any more precise than constants.
|
|
|
|
if (hasSingleValue(A))
|
|
|
|
return A;
|
|
|
|
if (hasSingleValue(B))
|
|
|
|
return B;
|
|
|
|
|
|
|
|
// Could be either constant range or not constant here.
|
|
|
|
if (!A.isConstantRange() || !B.isConstantRange()) {
|
|
|
|
// TODO: Arbitrary choice, could be improved
|
|
|
|
return A;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Intersect two constant ranges
|
|
|
|
ConstantRange Range =
|
[ValueLattice] Distinguish between constant ranges with/without undef.
This patch updates ValueLattice to distinguish between ranges that are
guaranteed to not include undef and ranges that may include undef.
A constant range guaranteed to not contain undef can be used to simplify
instructions to arbitrary values. A constant range that may contain
undef can only be used to simplify to a constant. If the value can be
undef, it might take a value outside the range. For example, consider
the snipped below
define i32 @f(i32 %a, i1 %c) {
br i1 %c, label %true, label %false
true:
%a.255 = and i32 %a, 255
br label %exit
false:
br label %exit
exit:
%p = phi i32 [ %a.255, %true ], [ undef, %false ]
%f.1 = icmp eq i32 %p, 300
call void @use(i1 %f.1)
%res = and i32 %p, 255
ret i32 %res
}
In the exit block, %p would be a constant range [0, 256) including undef as
%p could be undef. We can use the range information to replace %f.1 with
false because we remove the compare, effectively forcing the use of the
constant to be != 300. We cannot replace %res with %p however, because
if %a would be undef %cond may be true but the second use might not be
< 256.
Currently LazyValueInfo uses the new behavior just when simplifying AND
instructions and does not distinguish between constant ranges with and
without undef otherwise. I think we should address the remaining issues
in LVI incrementally.
Reviewers: efriedma, reames, aqjune, jdoerfert, sstefan1
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D76931
2020-03-31 12:10:00 +02:00
|
|
|
A.getConstantRange().intersectWith(B.getConstantRange());
|
2020-04-25 14:39:27 +02:00
|
|
|
// Note: An empty range is implicitly converted to unknown or undef depending
|
|
|
|
// on MayIncludeUndef internally.
|
[ValueLattice] Distinguish between constant ranges with/without undef.
This patch updates ValueLattice to distinguish between ranges that are
guaranteed to not include undef and ranges that may include undef.
A constant range guaranteed to not contain undef can be used to simplify
instructions to arbitrary values. A constant range that may contain
undef can only be used to simplify to a constant. If the value can be
undef, it might take a value outside the range. For example, consider
the snipped below
define i32 @f(i32 %a, i1 %c) {
br i1 %c, label %true, label %false
true:
%a.255 = and i32 %a, 255
br label %exit
false:
br label %exit
exit:
%p = phi i32 [ %a.255, %true ], [ undef, %false ]
%f.1 = icmp eq i32 %p, 300
call void @use(i1 %f.1)
%res = and i32 %p, 255
ret i32 %res
}
In the exit block, %p would be a constant range [0, 256) including undef as
%p could be undef. We can use the range information to replace %f.1 with
false because we remove the compare, effectively forcing the use of the
constant to be != 300. We cannot replace %res with %p however, because
if %a would be undef %cond may be true but the second use might not be
< 256.
Currently LazyValueInfo uses the new behavior just when simplifying AND
instructions and does not distinguish between constant ranges with and
without undef otherwise. I think we should address the remaining issues
in LVI incrementally.
Reviewers: efriedma, reames, aqjune, jdoerfert, sstefan1
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D76931
2020-03-31 12:10:00 +02:00
|
|
|
return ValueLatticeElement::getRange(
|
|
|
|
std::move(Range), /*MayIncludeUndef=*/A.isConstantRangeIncludingUndef() |
|
|
|
|
B.isConstantRangeIncludingUndef());
|
2016-02-02 23:03:19 +01:00
|
|
|
}
|
2016-02-02 22:57:37 +01:00
|
|
|
|
2009-11-11 03:08:33 +01:00
|
|
|
//===----------------------------------------------------------------------===//
|
2009-11-15 20:59:49 +01:00
|
|
|
// LazyValueInfoCache Decl
|
2009-11-11 03:08:33 +01:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2009-11-15 20:59:49 +01:00
|
|
|
namespace {
|
2015-01-09 17:47:20 +01:00
|
|
|
/// A callback value handle updates the cache when values are erased.
|
2011-01-05 22:15:29 +01:00
|
|
|
class LazyValueInfoCache;
|
2015-08-04 00:30:24 +02:00
|
|
|
struct LVIValueHandle final : public CallbackVH {
|
2011-01-05 22:15:29 +01:00
|
|
|
LazyValueInfoCache *Parent;
|
2015-07-28 17:53:21 +02:00
|
|
|
|
2019-11-16 16:22:18 +01:00
|
|
|
LVIValueHandle(Value *V, LazyValueInfoCache *P = nullptr)
|
2011-01-05 22:15:29 +01:00
|
|
|
: CallbackVH(V), Parent(P) { }
|
2014-03-05 08:30:04 +01:00
|
|
|
|
|
|
|
void deleted() override;
|
|
|
|
void allUsesReplacedWith(Value *V) override {
|
2011-01-05 22:15:29 +01:00
|
|
|
deleted();
|
|
|
|
}
|
|
|
|
};
|
2016-07-28 00:33:36 +02:00
|
|
|
} // end anonymous namespace
|
2011-01-05 22:15:29 +01:00
|
|
|
|
2015-07-28 17:53:21 +02:00
|
|
|
namespace {
|
Reapply [LVI] Normalize pointer behavior
This got reverted because a dependency was reverted. It has since
been reapplied, so reapply this as well.
-----
Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.
The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.
This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this more powerful than the previous implementation as
a side-effect, and this does actually seem benefitial in practice.
Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.
I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.
Differential Revision: https://reviews.llvm.org/D69914
2019-12-04 20:51:31 +01:00
|
|
|
using NonNullPointerSet = SmallDenseSet<AssertingVH<Value>, 2>;
|
|
|
|
|
2015-01-09 17:47:20 +01:00
|
|
|
/// This is the cache kept by LazyValueInfo which
|
2009-11-15 20:59:49 +01:00
|
|
|
/// maintains information about queries across the clients' queries.
|
|
|
|
class LazyValueInfoCache {
|
2019-11-16 16:22:18 +01:00
|
|
|
/// This is all of the cached information for one basic block. It contains
|
|
|
|
/// the per-value lattice elements, as well as a separate set for
|
Reapply [LVI] Normalize pointer behavior
This got reverted because a dependency was reverted. It has since
been reapplied, so reapply this as well.
-----
Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.
The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.
This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this more powerful than the previous implementation as
a side-effect, and this does actually seem benefitial in practice.
Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.
I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.
Differential Revision: https://reviews.llvm.org/D69914
2019-12-04 20:51:31 +01:00
|
|
|
/// overdefined values to reduce memory usage. Additionally pointers
|
|
|
|
/// dereferenced in the block are cached for nullability queries.
|
2019-11-16 16:22:18 +01:00
|
|
|
struct BlockCacheEntry {
|
|
|
|
SmallDenseMap<AssertingVH<Value>, ValueLatticeElement, 4> LatticeElements;
|
|
|
|
SmallDenseSet<AssertingVH<Value>, 4> OverDefined;
|
Reapply [LVI] Normalize pointer behavior
This got reverted because a dependency was reverted. It has since
been reapplied, so reapply this as well.
-----
Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.
The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.
This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this more powerful than the previous implementation as
a side-effect, and this does actually seem benefitial in practice.
Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.
I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.
Differential Revision: https://reviews.llvm.org/D69914
2019-12-04 20:51:31 +01:00
|
|
|
// None indicates that the nonnull pointers for this basic block
|
|
|
|
// block have not been computed yet.
|
|
|
|
Optional<NonNullPointerSet> NonNullPointers;
|
2016-07-28 00:33:36 +02:00
|
|
|
};
|
2009-11-11 01:22:30 +01:00
|
|
|
|
2019-11-16 16:22:18 +01:00
|
|
|
/// Cached information per basic block.
|
|
|
|
DenseMap<PoisoningVH<BasicBlock>, std::unique_ptr<BlockCacheEntry>>
|
|
|
|
BlockCache;
|
|
|
|
/// Set of value handles used to erase values from the cache on deletion.
|
|
|
|
DenseSet<LVIValueHandle, DenseMapInfo<Value *>> ValueHandles;
|
|
|
|
|
|
|
|
const BlockCacheEntry *getBlockEntry(BasicBlock *BB) const {
|
2020-06-13 15:15:39 +02:00
|
|
|
auto It = BlockCache.find_as(BB);
|
2019-11-16 16:22:18 +01:00
|
|
|
if (It == BlockCache.end())
|
|
|
|
return nullptr;
|
|
|
|
return It->second.get();
|
|
|
|
}
|
2019-12-20 19:25:57 +01:00
|
|
|
|
2019-11-16 16:22:18 +01:00
|
|
|
BlockCacheEntry *getOrCreateBlockEntry(BasicBlock *BB) {
|
2020-06-13 15:15:39 +02:00
|
|
|
auto It = BlockCache.find_as(BB);
|
2019-11-16 16:22:18 +01:00
|
|
|
if (It == BlockCache.end())
|
|
|
|
It = BlockCache.insert({ BB, std::make_unique<BlockCacheEntry>() })
|
|
|
|
.first;
|
2019-12-20 19:25:57 +01:00
|
|
|
|
2019-11-16 16:22:18 +01:00
|
|
|
return It->second.get();
|
|
|
|
}
|
2017-03-22 20:27:12 +01:00
|
|
|
|
2020-06-20 12:49:08 +02:00
|
|
|
void addValueHandle(Value *Val) {
|
|
|
|
auto HandleIt = ValueHandles.find_as(Val);
|
|
|
|
if (HandleIt == ValueHandles.end())
|
|
|
|
ValueHandles.insert({ Val, this });
|
|
|
|
}
|
|
|
|
|
2016-09-13 00:38:44 +02:00
|
|
|
public:
|
2017-09-28 13:09:22 +02:00
|
|
|
void insertResult(Value *Val, BasicBlock *BB,
|
|
|
|
const ValueLatticeElement &Result) {
|
2019-11-16 16:22:18 +01:00
|
|
|
BlockCacheEntry *Entry = getOrCreateBlockEntry(BB);
|
2019-12-20 19:25:57 +01:00
|
|
|
|
2015-12-11 01:49:47 +01:00
|
|
|
// Insert over-defined values into their own cache to reduce memory
|
|
|
|
// overhead.
|
2014-11-25 18:23:05 +01:00
|
|
|
if (Result.isOverdefined())
|
2019-11-16 16:22:18 +01:00
|
|
|
Entry->OverDefined.insert(Val);
|
|
|
|
else
|
|
|
|
Entry->LatticeElements.insert({ Val, Result });
|
2015-12-11 01:49:47 +01:00
|
|
|
|
2020-06-20 12:49:08 +02:00
|
|
|
addValueHandle(Val);
|
2015-12-11 01:49:47 +01:00
|
|
|
}
|
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> getCachedValueInfo(Value *V,
|
|
|
|
BasicBlock *BB) const {
|
2019-11-16 16:22:18 +01:00
|
|
|
const BlockCacheEntry *Entry = getBlockEntry(BB);
|
|
|
|
if (!Entry)
|
|
|
|
return None;
|
|
|
|
|
|
|
|
if (Entry->OverDefined.count(V))
|
2020-04-09 21:13:03 +02:00
|
|
|
return ValueLatticeElement::getOverdefined();
|
2019-12-20 19:25:57 +01:00
|
|
|
|
2020-06-13 15:15:39 +02:00
|
|
|
auto LatticeIt = Entry->LatticeElements.find_as(V);
|
2019-11-16 16:22:18 +01:00
|
|
|
if (LatticeIt == Entry->LatticeElements.end())
|
2020-04-09 21:13:03 +02:00
|
|
|
return None;
|
2019-11-16 16:22:18 +01:00
|
|
|
|
|
|
|
return LatticeIt->second;
|
Reapply [LVI] Normalize pointer behavior
This is a rebase of the change over D70376, which fixes an LVI cache
invalidation issue that also affected this patch.
-----
Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.
The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.
This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this change not fully NFC, because we can now fold
terminator icmps based on the dereferencability information in the
same block. This is the reason why I changed one JumpThreading test
(it would optimize the condition away without the change).
Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.
I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.
Differential Revision: https://reviews.llvm.org/D69914
2019-12-04 20:51:31 +01:00
|
|
|
}
|
|
|
|
|
Reapply [LVI] Normalize pointer behavior
This got reverted because a dependency was reverted. It has since
been reapplied, so reapply this as well.
-----
Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.
The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.
This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this more powerful than the previous implementation as
a side-effect, and this does actually seem benefitial in practice.
Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.
I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.
Differential Revision: https://reviews.llvm.org/D69914
2019-12-04 20:51:31 +01:00
|
|
|
bool isNonNullAtEndOfBlock(
|
|
|
|
Value *V, BasicBlock *BB,
|
|
|
|
function_ref<NonNullPointerSet(BasicBlock *)> InitFn) {
|
|
|
|
BlockCacheEntry *Entry = getOrCreateBlockEntry(BB);
|
|
|
|
if (!Entry->NonNullPointers) {
|
|
|
|
Entry->NonNullPointers = InitFn(BB);
|
|
|
|
for (Value *V : *Entry->NonNullPointers)
|
|
|
|
addValueHandle(V);
|
|
|
|
}
|
|
|
|
|
|
|
|
return Entry->NonNullPointers->count(V);
|
|
|
|
}
|
|
|
|
|
2016-09-12 23:46:58 +02:00
|
|
|
/// clear - Empty the cache.
|
|
|
|
void clear() {
|
2019-11-16 16:22:18 +01:00
|
|
|
BlockCache.clear();
|
|
|
|
ValueHandles.clear();
|
2016-09-12 23:46:58 +02:00
|
|
|
}
|
|
|
|
|
2016-09-13 00:03:36 +02:00
|
|
|
/// Inform the cache that a given value has been deleted.
|
|
|
|
void eraseValue(Value *V);
|
|
|
|
|
|
|
|
/// This is part of the update interface to inform the cache
|
|
|
|
/// that a block has been deleted.
|
|
|
|
void eraseBlock(BasicBlock *BB);
|
|
|
|
|
2016-09-13 00:38:44 +02:00
|
|
|
/// Updates the cache to remove any influence an overdefined value in
|
|
|
|
/// OldSucc might have (unless also overdefined in NewSucc). This just
|
|
|
|
/// flushes elements from the cache and does not add any.
|
|
|
|
void threadEdgeImpl(BasicBlock *OldSucc,BasicBlock *NewSucc);
|
2016-09-12 23:46:58 +02:00
|
|
|
};
|
2016-09-13 00:03:36 +02:00
|
|
|
}
|
2016-09-12 23:46:58 +02:00
|
|
|
|
2019-11-13 00:51:51 +01:00
|
|
|
void LazyValueInfoCache::eraseValue(Value *V) {
|
2019-11-16 16:22:18 +01:00
|
|
|
for (auto &Pair : BlockCache) {
|
|
|
|
Pair.second->LatticeElements.erase(V);
|
|
|
|
Pair.second->OverDefined.erase(V);
|
Reapply [LVI] Normalize pointer behavior
This got reverted because a dependency was reverted. It has since
been reapplied, so reapply this as well.
-----
Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.
The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.
This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this more powerful than the previous implementation as
a side-effect, and this does actually seem benefitial in practice.
Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.
I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.
Differential Revision: https://reviews.llvm.org/D69914
2019-12-04 20:51:31 +01:00
|
|
|
if (Pair.second->NonNullPointers)
|
|
|
|
Pair.second->NonNullPointers->erase(V);
|
2016-09-13 00:03:36 +02:00
|
|
|
}
|
|
|
|
|
2019-11-16 16:22:18 +01:00
|
|
|
auto HandleIt = ValueHandles.find_as(V);
|
|
|
|
if (HandleIt != ValueHandles.end())
|
|
|
|
ValueHandles.erase(HandleIt);
|
2016-09-13 00:03:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void LVIValueHandle::deleted() {
|
|
|
|
// This erasure deallocates *this, so it MUST happen after we're done
|
|
|
|
// using any and all members of *this.
|
|
|
|
Parent->eraseValue(*this);
|
|
|
|
}
|
|
|
|
|
|
|
|
void LazyValueInfoCache::eraseBlock(BasicBlock *BB) {
|
2019-11-16 16:22:18 +01:00
|
|
|
BlockCache.erase(BB);
|
2016-09-13 00:03:36 +02:00
|
|
|
}
|
|
|
|
|
2016-09-13 00:38:44 +02:00
|
|
|
void LazyValueInfoCache::threadEdgeImpl(BasicBlock *OldSucc,
|
|
|
|
BasicBlock *NewSucc) {
|
|
|
|
// When an edge in the graph has been threaded, values that we could not
|
|
|
|
// determine a value for before (i.e. were marked overdefined) may be
|
|
|
|
// possible to solve now. We do NOT try to proactively update these values.
|
|
|
|
// Instead, we clear their entries from the cache, and allow lazy updating to
|
|
|
|
// recompute them when needed.
|
|
|
|
|
|
|
|
// The updating process is fairly simple: we need to drop cached info
|
|
|
|
// for all values that were marked overdefined in OldSucc, and for those same
|
|
|
|
// values in any successor of OldSucc (except NewSucc) in which they were
|
|
|
|
// also marked overdefined.
|
|
|
|
std::vector<BasicBlock*> worklist;
|
|
|
|
worklist.push_back(OldSucc);
|
|
|
|
|
2019-11-16 16:22:18 +01:00
|
|
|
const BlockCacheEntry *Entry = getBlockEntry(OldSucc);
|
|
|
|
if (!Entry || Entry->OverDefined.empty())
|
2016-09-13 00:38:44 +02:00
|
|
|
return; // Nothing to process here.
|
2019-11-16 16:22:18 +01:00
|
|
|
SmallVector<Value *, 4> ValsToClear(Entry->OverDefined.begin(),
|
|
|
|
Entry->OverDefined.end());
|
2016-09-13 00:38:44 +02:00
|
|
|
|
|
|
|
// Use a worklist to perform a depth-first search of OldSucc's successors.
|
|
|
|
// NOTE: We do not need a visited list since any blocks we have already
|
|
|
|
// visited will have had their overdefined markers cleared already, and we
|
|
|
|
// thus won't loop to their successors.
|
|
|
|
while (!worklist.empty()) {
|
|
|
|
BasicBlock *ToUpdate = worklist.back();
|
|
|
|
worklist.pop_back();
|
|
|
|
|
|
|
|
// Skip blocks only accessible through NewSucc.
|
|
|
|
if (ToUpdate == NewSucc) continue;
|
|
|
|
|
2016-12-30 18:56:47 +01:00
|
|
|
// If a value was marked overdefined in OldSucc, and is here too...
|
2020-06-13 15:15:39 +02:00
|
|
|
auto OI = BlockCache.find_as(ToUpdate);
|
2019-11-16 16:22:18 +01:00
|
|
|
if (OI == BlockCache.end() || OI->second->OverDefined.empty())
|
2016-12-30 18:56:47 +01:00
|
|
|
continue;
|
2019-11-16 16:22:18 +01:00
|
|
|
auto &ValueSet = OI->second->OverDefined;
|
2016-12-30 18:56:47 +01:00
|
|
|
|
2016-09-13 00:38:44 +02:00
|
|
|
bool changed = false;
|
|
|
|
for (Value *V : ValsToClear) {
|
2016-12-30 23:09:10 +01:00
|
|
|
if (!ValueSet.erase(V))
|
2016-09-13 00:38:44 +02:00
|
|
|
continue;
|
|
|
|
|
|
|
|
// If we removed anything, then we potentially need to update
|
|
|
|
// blocks successors too.
|
|
|
|
changed = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!changed) continue;
|
|
|
|
|
2020-12-30 04:23:21 +01:00
|
|
|
llvm::append_range(worklist, successors(ToUpdate));
|
2016-09-13 00:38:44 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-06 21:25:31 +02:00
|
|
|
|
|
|
|
namespace {
|
|
|
|
/// An assembly annotator class to print LazyValueCache information in
|
|
|
|
/// comments.
|
|
|
|
class LazyValueInfoImpl;
|
|
|
|
class LazyValueInfoAnnotatedWriter : public AssemblyAnnotationWriter {
|
|
|
|
LazyValueInfoImpl *LVIImpl;
|
|
|
|
// While analyzing which blocks we can solve values for, we need the dominator
|
2020-03-25 20:02:07 +01:00
|
|
|
// information.
|
2017-06-06 21:25:31 +02:00
|
|
|
DominatorTree &DT;
|
|
|
|
|
|
|
|
public:
|
|
|
|
LazyValueInfoAnnotatedWriter(LazyValueInfoImpl *L, DominatorTree &DTree)
|
|
|
|
: LVIImpl(L), DT(DTree) {}
|
|
|
|
|
2020-07-14 18:47:29 +02:00
|
|
|
void emitBasicBlockStartAnnot(const BasicBlock *BB,
|
|
|
|
formatted_raw_ostream &OS) override;
|
2017-06-06 21:25:31 +02:00
|
|
|
|
2020-07-14 18:47:29 +02:00
|
|
|
void emitInstructionAnnot(const Instruction *I,
|
|
|
|
formatted_raw_ostream &OS) override;
|
2017-06-06 21:25:31 +02:00
|
|
|
};
|
|
|
|
}
|
2016-09-13 00:03:36 +02:00
|
|
|
namespace {
|
2020-06-14 15:42:27 +02:00
|
|
|
// The actual implementation of the lazy analysis and update. Note that the
|
|
|
|
// inheritance from LazyValueInfoCache is intended to be temporary while
|
|
|
|
// splitting the code and then transitioning to a has-a relationship.
|
|
|
|
class LazyValueInfoImpl {
|
|
|
|
|
|
|
|
/// Cached results from previous queries
|
|
|
|
LazyValueInfoCache TheCache;
|
|
|
|
|
|
|
|
/// This stack holds the state of the value solver during a query.
|
|
|
|
/// It basically emulates the callstack of the naive
|
|
|
|
/// recursive value lookup process.
|
|
|
|
SmallVector<std::pair<BasicBlock*, Value*>, 8> BlockValueStack;
|
|
|
|
|
|
|
|
/// Keeps track of which block-value pairs are in BlockValueStack.
|
|
|
|
DenseSet<std::pair<BasicBlock*, Value*> > BlockValueSet;
|
|
|
|
|
|
|
|
/// Push BV onto BlockValueStack unless it's already in there.
|
|
|
|
/// Returns true on success.
|
|
|
|
bool pushBlockValue(const std::pair<BasicBlock *, Value *> &BV) {
|
|
|
|
if (!BlockValueSet.insert(BV).second)
|
|
|
|
return false; // It's already in the stack.
|
|
|
|
|
|
|
|
LLVM_DEBUG(dbgs() << "PUSH: " << *BV.second << " in "
|
|
|
|
<< BV.first->getName() << "\n");
|
|
|
|
BlockValueStack.push_back(BV);
|
|
|
|
return true;
|
|
|
|
}
|
2016-09-12 23:46:58 +02:00
|
|
|
|
2020-06-14 15:42:27 +02:00
|
|
|
AssumptionCache *AC; ///< A pointer to the cache of @llvm.assume calls.
|
|
|
|
const DataLayout &DL; ///< A mandatory DataLayout
|
2016-09-12 23:46:58 +02:00
|
|
|
|
2020-06-14 15:42:27 +02:00
|
|
|
/// Declaration of the llvm.experimental.guard() intrinsic,
|
|
|
|
/// if it exists in the module.
|
|
|
|
Function *GuardDecl;
|
2020-06-13 15:36:55 +02:00
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> getBlockValue(Value *Val, BasicBlock *BB);
|
|
|
|
Optional<ValueLatticeElement> getEdgeValue(Value *V, BasicBlock *F,
|
|
|
|
BasicBlock *T, Instruction *CxtI = nullptr);
|
2016-09-12 23:46:58 +02:00
|
|
|
|
|
|
|
// These methods process one work item and may add more. A false value
|
|
|
|
// returned means that the work item was not completely processed and must
|
|
|
|
// be revisited after going through the new items.
|
|
|
|
bool solveBlockValue(Value *Val, BasicBlock *BB);
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> solveBlockValueImpl(Value *Val, BasicBlock *BB);
|
|
|
|
Optional<ValueLatticeElement> solveBlockValueNonLocal(Value *Val,
|
|
|
|
BasicBlock *BB);
|
|
|
|
Optional<ValueLatticeElement> solveBlockValuePHINode(PHINode *PN,
|
|
|
|
BasicBlock *BB);
|
|
|
|
Optional<ValueLatticeElement> solveBlockValueSelect(SelectInst *S,
|
|
|
|
BasicBlock *BB);
|
2020-07-25 16:32:22 +02:00
|
|
|
Optional<ConstantRange> getRangeFor(Value *V, Instruction *CxtI,
|
|
|
|
BasicBlock *BB);
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> solveBlockValueBinaryOpImpl(
|
|
|
|
Instruction *I, BasicBlock *BB,
|
2019-05-25 11:53:37 +02:00
|
|
|
std::function<ConstantRange(const ConstantRange &,
|
|
|
|
const ConstantRange &)> OpFn);
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> solveBlockValueBinaryOp(BinaryOperator *BBI,
|
|
|
|
BasicBlock *BB);
|
|
|
|
Optional<ValueLatticeElement> solveBlockValueCast(CastInst *CI,
|
|
|
|
BasicBlock *BB);
|
|
|
|
Optional<ValueLatticeElement> solveBlockValueOverflowIntrinsic(
|
|
|
|
WithOverflowInst *WO, BasicBlock *BB);
|
|
|
|
Optional<ValueLatticeElement> solveBlockValueIntrinsic(IntrinsicInst *II,
|
|
|
|
BasicBlock *BB);
|
|
|
|
Optional<ValueLatticeElement> solveBlockValueExtractValue(
|
|
|
|
ExtractValueInst *EVI, BasicBlock *BB);
|
Reapply [LVI] Normalize pointer behavior
This got reverted because a dependency was reverted. It has since
been reapplied, so reapply this as well.
-----
Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.
The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.
This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this more powerful than the previous implementation as
a side-effect, and this does actually seem benefitial in practice.
Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.
I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.
Differential Revision: https://reviews.llvm.org/D69914
2019-12-04 20:51:31 +01:00
|
|
|
bool isNonNullAtEndOfBlock(Value *Val, BasicBlock *BB);
|
2016-09-12 23:46:58 +02:00
|
|
|
void intersectAssumeOrGuardBlockValueConstantRange(Value *Val,
|
2017-09-28 13:09:22 +02:00
|
|
|
ValueLatticeElement &BBLV,
|
2017-06-02 19:28:12 +02:00
|
|
|
Instruction *BBI);
|
2016-09-12 23:46:58 +02:00
|
|
|
|
|
|
|
void solve();
|
|
|
|
|
2020-06-14 15:42:27 +02:00
|
|
|
public:
|
2020-09-27 18:21:19 +02:00
|
|
|
/// This is the query interface to determine the lattice value for the
|
|
|
|
/// specified Value* at the context instruction (if specified) or at the
|
|
|
|
/// start of the block.
|
2020-06-14 15:42:27 +02:00
|
|
|
ValueLatticeElement getValueInBlock(Value *V, BasicBlock *BB,
|
|
|
|
Instruction *CxtI = nullptr);
|
|
|
|
|
2020-09-27 18:21:19 +02:00
|
|
|
/// This is the query interface to determine the lattice value for the
|
|
|
|
/// specified Value* at the specified instruction using only information
|
|
|
|
/// from assumes/guards and range metadata. Unlike getValueInBlock(), no
|
|
|
|
/// recursive query is performed.
|
2020-06-14 15:42:27 +02:00
|
|
|
ValueLatticeElement getValueAt(Value *V, Instruction *CxtI);
|
|
|
|
|
|
|
|
/// This is the query interface to determine the lattice
|
|
|
|
/// value for the specified Value* that is true on the specified edge.
|
|
|
|
ValueLatticeElement getValueOnEdge(Value *V, BasicBlock *FromBB,
|
|
|
|
BasicBlock *ToBB,
|
|
|
|
Instruction *CxtI = nullptr);
|
|
|
|
|
|
|
|
/// Complete flush all previously computed values
|
|
|
|
void clear() {
|
|
|
|
TheCache.clear();
|
|
|
|
}
|
2016-09-13 00:38:44 +02:00
|
|
|
|
2020-06-14 15:42:27 +02:00
|
|
|
/// Printing the LazyValueInfo Analysis.
|
|
|
|
void printLVI(Function &F, DominatorTree &DTree, raw_ostream &OS) {
|
|
|
|
LazyValueInfoAnnotatedWriter Writer(this, DTree);
|
|
|
|
F.print(OS, &Writer);
|
|
|
|
}
|
2017-03-22 20:27:12 +01:00
|
|
|
|
2020-06-14 15:42:27 +02:00
|
|
|
/// This is part of the update interface to inform the cache
|
|
|
|
/// that a block has been deleted.
|
|
|
|
void eraseBlock(BasicBlock *BB) {
|
|
|
|
TheCache.eraseBlock(BB);
|
|
|
|
}
|
2016-09-13 00:38:44 +02:00
|
|
|
|
2020-06-14 15:42:27 +02:00
|
|
|
/// This is the update interface to inform the cache that an edge from
|
|
|
|
/// PredBB to OldSucc has been threaded to be from PredBB to NewSucc.
|
|
|
|
void threadEdge(BasicBlock *PredBB,BasicBlock *OldSucc,BasicBlock *NewSucc);
|
2015-07-28 17:53:21 +02:00
|
|
|
|
2020-06-14 15:42:27 +02:00
|
|
|
LazyValueInfoImpl(AssumptionCache *AC, const DataLayout &DL,
|
|
|
|
Function *GuardDecl)
|
|
|
|
: AC(AC), DL(DL), GuardDecl(GuardDecl) {}
|
|
|
|
};
|
2009-11-15 20:59:49 +01:00
|
|
|
} // end anonymous namespace
|
2009-11-11 23:48:44 +01:00
|
|
|
|
2017-06-06 21:25:31 +02:00
|
|
|
|
2016-09-12 23:46:58 +02:00
|
|
|
void LazyValueInfoImpl::solve() {
|
LVI: Add a per-value worklist limit to LazyValueInfo.
Summary:
LVI is now depth first, which is optimal for iteration strategy in
terms of work per call. However, the way the results get cached means
it can still go very badly N^2 or worse right now. The overdefined
cache is per-block, because LVI wants to try to get different results
for the same name in different blocks (IE solve the problem
PredicateInfo solves). This means even if we discover a value is
overdefined after going very deep, it doesn't cache this information,
causing it to end up trying to rediscover it again and again. The
same is true for values along the way. In practice, overdefined
anywhere should mean overdefined everywhere (this is how, for example,
SCCP works).
Until we get around to reworking the overdefined cache, we need to
limit the worklist size we process. Note that permanently reverting
the DFS strategy exploration seems the wrong strategy (temporarily
seems fine if we really want). BFS is clearly the wrong approach, it
just gets luckier on some testcases. It's also very hard to design
an effective throttle for BFS. For DFS, the throttle is directly related
to the depth of the CFG. So really deep CFGs will get cutoff, smaller
ones will not. As the CFG simplifies, you get better results.
In BFS, the limit is it's related to the fan-out times average block size,
which is harder to reason about or make good choices for.
Bug being filed about the overdefined cache, but it will require major
surgery to fix it (plumbing predicateinfo through CVP or LVI).
Note: I did not make this number configurable because i'm not sure
anyone really needs to tweak this knob. We run CVP 3 times. On the
testcases i have the slow ones happen in the middle, where CVP is
doing cleanup work other things are effective at. Over the course of
3 runs, we don't see to have any real loss of performance.
I haven't gotten a minimized testcase yet, but just imagine in your
head a testcase where, going *up* the CFG, you have branches, one of
which leads 50000 blocks deep, and the other, to something where the
answer is overdefined immediately. BFS would discover the overdefined
faster than DFS, but do more work to do so. In practice, the right
answer is "once DFS discovers overdefined for a value, stop trying to
get more info about that value" (and so, DFS would normally cache the
overdefined results for every value it passed through in those 50k
blocks, and never do that work again. But it don't, because of the
naming problem)
Reviewers: chandlerc, djasper
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29715
llvm-svn: 294463
2017-02-08 16:22:52 +01:00
|
|
|
SmallVector<std::pair<BasicBlock *, Value *>, 8> StartingStack(
|
|
|
|
BlockValueStack.begin(), BlockValueStack.end());
|
|
|
|
|
|
|
|
unsigned processedCount = 0;
|
2011-01-06 00:26:22 +01:00
|
|
|
while (!BlockValueStack.empty()) {
|
LVI: Add a per-value worklist limit to LazyValueInfo.
Summary:
LVI is now depth first, which is optimal for iteration strategy in
terms of work per call. However, the way the results get cached means
it can still go very badly N^2 or worse right now. The overdefined
cache is per-block, because LVI wants to try to get different results
for the same name in different blocks (IE solve the problem
PredicateInfo solves). This means even if we discover a value is
overdefined after going very deep, it doesn't cache this information,
causing it to end up trying to rediscover it again and again. The
same is true for values along the way. In practice, overdefined
anywhere should mean overdefined everywhere (this is how, for example,
SCCP works).
Until we get around to reworking the overdefined cache, we need to
limit the worklist size we process. Note that permanently reverting
the DFS strategy exploration seems the wrong strategy (temporarily
seems fine if we really want). BFS is clearly the wrong approach, it
just gets luckier on some testcases. It's also very hard to design
an effective throttle for BFS. For DFS, the throttle is directly related
to the depth of the CFG. So really deep CFGs will get cutoff, smaller
ones will not. As the CFG simplifies, you get better results.
In BFS, the limit is it's related to the fan-out times average block size,
which is harder to reason about or make good choices for.
Bug being filed about the overdefined cache, but it will require major
surgery to fix it (plumbing predicateinfo through CVP or LVI).
Note: I did not make this number configurable because i'm not sure
anyone really needs to tweak this knob. We run CVP 3 times. On the
testcases i have the slow ones happen in the middle, where CVP is
doing cleanup work other things are effective at. Over the course of
3 runs, we don't see to have any real loss of performance.
I haven't gotten a minimized testcase yet, but just imagine in your
head a testcase where, going *up* the CFG, you have branches, one of
which leads 50000 blocks deep, and the other, to something where the
answer is overdefined immediately. BFS would discover the overdefined
faster than DFS, but do more work to do so. In practice, the right
answer is "once DFS discovers overdefined for a value, stop trying to
get more info about that value" (and so, DFS would normally cache the
overdefined results for every value it passed through in those 50k
blocks, and never do that work again. But it don't, because of the
naming problem)
Reviewers: chandlerc, djasper
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29715
llvm-svn: 294463
2017-02-08 16:22:52 +01:00
|
|
|
processedCount++;
|
|
|
|
// Abort if we have to process too many values to get a result for this one.
|
|
|
|
// Because of the design of the overdefined cache currently being per-block
|
|
|
|
// to avoid naming-related issues (IE it wants to try to give different
|
|
|
|
// results for the same name in different blocks), overdefined results don't
|
|
|
|
// get cached globally, which in turn means we will often try to rediscover
|
|
|
|
// the same overdefined result again and again. Once something like
|
|
|
|
// PredicateInfo is used in LVI or CVP, we should be able to make the
|
|
|
|
// overdefined cache global, and remove this throttle.
|
|
|
|
if (processedCount > MaxProcessedPerValue) {
|
2018-05-14 14:53:11 +02:00
|
|
|
LLVM_DEBUG(
|
|
|
|
dbgs() << "Giving up on stack because we are getting too deep\n");
|
LVI: Add a per-value worklist limit to LazyValueInfo.
Summary:
LVI is now depth first, which is optimal for iteration strategy in
terms of work per call. However, the way the results get cached means
it can still go very badly N^2 or worse right now. The overdefined
cache is per-block, because LVI wants to try to get different results
for the same name in different blocks (IE solve the problem
PredicateInfo solves). This means even if we discover a value is
overdefined after going very deep, it doesn't cache this information,
causing it to end up trying to rediscover it again and again. The
same is true for values along the way. In practice, overdefined
anywhere should mean overdefined everywhere (this is how, for example,
SCCP works).
Until we get around to reworking the overdefined cache, we need to
limit the worklist size we process. Note that permanently reverting
the DFS strategy exploration seems the wrong strategy (temporarily
seems fine if we really want). BFS is clearly the wrong approach, it
just gets luckier on some testcases. It's also very hard to design
an effective throttle for BFS. For DFS, the throttle is directly related
to the depth of the CFG. So really deep CFGs will get cutoff, smaller
ones will not. As the CFG simplifies, you get better results.
In BFS, the limit is it's related to the fan-out times average block size,
which is harder to reason about or make good choices for.
Bug being filed about the overdefined cache, but it will require major
surgery to fix it (plumbing predicateinfo through CVP or LVI).
Note: I did not make this number configurable because i'm not sure
anyone really needs to tweak this knob. We run CVP 3 times. On the
testcases i have the slow ones happen in the middle, where CVP is
doing cleanup work other things are effective at. Over the course of
3 runs, we don't see to have any real loss of performance.
I haven't gotten a minimized testcase yet, but just imagine in your
head a testcase where, going *up* the CFG, you have branches, one of
which leads 50000 blocks deep, and the other, to something where the
answer is overdefined immediately. BFS would discover the overdefined
faster than DFS, but do more work to do so. In practice, the right
answer is "once DFS discovers overdefined for a value, stop trying to
get more info about that value" (and so, DFS would normally cache the
overdefined results for every value it passed through in those 50k
blocks, and never do that work again. But it don't, because of the
naming problem)
Reviewers: chandlerc, djasper
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29715
llvm-svn: 294463
2017-02-08 16:22:52 +01:00
|
|
|
// Fill in the original values
|
|
|
|
while (!StartingStack.empty()) {
|
|
|
|
std::pair<BasicBlock *, Value *> &e = StartingStack.back();
|
|
|
|
TheCache.insertResult(e.second, e.first,
|
2017-09-28 13:09:22 +02:00
|
|
|
ValueLatticeElement::getOverdefined());
|
LVI: Add a per-value worklist limit to LazyValueInfo.
Summary:
LVI is now depth first, which is optimal for iteration strategy in
terms of work per call. However, the way the results get cached means
it can still go very badly N^2 or worse right now. The overdefined
cache is per-block, because LVI wants to try to get different results
for the same name in different blocks (IE solve the problem
PredicateInfo solves). This means even if we discover a value is
overdefined after going very deep, it doesn't cache this information,
causing it to end up trying to rediscover it again and again. The
same is true for values along the way. In practice, overdefined
anywhere should mean overdefined everywhere (this is how, for example,
SCCP works).
Until we get around to reworking the overdefined cache, we need to
limit the worklist size we process. Note that permanently reverting
the DFS strategy exploration seems the wrong strategy (temporarily
seems fine if we really want). BFS is clearly the wrong approach, it
just gets luckier on some testcases. It's also very hard to design
an effective throttle for BFS. For DFS, the throttle is directly related
to the depth of the CFG. So really deep CFGs will get cutoff, smaller
ones will not. As the CFG simplifies, you get better results.
In BFS, the limit is it's related to the fan-out times average block size,
which is harder to reason about or make good choices for.
Bug being filed about the overdefined cache, but it will require major
surgery to fix it (plumbing predicateinfo through CVP or LVI).
Note: I did not make this number configurable because i'm not sure
anyone really needs to tweak this knob. We run CVP 3 times. On the
testcases i have the slow ones happen in the middle, where CVP is
doing cleanup work other things are effective at. Over the course of
3 runs, we don't see to have any real loss of performance.
I haven't gotten a minimized testcase yet, but just imagine in your
head a testcase where, going *up* the CFG, you have branches, one of
which leads 50000 blocks deep, and the other, to something where the
answer is overdefined immediately. BFS would discover the overdefined
faster than DFS, but do more work to do so. In practice, the right
answer is "once DFS discovers overdefined for a value, stop trying to
get more info about that value" (and so, DFS would normally cache the
overdefined results for every value it passed through in those 50k
blocks, and never do that work again. But it don't, because of the
naming problem)
Reviewers: chandlerc, djasper
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29715
llvm-svn: 294463
2017-02-08 16:22:52 +01:00
|
|
|
StartingStack.pop_back();
|
|
|
|
}
|
|
|
|
BlockValueSet.clear();
|
|
|
|
BlockValueStack.clear();
|
|
|
|
return;
|
|
|
|
}
|
2017-02-09 10:28:05 +01:00
|
|
|
std::pair<BasicBlock *, Value *> e = BlockValueStack.back();
|
2014-11-25 18:23:05 +01:00
|
|
|
assert(BlockValueSet.count(e) && "Stack value should be in BlockValueSet!");
|
|
|
|
|
2012-06-28 03:16:18 +02:00
|
|
|
if (solveBlockValue(e.second, e.first)) {
|
2014-11-25 18:23:05 +01:00
|
|
|
// The work item was completely processed.
|
LVI: Add a per-value worklist limit to LazyValueInfo.
Summary:
LVI is now depth first, which is optimal for iteration strategy in
terms of work per call. However, the way the results get cached means
it can still go very badly N^2 or worse right now. The overdefined
cache is per-block, because LVI wants to try to get different results
for the same name in different blocks (IE solve the problem
PredicateInfo solves). This means even if we discover a value is
overdefined after going very deep, it doesn't cache this information,
causing it to end up trying to rediscover it again and again. The
same is true for values along the way. In practice, overdefined
anywhere should mean overdefined everywhere (this is how, for example,
SCCP works).
Until we get around to reworking the overdefined cache, we need to
limit the worklist size we process. Note that permanently reverting
the DFS strategy exploration seems the wrong strategy (temporarily
seems fine if we really want). BFS is clearly the wrong approach, it
just gets luckier on some testcases. It's also very hard to design
an effective throttle for BFS. For DFS, the throttle is directly related
to the depth of the CFG. So really deep CFGs will get cutoff, smaller
ones will not. As the CFG simplifies, you get better results.
In BFS, the limit is it's related to the fan-out times average block size,
which is harder to reason about or make good choices for.
Bug being filed about the overdefined cache, but it will require major
surgery to fix it (plumbing predicateinfo through CVP or LVI).
Note: I did not make this number configurable because i'm not sure
anyone really needs to tweak this knob. We run CVP 3 times. On the
testcases i have the slow ones happen in the middle, where CVP is
doing cleanup work other things are effective at. Over the course of
3 runs, we don't see to have any real loss of performance.
I haven't gotten a minimized testcase yet, but just imagine in your
head a testcase where, going *up* the CFG, you have branches, one of
which leads 50000 blocks deep, and the other, to something where the
answer is overdefined immediately. BFS would discover the overdefined
faster than DFS, but do more work to do so. In practice, the right
answer is "once DFS discovers overdefined for a value, stop trying to
get more info about that value" (and so, DFS would normally cache the
overdefined results for every value it passed through in those 50k
blocks, and never do that work again. But it don't, because of the
naming problem)
Reviewers: chandlerc, djasper
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29715
llvm-svn: 294463
2017-02-08 16:22:52 +01:00
|
|
|
assert(BlockValueStack.back() == e && "Nothing should have been pushed!");
|
2020-03-24 20:31:13 +01:00
|
|
|
#ifndef NDEBUG
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> BBLV =
|
|
|
|
TheCache.getCachedValueInfo(e.second, e.first);
|
|
|
|
assert(BBLV && "Result should be in cache!");
|
2018-05-14 14:53:11 +02:00
|
|
|
LLVM_DEBUG(
|
|
|
|
dbgs() << "POP " << *e.second << " in " << e.first->getName() << " = "
|
2020-04-09 21:13:03 +02:00
|
|
|
<< *BBLV << "\n");
|
2020-03-24 20:31:13 +01:00
|
|
|
#endif
|
2016-02-02 04:15:40 +01:00
|
|
|
|
LVI: Add a per-value worklist limit to LazyValueInfo.
Summary:
LVI is now depth first, which is optimal for iteration strategy in
terms of work per call. However, the way the results get cached means
it can still go very badly N^2 or worse right now. The overdefined
cache is per-block, because LVI wants to try to get different results
for the same name in different blocks (IE solve the problem
PredicateInfo solves). This means even if we discover a value is
overdefined after going very deep, it doesn't cache this information,
causing it to end up trying to rediscover it again and again. The
same is true for values along the way. In practice, overdefined
anywhere should mean overdefined everywhere (this is how, for example,
SCCP works).
Until we get around to reworking the overdefined cache, we need to
limit the worklist size we process. Note that permanently reverting
the DFS strategy exploration seems the wrong strategy (temporarily
seems fine if we really want). BFS is clearly the wrong approach, it
just gets luckier on some testcases. It's also very hard to design
an effective throttle for BFS. For DFS, the throttle is directly related
to the depth of the CFG. So really deep CFGs will get cutoff, smaller
ones will not. As the CFG simplifies, you get better results.
In BFS, the limit is it's related to the fan-out times average block size,
which is harder to reason about or make good choices for.
Bug being filed about the overdefined cache, but it will require major
surgery to fix it (plumbing predicateinfo through CVP or LVI).
Note: I did not make this number configurable because i'm not sure
anyone really needs to tweak this knob. We run CVP 3 times. On the
testcases i have the slow ones happen in the middle, where CVP is
doing cleanup work other things are effective at. Over the course of
3 runs, we don't see to have any real loss of performance.
I haven't gotten a minimized testcase yet, but just imagine in your
head a testcase where, going *up* the CFG, you have branches, one of
which leads 50000 blocks deep, and the other, to something where the
answer is overdefined immediately. BFS would discover the overdefined
faster than DFS, but do more work to do so. In practice, the right
answer is "once DFS discovers overdefined for a value, stop trying to
get more info about that value" (and so, DFS would normally cache the
overdefined results for every value it passed through in those 50k
blocks, and never do that work again. But it don't, because of the
naming problem)
Reviewers: chandlerc, djasper
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29715
llvm-svn: 294463
2017-02-08 16:22:52 +01:00
|
|
|
BlockValueStack.pop_back();
|
2014-11-25 18:23:05 +01:00
|
|
|
BlockValueSet.erase(e);
|
|
|
|
} else {
|
|
|
|
// More work needs to be done before revisiting.
|
LVI: Add a per-value worklist limit to LazyValueInfo.
Summary:
LVI is now depth first, which is optimal for iteration strategy in
terms of work per call. However, the way the results get cached means
it can still go very badly N^2 or worse right now. The overdefined
cache is per-block, because LVI wants to try to get different results
for the same name in different blocks (IE solve the problem
PredicateInfo solves). This means even if we discover a value is
overdefined after going very deep, it doesn't cache this information,
causing it to end up trying to rediscover it again and again. The
same is true for values along the way. In practice, overdefined
anywhere should mean overdefined everywhere (this is how, for example,
SCCP works).
Until we get around to reworking the overdefined cache, we need to
limit the worklist size we process. Note that permanently reverting
the DFS strategy exploration seems the wrong strategy (temporarily
seems fine if we really want). BFS is clearly the wrong approach, it
just gets luckier on some testcases. It's also very hard to design
an effective throttle for BFS. For DFS, the throttle is directly related
to the depth of the CFG. So really deep CFGs will get cutoff, smaller
ones will not. As the CFG simplifies, you get better results.
In BFS, the limit is it's related to the fan-out times average block size,
which is harder to reason about or make good choices for.
Bug being filed about the overdefined cache, but it will require major
surgery to fix it (plumbing predicateinfo through CVP or LVI).
Note: I did not make this number configurable because i'm not sure
anyone really needs to tweak this knob. We run CVP 3 times. On the
testcases i have the slow ones happen in the middle, where CVP is
doing cleanup work other things are effective at. Over the course of
3 runs, we don't see to have any real loss of performance.
I haven't gotten a minimized testcase yet, but just imagine in your
head a testcase where, going *up* the CFG, you have branches, one of
which leads 50000 blocks deep, and the other, to something where the
answer is overdefined immediately. BFS would discover the overdefined
faster than DFS, but do more work to do so. In practice, the right
answer is "once DFS discovers overdefined for a value, stop trying to
get more info about that value" (and so, DFS would normally cache the
overdefined results for every value it passed through in those 50k
blocks, and never do that work again. But it don't, because of the
naming problem)
Reviewers: chandlerc, djasper
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29715
llvm-svn: 294463
2017-02-08 16:22:52 +01:00
|
|
|
assert(BlockValueStack.back() != e && "Stack should have been pushed!");
|
2012-06-28 03:16:18 +02:00
|
|
|
}
|
2010-12-18 02:00:40 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> LazyValueInfoImpl::getBlockValue(Value *Val,
|
|
|
|
BasicBlock *BB) {
|
2010-12-18 02:00:40 +01:00
|
|
|
// If already a constant, there is nothing to compute.
|
2020-04-09 21:13:03 +02:00
|
|
|
if (Constant *VC = dyn_cast<Constant>(Val))
|
|
|
|
return ValueLatticeElement::get(VC);
|
2010-12-18 02:00:40 +01:00
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
if (Optional<ValueLatticeElement> OptLatticeVal =
|
|
|
|
TheCache.getCachedValueInfo(Val, BB))
|
|
|
|
return OptLatticeVal;
|
2010-12-18 02:00:40 +01:00
|
|
|
|
2020-03-24 20:31:13 +01:00
|
|
|
// We have hit a cycle, assume overdefined.
|
2020-04-09 21:13:03 +02:00
|
|
|
if (!pushBlockValue({ BB, Val }))
|
|
|
|
return ValueLatticeElement::getOverdefined();
|
2010-12-18 02:00:40 +01:00
|
|
|
|
2020-03-24 20:31:13 +01:00
|
|
|
// Yet to be resolved.
|
2020-04-09 21:13:03 +02:00
|
|
|
return None;
|
2010-12-18 02:00:40 +01:00
|
|
|
}
|
|
|
|
|
2017-09-28 13:09:22 +02:00
|
|
|
static ValueLatticeElement getFromRangeMetadata(Instruction *BBI) {
|
[LVI/CVP] Teach LVI about range metadata
Somewhat shockingly for an analysis pass which is computing constant ranges, LVI did not understand the ranges provided by range metadata.
As part of this change, I included a change to CVP primarily because doing so made it much easier to write small self contained test cases. CVP was previously only handling the non-local operand case, but given that LVI can sometimes figure out information about instructions standalone, I don't see any reason to restrict this. There could possibly be a compile time impact from this, but I suspect it should be minimal. If anyone has an example which substaintially regresses, please let me know. I could restrict the block local handling to ICmps feeding Terminator instructions if needed.
Note that this patch continues a somewhat bad practice in LVI. In many cases, we know facts about values, and separate context sensitive facts about values. LVI makes no effort to distinguish and will frequently cache the same value fact repeatedly for different contexts. I would like to change this, but that's a large enough change that I want it to go in separately with clear documentation of what's changing. Other examples of this include the non-null handling, and arguments.
As a meta comment: the entire motivation of this change was being able to write smaller (aka reasonable sized) test cases for a future patch teaching LVI about select instructions.
Differential Revision: http://reviews.llvm.org/D13543
llvm-svn: 251606
2015-10-29 04:57:17 +01:00
|
|
|
switch (BBI->getOpcode()) {
|
|
|
|
default: break;
|
|
|
|
case Instruction::Load:
|
|
|
|
case Instruction::Call:
|
|
|
|
case Instruction::Invoke:
|
2016-07-25 02:59:46 +02:00
|
|
|
if (MDNode *Ranges = BBI->getMetadata(LLVMContext::MD_range))
|
2015-10-29 05:21:49 +01:00
|
|
|
if (isa<IntegerType>(BBI->getType())) {
|
2017-09-28 13:09:22 +02:00
|
|
|
return ValueLatticeElement::getRange(
|
|
|
|
getConstantRangeFromMetadata(*Ranges));
|
[LVI/CVP] Teach LVI about range metadata
Somewhat shockingly for an analysis pass which is computing constant ranges, LVI did not understand the ranges provided by range metadata.
As part of this change, I included a change to CVP primarily because doing so made it much easier to write small self contained test cases. CVP was previously only handling the non-local operand case, but given that LVI can sometimes figure out information about instructions standalone, I don't see any reason to restrict this. There could possibly be a compile time impact from this, but I suspect it should be minimal. If anyone has an example which substaintially regresses, please let me know. I could restrict the block local handling to ICmps feeding Terminator instructions if needed.
Note that this patch continues a somewhat bad practice in LVI. In many cases, we know facts about values, and separate context sensitive facts about values. LVI makes no effort to distinguish and will frequently cache the same value fact repeatedly for different contexts. I would like to change this, but that's a large enough change that I want it to go in separately with clear documentation of what's changing. Other examples of this include the non-null handling, and arguments.
As a meta comment: the entire motivation of this change was being able to write smaller (aka reasonable sized) test cases for a future patch teaching LVI about select instructions.
Differential Revision: http://reviews.llvm.org/D13543
llvm-svn: 251606
2015-10-29 04:57:17 +01:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
};
|
2016-02-02 22:57:37 +01:00
|
|
|
// Nothing known - will be intersected with other facts
|
2017-09-28 13:09:22 +02:00
|
|
|
return ValueLatticeElement::getOverdefined();
|
[LVI/CVP] Teach LVI about range metadata
Somewhat shockingly for an analysis pass which is computing constant ranges, LVI did not understand the ranges provided by range metadata.
As part of this change, I included a change to CVP primarily because doing so made it much easier to write small self contained test cases. CVP was previously only handling the non-local operand case, but given that LVI can sometimes figure out information about instructions standalone, I don't see any reason to restrict this. There could possibly be a compile time impact from this, but I suspect it should be minimal. If anyone has an example which substaintially regresses, please let me know. I could restrict the block local handling to ICmps feeding Terminator instructions if needed.
Note that this patch continues a somewhat bad practice in LVI. In many cases, we know facts about values, and separate context sensitive facts about values. LVI makes no effort to distinguish and will frequently cache the same value fact repeatedly for different contexts. I would like to change this, but that's a large enough change that I want it to go in separately with clear documentation of what's changing. Other examples of this include the non-null handling, and arguments.
As a meta comment: the entire motivation of this change was being able to write smaller (aka reasonable sized) test cases for a future patch teaching LVI about select instructions.
Differential Revision: http://reviews.llvm.org/D13543
llvm-svn: 251606
2015-10-29 04:57:17 +01:00
|
|
|
}
|
|
|
|
|
2016-09-12 23:46:58 +02:00
|
|
|
bool LazyValueInfoImpl::solveBlockValue(Value *Val, BasicBlock *BB) {
|
2020-03-24 22:39:25 +01:00
|
|
|
assert(!isa<Constant>(Val) && "Value should not be constant");
|
2020-04-09 21:13:03 +02:00
|
|
|
assert(!TheCache.getCachedValueInfo(Val, BB) &&
|
2020-03-24 22:39:25 +01:00
|
|
|
"Value should not be in cache");
|
2009-11-15 21:00:52 +01:00
|
|
|
|
2014-11-25 18:23:05 +01:00
|
|
|
// Hold off inserting this value into the Cache in case we have to return
|
|
|
|
// false and come back later.
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> Res = solveBlockValueImpl(Val, BB);
|
|
|
|
if (!Res)
|
2016-12-06 04:22:03 +01:00
|
|
|
// Work pushed, will revisit
|
|
|
|
return false;
|
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
TheCache.insertResult(Val, BB, *Res);
|
2016-12-06 04:22:03 +01:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> LazyValueInfoImpl::solveBlockValueImpl(
|
|
|
|
Value *Val, BasicBlock *BB) {
|
2019-12-20 19:25:57 +01:00
|
|
|
Instruction *BBI = dyn_cast<Instruction>(Val);
|
|
|
|
if (!BBI || BBI->getParent() != BB)
|
2020-04-09 21:13:03 +02:00
|
|
|
return solveBlockValueNonLocal(Val, BB);
|
2019-12-20 19:25:57 +01:00
|
|
|
|
|
|
|
if (PHINode *PN = dyn_cast<PHINode>(BBI))
|
2020-04-09 21:13:03 +02:00
|
|
|
return solveBlockValuePHINode(PN, BB);
|
2019-12-20 19:25:57 +01:00
|
|
|
|
|
|
|
if (auto *SI = dyn_cast<SelectInst>(BBI))
|
2020-04-09 21:13:03 +02:00
|
|
|
return solveBlockValueSelect(SI, BB);
|
2019-12-20 19:25:57 +01:00
|
|
|
|
2016-04-27 03:02:25 +02:00
|
|
|
// If this value is a nonnull pointer, record it's range and bailout. Note
|
|
|
|
// that for all other pointer typed values, we terminate the search at the
|
|
|
|
// definition. We could easily extend this to look through geps, bitcasts,
|
|
|
|
// and the like to prove non-nullness, but it's not clear that's worth it
|
2017-06-09 23:21:17 +02:00
|
|
|
// compile time wise. The context-insensitive value walk done inside
|
2017-09-09 20:23:11 +02:00
|
|
|
// isKnownNonZero gets most of the profitable cases at much less expense.
|
2019-02-05 09:30:48 +01:00
|
|
|
// This does mean that we have a sensitivity to where the defining
|
2016-04-27 03:02:25 +02:00
|
|
|
// instruction is placed, even if it could legally be hoisted much higher.
|
|
|
|
// That is unfortunate.
|
2019-12-20 19:25:57 +01:00
|
|
|
PointerType *PT = dyn_cast<PointerType>(BBI->getType());
|
2020-04-09 21:13:03 +02:00
|
|
|
if (PT && isKnownNonZero(BBI, DL))
|
|
|
|
return ValueLatticeElement::getNot(ConstantPointerNull::get(PT));
|
|
|
|
|
2016-05-26 00:29:34 +02:00
|
|
|
if (BBI->getType()->isIntegerTy()) {
|
2017-06-03 09:47:08 +02:00
|
|
|
if (auto *CI = dyn_cast<CastInst>(BBI))
|
2020-04-09 21:13:03 +02:00
|
|
|
return solveBlockValueCast(CI, BB);
|
2017-06-03 09:47:08 +02:00
|
|
|
|
2018-11-21 06:24:12 +01:00
|
|
|
if (BinaryOperator *BO = dyn_cast<BinaryOperator>(BBI))
|
2020-04-09 21:13:03 +02:00
|
|
|
return solveBlockValueBinaryOp(BO, BB);
|
2019-05-25 11:53:45 +02:00
|
|
|
|
|
|
|
if (auto *EVI = dyn_cast<ExtractValueInst>(BBI))
|
2020-04-09 21:13:03 +02:00
|
|
|
return solveBlockValueExtractValue(EVI, BB);
|
2019-05-25 18:44:14 +02:00
|
|
|
|
|
|
|
if (auto *II = dyn_cast<IntrinsicInst>(BBI))
|
2020-04-09 21:13:03 +02:00
|
|
|
return solveBlockValueIntrinsic(II, BB);
|
2010-12-18 02:00:40 +01:00
|
|
|
}
|
|
|
|
|
2018-05-14 14:53:11 +02:00
|
|
|
LLVM_DEBUG(dbgs() << " compute BB '" << BB->getName()
|
|
|
|
<< "' - unknown inst def found.\n");
|
2020-04-09 21:13:03 +02:00
|
|
|
return getFromRangeMetadata(BBI);
|
2010-12-18 02:00:40 +01:00
|
|
|
}
|
|
|
|
|
Reapply [LVI] Normalize pointer behavior
This got reverted because a dependency was reverted. It has since
been reapplied, so reapply this as well.
-----
Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.
The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.
This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this more powerful than the previous implementation as
a side-effect, and this does actually seem benefitial in practice.
Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.
I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.
Differential Revision: https://reviews.llvm.org/D69914
2019-12-04 20:51:31 +01:00
|
|
|
static void AddNonNullPointer(Value *Ptr, NonNullPointerSet &PtrSet) {
|
|
|
|
// TODO: Use NullPointerIsDefined instead.
|
|
|
|
if (Ptr->getType()->getPointerAddressSpace() == 0)
|
|
|
|
PtrSet.insert(getUnderlyingObject(Ptr));
|
|
|
|
}
|
|
|
|
|
|
|
|
static void AddNonNullPointersByInstruction(
|
|
|
|
Instruction *I, NonNullPointerSet &PtrSet) {
|
Reapply [LVI] Normalize pointer behavior
This is a rebase of the change over D70376, which fixes an LVI cache
invalidation issue that also affected this patch.
-----
Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.
The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.
This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this change not fully NFC, because we can now fold
terminator icmps based on the dereferencability information in the
same block. This is the reason why I changed one JumpThreading test
(it would optimize the condition away without the change).
Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.
I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.
Differential Revision: https://reviews.llvm.org/D69914
2019-12-04 20:51:31 +01:00
|
|
|
if (LoadInst *L = dyn_cast<LoadInst>(I)) {
|
Reapply [LVI] Normalize pointer behavior
This got reverted because a dependency was reverted. It has since
been reapplied, so reapply this as well.
-----
Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.
The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.
This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this more powerful than the previous implementation as
a side-effect, and this does actually seem benefitial in practice.
Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.
I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.
Differential Revision: https://reviews.llvm.org/D69914
2019-12-04 20:51:31 +01:00
|
|
|
AddNonNullPointer(L->getPointerOperand(), PtrSet);
|
|
|
|
} else if (StoreInst *S = dyn_cast<StoreInst>(I)) {
|
|
|
|
AddNonNullPointer(S->getPointerOperand(), PtrSet);
|
|
|
|
} else if (MemIntrinsic *MI = dyn_cast<MemIntrinsic>(I)) {
|
|
|
|
if (MI->isVolatile()) return;
|
2011-01-15 10:16:12 +01:00
|
|
|
|
|
|
|
// FIXME: check whether it has a valuerange that excludes zero?
|
|
|
|
ConstantInt *Len = dyn_cast<ConstantInt>(MI->getLength());
|
Reapply [LVI] Normalize pointer behavior
This got reverted because a dependency was reverted. It has since
been reapplied, so reapply this as well.
-----
Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.
The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.
This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this more powerful than the previous implementation as
a side-effect, and this does actually seem benefitial in practice.
Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.
I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.
Differential Revision: https://reviews.llvm.org/D69914
2019-12-04 20:51:31 +01:00
|
|
|
if (!Len || Len->isZero()) return;
|
2011-01-15 10:16:12 +01:00
|
|
|
|
Reapply [LVI] Normalize pointer behavior
This got reverted because a dependency was reverted. It has since
been reapplied, so reapply this as well.
-----
Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.
The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.
This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this more powerful than the previous implementation as
a side-effect, and this does actually seem benefitial in practice.
Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.
I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.
Differential Revision: https://reviews.llvm.org/D69914
2019-12-04 20:51:31 +01:00
|
|
|
AddNonNullPointer(MI->getRawDest(), PtrSet);
|
2011-01-15 10:16:12 +01:00
|
|
|
if (MemTransferInst *MTI = dyn_cast<MemTransferInst>(MI))
|
Reapply [LVI] Normalize pointer behavior
This got reverted because a dependency was reverted. It has since
been reapplied, so reapply this as well.
-----
Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.
The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.
This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this more powerful than the previous implementation as
a side-effect, and this does actually seem benefitial in practice.
Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.
I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.
Differential Revision: https://reviews.llvm.org/D69914
2019-12-04 20:51:31 +01:00
|
|
|
AddNonNullPointer(MTI->getRawSource(), PtrSet);
|
2011-01-15 10:16:12 +01:00
|
|
|
}
|
2010-12-18 02:00:40 +01:00
|
|
|
}
|
|
|
|
|
Reapply [LVI] Normalize pointer behavior
This got reverted because a dependency was reverted. It has since
been reapplied, so reapply this as well.
-----
Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.
The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.
This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this more powerful than the previous implementation as
a side-effect, and this does actually seem benefitial in practice.
Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.
I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.
Differential Revision: https://reviews.llvm.org/D69914
2019-12-04 20:51:31 +01:00
|
|
|
bool LazyValueInfoImpl::isNonNullAtEndOfBlock(Value *Val, BasicBlock *BB) {
|
|
|
|
if (NullPointerIsDefined(BB->getParent(),
|
|
|
|
Val->getType()->getPointerAddressSpace()))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
Val = getUnderlyingObject(Val);
|
2020-08-29 21:33:19 +02:00
|
|
|
return TheCache.isNonNullAtEndOfBlock(Val, BB, [](BasicBlock *BB) {
|
Reapply [LVI] Normalize pointer behavior
This got reverted because a dependency was reverted. It has since
been reapplied, so reapply this as well.
-----
Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.
The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.
This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this more powerful than the previous implementation as
a side-effect, and this does actually seem benefitial in practice.
Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.
I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.
Differential Revision: https://reviews.llvm.org/D69914
2019-12-04 20:51:31 +01:00
|
|
|
NonNullPointerSet NonNullPointers;
|
2016-04-27 02:30:55 +02:00
|
|
|
for (Instruction &I : *BB)
|
Reapply [LVI] Normalize pointer behavior
This got reverted because a dependency was reverted. It has since
been reapplied, so reapply this as well.
-----
Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.
The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.
This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this more powerful than the previous implementation as
a side-effect, and this does actually seem benefitial in practice.
Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.
I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.
Differential Revision: https://reviews.llvm.org/D69914
2019-12-04 20:51:31 +01:00
|
|
|
AddNonNullPointersByInstruction(&I, NonNullPointers);
|
|
|
|
return NonNullPointers;
|
|
|
|
});
|
2016-04-27 02:30:55 +02:00
|
|
|
}
|
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> LazyValueInfoImpl::solveBlockValueNonLocal(
|
|
|
|
Value *Val, BasicBlock *BB) {
|
2017-09-28 13:09:22 +02:00
|
|
|
ValueLatticeElement Result; // Start Undefined.
|
2010-12-18 02:00:40 +01:00
|
|
|
|
|
|
|
// If this is the entry block, we must be asking about an argument. The
|
|
|
|
// value is overdefined.
|
|
|
|
if (BB == &BB->getParent()->getEntryBlock()) {
|
|
|
|
assert(isa<Argument>(Val) && "Unknown live-in to the entry block");
|
Reapply [LVI] Normalize pointer behavior
This got reverted because a dependency was reverted. It has since
been reapplied, so reapply this as well.
-----
Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.
The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.
This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this more powerful than the previous implementation as
a side-effect, and this does actually seem benefitial in practice.
Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.
I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.
Differential Revision: https://reviews.llvm.org/D69914
2019-12-04 20:51:31 +01:00
|
|
|
return ValueLatticeElement::getOverdefined();
|
2010-12-18 02:00:40 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
// Loop over all of our predecessors, merging what we know from them into
|
2017-02-07 01:25:24 +01:00
|
|
|
// result. If we encounter an unexplored predecessor, we eagerly explore it
|
|
|
|
// in a depth first manner. In practice, this has the effect of discovering
|
|
|
|
// paths we can't analyze eagerly without spending compile times analyzing
|
|
|
|
// other paths. This heuristic benefits from the fact that predecessors are
|
|
|
|
// frequently arranged such that dominating ones come first and we quickly
|
|
|
|
// find a path to function entry. TODO: We should consider explicitly
|
|
|
|
// canonicalizing to make this true rather than relying on this happy
|
2018-07-30 21:41:25 +02:00
|
|
|
// accident.
|
2014-07-21 19:06:51 +02:00
|
|
|
for (pred_iterator PI = pred_begin(BB), E = pred_end(BB); PI != E; ++PI) {
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> EdgeResult = getEdgeValue(Val, *PI, BB);
|
|
|
|
if (!EdgeResult)
|
2017-02-07 01:25:24 +01:00
|
|
|
// Explore that input, then return here
|
2020-04-09 21:13:03 +02:00
|
|
|
return None;
|
2010-12-18 02:00:40 +01:00
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
Result.mergeIn(*EdgeResult);
|
2010-12-18 02:00:40 +01:00
|
|
|
|
|
|
|
// If we hit overdefined, exit early. The BlockVals entry is already set
|
|
|
|
// to overdefined.
|
|
|
|
if (Result.isOverdefined()) {
|
2018-05-14 14:53:11 +02:00
|
|
|
LLVM_DEBUG(dbgs() << " compute BB '" << BB->getName()
|
|
|
|
<< "' - overdefined because of pred (non local).\n");
|
2020-04-09 21:13:03 +02:00
|
|
|
return Result;
|
2010-12-18 02:00:40 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Return the merged value, which is more precise than 'overdefined'.
|
|
|
|
assert(!Result.isOverdefined());
|
2020-04-09 21:13:03 +02:00
|
|
|
return Result;
|
2010-12-18 02:00:40 +01:00
|
|
|
}
|
2015-07-28 17:53:21 +02:00
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> LazyValueInfoImpl::solveBlockValuePHINode(
|
|
|
|
PHINode *PN, BasicBlock *BB) {
|
2017-09-28 13:09:22 +02:00
|
|
|
ValueLatticeElement Result; // Start Undefined.
|
2010-12-18 02:00:40 +01:00
|
|
|
|
|
|
|
// Loop over all of our predecessors, merging what we know from them into
|
2017-02-07 01:25:24 +01:00
|
|
|
// result. See the comment about the chosen traversal order in
|
|
|
|
// solveBlockValueNonLocal; the same reasoning applies here.
|
2010-12-18 02:00:40 +01:00
|
|
|
for (unsigned i = 0, e = PN->getNumIncomingValues(); i != e; ++i) {
|
|
|
|
BasicBlock *PhiBB = PN->getIncomingBlock(i);
|
|
|
|
Value *PhiVal = PN->getIncomingValue(i);
|
2014-10-16 02:40:05 +02:00
|
|
|
// Note that we can provide PN as the context value to getEdgeValue, even
|
|
|
|
// though the results will be cached, because PN is the value being used as
|
|
|
|
// the cache key in the caller.
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> EdgeResult =
|
|
|
|
getEdgeValue(PhiVal, PhiBB, BB, PN);
|
|
|
|
if (!EdgeResult)
|
2017-02-07 01:25:24 +01:00
|
|
|
// Explore that input, then return here
|
2020-04-09 21:13:03 +02:00
|
|
|
return None;
|
2010-12-18 02:00:40 +01:00
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
Result.mergeIn(*EdgeResult);
|
2010-12-18 02:00:40 +01:00
|
|
|
|
|
|
|
// If we hit overdefined, exit early. The BlockVals entry is already set
|
|
|
|
// to overdefined.
|
|
|
|
if (Result.isOverdefined()) {
|
2018-05-14 14:53:11 +02:00
|
|
|
LLVM_DEBUG(dbgs() << " compute BB '" << BB->getName()
|
|
|
|
<< "' - overdefined because of pred (local).\n");
|
2015-07-28 17:53:21 +02:00
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
return Result;
|
2010-12-18 02:00:40 +01:00
|
|
|
}
|
|
|
|
}
|
2010-08-18 23:11:37 +02:00
|
|
|
|
2010-12-18 02:00:40 +01:00
|
|
|
// Return the merged value, which is more precise than 'overdefined'.
|
|
|
|
assert(!Result.isOverdefined() && "Possible PHI in entry block?");
|
2020-04-09 21:13:03 +02:00
|
|
|
return Result;
|
2010-12-18 02:00:40 +01:00
|
|
|
}
|
|
|
|
|
2017-09-28 13:09:22 +02:00
|
|
|
static ValueLatticeElement getValueFromCondition(Value *Val, Value *Cond,
|
|
|
|
bool isTrueDest = true);
|
2014-09-07 22:29:59 +02:00
|
|
|
|
2016-02-02 22:57:37 +01:00
|
|
|
// If we can determine a constraint on the value given conditions assumed by
|
|
|
|
// the program, intersect those constraints with BBLV
|
2016-09-12 23:46:58 +02:00
|
|
|
void LazyValueInfoImpl::intersectAssumeOrGuardBlockValueConstantRange(
|
2017-09-28 13:09:22 +02:00
|
|
|
Value *Val, ValueLatticeElement &BBLV, Instruction *BBI) {
|
2014-09-07 22:29:59 +02:00
|
|
|
BBI = BBI ? BBI : dyn_cast<Instruction>(Val);
|
|
|
|
if (!BBI)
|
|
|
|
return;
|
|
|
|
|
2020-03-25 20:51:01 +01:00
|
|
|
BasicBlock *BB = BBI->getParent();
|
2017-01-11 14:24:24 +01:00
|
|
|
for (auto &AssumeVH : AC->assumptionsFor(Val)) {
|
2016-12-19 09:22:17 +01:00
|
|
|
if (!AssumeVH)
|
2015-01-04 13:03:27 +01:00
|
|
|
continue;
|
2020-03-25 20:51:01 +01:00
|
|
|
|
|
|
|
// Only check assumes in the block of the context instruction. Other
|
|
|
|
// assumes will have already been taken into account when the value was
|
|
|
|
// propagated from predecessor blocks.
|
2016-12-19 09:22:17 +01:00
|
|
|
auto *I = cast<CallInst>(AssumeVH);
|
2020-03-25 20:51:01 +01:00
|
|
|
if (I->getParent() != BB || !isValidAssumeForContext(I, BBI))
|
2014-09-07 22:29:59 +02:00
|
|
|
continue;
|
|
|
|
|
2016-12-19 09:22:17 +01:00
|
|
|
BBLV = intersect(BBLV, getValueFromCondition(Val, I->getArgOperand(0)));
|
2014-09-07 22:29:59 +02:00
|
|
|
}
|
2016-08-12 17:52:23 +02:00
|
|
|
|
|
|
|
// If guards are not used in the module, don't spend time looking for them
|
Reapply [LVI] Normalize pointer behavior
This got reverted because a dependency was reverted. It has since
been reapplied, so reapply this as well.
-----
Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.
The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.
This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this more powerful than the previous implementation as
a side-effect, and this does actually seem benefitial in practice.
Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.
I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.
Differential Revision: https://reviews.llvm.org/D69914
2019-12-04 20:51:31 +01:00
|
|
|
if (GuardDecl && !GuardDecl->use_empty() &&
|
|
|
|
BBI->getIterator() != BB->begin()) {
|
|
|
|
for (Instruction &I : make_range(std::next(BBI->getIterator().getReverse()),
|
|
|
|
BB->rend())) {
|
|
|
|
Value *Cond = nullptr;
|
|
|
|
if (match(&I, m_Intrinsic<Intrinsic::experimental_guard>(m_Value(Cond))))
|
|
|
|
BBLV = intersect(BBLV, getValueFromCondition(Val, Cond));
|
|
|
|
}
|
|
|
|
}
|
2016-08-12 17:52:23 +02:00
|
|
|
|
Reapply [LVI] Normalize pointer behavior
This got reverted because a dependency was reverted. It has since
been reapplied, so reapply this as well.
-----
Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.
The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.
This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this more powerful than the previous implementation as
a side-effect, and this does actually seem benefitial in practice.
Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.
I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.
Differential Revision: https://reviews.llvm.org/D69914
2019-12-04 20:51:31 +01:00
|
|
|
if (BBLV.isOverdefined()) {
|
|
|
|
// Check whether we're checking at the terminator, and the pointer has
|
|
|
|
// been dereferenced in this block.
|
|
|
|
PointerType *PTy = dyn_cast<PointerType>(Val->getType());
|
|
|
|
if (PTy && BB->getTerminator() == BBI &&
|
|
|
|
isNonNullAtEndOfBlock(Val, BB))
|
|
|
|
BBLV = ValueLatticeElement::getNot(ConstantPointerNull::get(PTy));
|
2016-08-12 17:52:23 +02:00
|
|
|
}
|
2014-09-07 22:29:59 +02:00
|
|
|
}
|
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> LazyValueInfoImpl::solveBlockValueSelect(
|
|
|
|
SelectInst *SI, BasicBlock *BB) {
|
2016-02-01 23:57:53 +01:00
|
|
|
// Recurse on our inputs if needed
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> OptTrueVal =
|
|
|
|
getBlockValue(SI->getTrueValue(), BB);
|
|
|
|
if (!OptTrueVal)
|
|
|
|
return None;
|
|
|
|
ValueLatticeElement &TrueVal = *OptTrueVal;
|
2020-03-24 20:31:13 +01:00
|
|
|
|
2016-02-01 23:57:53 +01:00
|
|
|
// If we hit overdefined, don't ask more queries. We want to avoid poisoning
|
|
|
|
// extra slots in the table if we can.
|
2020-04-09 21:13:03 +02:00
|
|
|
if (TrueVal.isOverdefined())
|
|
|
|
return ValueLatticeElement::getOverdefined();
|
2016-02-01 23:57:53 +01:00
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> OptFalseVal =
|
|
|
|
getBlockValue(SI->getFalseValue(), BB);
|
|
|
|
if (!OptFalseVal)
|
|
|
|
return None;
|
|
|
|
ValueLatticeElement &FalseVal = *OptFalseVal;
|
2020-03-24 20:31:13 +01:00
|
|
|
|
2016-02-01 23:57:53 +01:00
|
|
|
// If we hit overdefined, don't ask more queries. We want to avoid poisoning
|
|
|
|
// extra slots in the table if we can.
|
2020-04-09 21:13:03 +02:00
|
|
|
if (FalseVal.isOverdefined())
|
|
|
|
return ValueLatticeElement::getOverdefined();
|
2016-02-01 23:57:53 +01:00
|
|
|
|
2016-02-26 23:53:59 +01:00
|
|
|
if (TrueVal.isConstantRange() && FalseVal.isConstantRange()) {
|
2017-05-06 05:35:15 +02:00
|
|
|
const ConstantRange &TrueCR = TrueVal.getConstantRange();
|
|
|
|
const ConstantRange &FalseCR = FalseVal.getConstantRange();
|
2016-02-26 23:53:59 +01:00
|
|
|
Value *LHS = nullptr;
|
|
|
|
Value *RHS = nullptr;
|
|
|
|
SelectPatternResult SPR = matchSelectPattern(SI, LHS, RHS);
|
|
|
|
// Is this a min specifically of our two inputs? (Avoid the risk of
|
|
|
|
// ValueTracking getting smarter looking back past our immediate inputs.)
|
|
|
|
if (SelectPatternResult::isMinOrMax(SPR.Flavor) &&
|
|
|
|
LHS == SI->getTrueValue() && RHS == SI->getFalseValue()) {
|
2016-12-06 03:54:16 +01:00
|
|
|
ConstantRange ResultCR = [&]() {
|
|
|
|
switch (SPR.Flavor) {
|
|
|
|
default:
|
|
|
|
llvm_unreachable("unexpected minmax type!");
|
|
|
|
case SPF_SMIN: /// Signed minimum
|
|
|
|
return TrueCR.smin(FalseCR);
|
|
|
|
case SPF_UMIN: /// Unsigned minimum
|
|
|
|
return TrueCR.umin(FalseCR);
|
|
|
|
case SPF_SMAX: /// Signed maximum
|
|
|
|
return TrueCR.smax(FalseCR);
|
|
|
|
case SPF_UMAX: /// Unsigned maximum
|
|
|
|
return TrueCR.umax(FalseCR);
|
|
|
|
};
|
|
|
|
}();
|
2020-04-09 21:13:03 +02:00
|
|
|
return ValueLatticeElement::getRange(
|
[ValueLattice] Distinguish between constant ranges with/without undef.
This patch updates ValueLattice to distinguish between ranges that are
guaranteed to not include undef and ranges that may include undef.
A constant range guaranteed to not contain undef can be used to simplify
instructions to arbitrary values. A constant range that may contain
undef can only be used to simplify to a constant. If the value can be
undef, it might take a value outside the range. For example, consider
the snipped below
define i32 @f(i32 %a, i1 %c) {
br i1 %c, label %true, label %false
true:
%a.255 = and i32 %a, 255
br label %exit
false:
br label %exit
exit:
%p = phi i32 [ %a.255, %true ], [ undef, %false ]
%f.1 = icmp eq i32 %p, 300
call void @use(i1 %f.1)
%res = and i32 %p, 255
ret i32 %res
}
In the exit block, %p would be a constant range [0, 256) including undef as
%p could be undef. We can use the range information to replace %f.1 with
false because we remove the compare, effectively forcing the use of the
constant to be != 300. We cannot replace %res with %p however, because
if %a would be undef %cond may be true but the second use might not be
< 256.
Currently LazyValueInfo uses the new behavior just when simplifying AND
instructions and does not distinguish between constant ranges with and
without undef otherwise. I think we should address the remaining issues
in LVI incrementally.
Reviewers: efriedma, reames, aqjune, jdoerfert, sstefan1
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D76931
2020-03-31 12:10:00 +02:00
|
|
|
ResultCR, TrueVal.isConstantRangeIncludingUndef() |
|
|
|
|
FalseVal.isConstantRangeIncludingUndef());
|
2016-02-26 23:53:59 +01:00
|
|
|
}
|
2016-07-04 03:26:33 +02:00
|
|
|
|
2019-05-14 20:53:47 +02:00
|
|
|
if (SPR.Flavor == SPF_ABS) {
|
2020-04-09 21:13:03 +02:00
|
|
|
if (LHS == SI->getTrueValue())
|
|
|
|
return ValueLatticeElement::getRange(
|
[ValueLattice] Distinguish between constant ranges with/without undef.
This patch updates ValueLattice to distinguish between ranges that are
guaranteed to not include undef and ranges that may include undef.
A constant range guaranteed to not contain undef can be used to simplify
instructions to arbitrary values. A constant range that may contain
undef can only be used to simplify to a constant. If the value can be
undef, it might take a value outside the range. For example, consider
the snipped below
define i32 @f(i32 %a, i1 %c) {
br i1 %c, label %true, label %false
true:
%a.255 = and i32 %a, 255
br label %exit
false:
br label %exit
exit:
%p = phi i32 [ %a.255, %true ], [ undef, %false ]
%f.1 = icmp eq i32 %p, 300
call void @use(i1 %f.1)
%res = and i32 %p, 255
ret i32 %res
}
In the exit block, %p would be a constant range [0, 256) including undef as
%p could be undef. We can use the range information to replace %f.1 with
false because we remove the compare, effectively forcing the use of the
constant to be != 300. We cannot replace %res with %p however, because
if %a would be undef %cond may be true but the second use might not be
< 256.
Currently LazyValueInfo uses the new behavior just when simplifying AND
instructions and does not distinguish between constant ranges with and
without undef otherwise. I think we should address the remaining issues
in LVI incrementally.
Reviewers: efriedma, reames, aqjune, jdoerfert, sstefan1
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D76931
2020-03-31 12:10:00 +02:00
|
|
|
TrueCR.abs(), TrueVal.isConstantRangeIncludingUndef());
|
2020-04-09 21:13:03 +02:00
|
|
|
if (LHS == SI->getFalseValue())
|
|
|
|
return ValueLatticeElement::getRange(
|
[ValueLattice] Distinguish between constant ranges with/without undef.
This patch updates ValueLattice to distinguish between ranges that are
guaranteed to not include undef and ranges that may include undef.
A constant range guaranteed to not contain undef can be used to simplify
instructions to arbitrary values. A constant range that may contain
undef can only be used to simplify to a constant. If the value can be
undef, it might take a value outside the range. For example, consider
the snipped below
define i32 @f(i32 %a, i1 %c) {
br i1 %c, label %true, label %false
true:
%a.255 = and i32 %a, 255
br label %exit
false:
br label %exit
exit:
%p = phi i32 [ %a.255, %true ], [ undef, %false ]
%f.1 = icmp eq i32 %p, 300
call void @use(i1 %f.1)
%res = and i32 %p, 255
ret i32 %res
}
In the exit block, %p would be a constant range [0, 256) including undef as
%p could be undef. We can use the range information to replace %f.1 with
false because we remove the compare, effectively forcing the use of the
constant to be != 300. We cannot replace %res with %p however, because
if %a would be undef %cond may be true but the second use might not be
< 256.
Currently LazyValueInfo uses the new behavior just when simplifying AND
instructions and does not distinguish between constant ranges with and
without undef otherwise. I think we should address the remaining issues
in LVI incrementally.
Reviewers: efriedma, reames, aqjune, jdoerfert, sstefan1
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D76931
2020-03-31 12:10:00 +02:00
|
|
|
FalseCR.abs(), FalseVal.isConstantRangeIncludingUndef());
|
2019-05-14 20:53:47 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (SPR.Flavor == SPF_NABS) {
|
|
|
|
ConstantRange Zero(APInt::getNullValue(TrueCR.getBitWidth()));
|
2020-04-09 21:13:03 +02:00
|
|
|
if (LHS == SI->getTrueValue())
|
|
|
|
return ValueLatticeElement::getRange(
|
[ValueLattice] Distinguish between constant ranges with/without undef.
This patch updates ValueLattice to distinguish between ranges that are
guaranteed to not include undef and ranges that may include undef.
A constant range guaranteed to not contain undef can be used to simplify
instructions to arbitrary values. A constant range that may contain
undef can only be used to simplify to a constant. If the value can be
undef, it might take a value outside the range. For example, consider
the snipped below
define i32 @f(i32 %a, i1 %c) {
br i1 %c, label %true, label %false
true:
%a.255 = and i32 %a, 255
br label %exit
false:
br label %exit
exit:
%p = phi i32 [ %a.255, %true ], [ undef, %false ]
%f.1 = icmp eq i32 %p, 300
call void @use(i1 %f.1)
%res = and i32 %p, 255
ret i32 %res
}
In the exit block, %p would be a constant range [0, 256) including undef as
%p could be undef. We can use the range information to replace %f.1 with
false because we remove the compare, effectively forcing the use of the
constant to be != 300. We cannot replace %res with %p however, because
if %a would be undef %cond may be true but the second use might not be
< 256.
Currently LazyValueInfo uses the new behavior just when simplifying AND
instructions and does not distinguish between constant ranges with and
without undef otherwise. I think we should address the remaining issues
in LVI incrementally.
Reviewers: efriedma, reames, aqjune, jdoerfert, sstefan1
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D76931
2020-03-31 12:10:00 +02:00
|
|
|
Zero.sub(TrueCR.abs()), FalseVal.isConstantRangeIncludingUndef());
|
2020-04-09 21:13:03 +02:00
|
|
|
if (LHS == SI->getFalseValue())
|
|
|
|
return ValueLatticeElement::getRange(
|
[ValueLattice] Distinguish between constant ranges with/without undef.
This patch updates ValueLattice to distinguish between ranges that are
guaranteed to not include undef and ranges that may include undef.
A constant range guaranteed to not contain undef can be used to simplify
instructions to arbitrary values. A constant range that may contain
undef can only be used to simplify to a constant. If the value can be
undef, it might take a value outside the range. For example, consider
the snipped below
define i32 @f(i32 %a, i1 %c) {
br i1 %c, label %true, label %false
true:
%a.255 = and i32 %a, 255
br label %exit
false:
br label %exit
exit:
%p = phi i32 [ %a.255, %true ], [ undef, %false ]
%f.1 = icmp eq i32 %p, 300
call void @use(i1 %f.1)
%res = and i32 %p, 255
ret i32 %res
}
In the exit block, %p would be a constant range [0, 256) including undef as
%p could be undef. We can use the range information to replace %f.1 with
false because we remove the compare, effectively forcing the use of the
constant to be != 300. We cannot replace %res with %p however, because
if %a would be undef %cond may be true but the second use might not be
< 256.
Currently LazyValueInfo uses the new behavior just when simplifying AND
instructions and does not distinguish between constant ranges with and
without undef otherwise. I think we should address the remaining issues
in LVI incrementally.
Reviewers: efriedma, reames, aqjune, jdoerfert, sstefan1
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D76931
2020-03-31 12:10:00 +02:00
|
|
|
Zero.sub(FalseCR.abs()), FalseVal.isConstantRangeIncludingUndef());
|
2019-05-14 20:53:47 +02:00
|
|
|
}
|
2016-02-26 23:53:59 +01:00
|
|
|
}
|
|
|
|
|
2016-02-12 01:09:18 +01:00
|
|
|
// Can we constrain the facts about the true and false values by using the
|
|
|
|
// condition itself? This shows up with idioms like e.g. select(a > 5, a, 5).
|
|
|
|
// TODO: We could potentially refine an overdefined true value above.
|
2016-08-02 18:20:48 +02:00
|
|
|
Value *Cond = SI->getCondition();
|
2016-08-10 15:38:07 +02:00
|
|
|
TrueVal = intersect(TrueVal,
|
|
|
|
getValueFromCondition(SI->getTrueValue(), Cond, true));
|
|
|
|
FalseVal = intersect(FalseVal,
|
|
|
|
getValueFromCondition(SI->getFalseValue(), Cond, false));
|
2016-08-02 18:20:48 +02:00
|
|
|
|
|
|
|
// Handle clamp idioms such as:
|
|
|
|
// %24 = constantrange<0, 17>
|
|
|
|
// %39 = icmp eq i32 %24, 0
|
|
|
|
// %40 = add i32 %24, -1
|
|
|
|
// %siv.next = select i1 %39, i32 16, i32 %40
|
|
|
|
// %siv.next = constantrange<0, 17> not <-1, 17>
|
|
|
|
// In general, this can handle any clamp idiom which tests the edge
|
|
|
|
// condition via an equality or inequality.
|
|
|
|
if (auto *ICI = dyn_cast<ICmpInst>(Cond)) {
|
2016-02-26 23:53:59 +01:00
|
|
|
ICmpInst::Predicate Pred = ICI->getPredicate();
|
|
|
|
Value *A = ICI->getOperand(0);
|
|
|
|
if (ConstantInt *CIBase = dyn_cast<ConstantInt>(ICI->getOperand(1))) {
|
|
|
|
auto addConstants = [](ConstantInt *A, ConstantInt *B) {
|
|
|
|
assert(A->getType() == B->getType());
|
|
|
|
return ConstantInt::get(A->getType(), A->getValue() + B->getValue());
|
|
|
|
};
|
|
|
|
// See if either input is A + C2, subject to the constraint from the
|
|
|
|
// condition that A != C when that input is used. We can assume that
|
|
|
|
// that input doesn't include C + C2.
|
|
|
|
ConstantInt *CIAdded;
|
|
|
|
switch (Pred) {
|
2016-02-27 06:18:30 +01:00
|
|
|
default: break;
|
2016-02-26 23:53:59 +01:00
|
|
|
case ICmpInst::ICMP_EQ:
|
|
|
|
if (match(SI->getFalseValue(), m_Add(m_Specific(A),
|
|
|
|
m_ConstantInt(CIAdded)))) {
|
|
|
|
auto ResNot = addConstants(CIBase, CIAdded);
|
|
|
|
FalseVal = intersect(FalseVal,
|
2017-09-28 13:09:22 +02:00
|
|
|
ValueLatticeElement::getNot(ResNot));
|
2016-02-26 23:53:59 +01:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
case ICmpInst::ICMP_NE:
|
|
|
|
if (match(SI->getTrueValue(), m_Add(m_Specific(A),
|
|
|
|
m_ConstantInt(CIAdded)))) {
|
|
|
|
auto ResNot = addConstants(CIBase, CIAdded);
|
|
|
|
TrueVal = intersect(TrueVal,
|
2017-09-28 13:09:22 +02:00
|
|
|
ValueLatticeElement::getNot(ResNot));
|
2016-02-26 23:53:59 +01:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
};
|
|
|
|
}
|
|
|
|
}
|
2016-07-04 03:26:33 +02:00
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
ValueLatticeElement Result = TrueVal;
|
2020-04-14 13:32:43 +02:00
|
|
|
Result.mergeIn(FalseVal);
|
2020-04-09 21:13:03 +02:00
|
|
|
return Result;
|
2016-02-01 23:57:53 +01:00
|
|
|
}
|
|
|
|
|
2020-07-25 16:32:22 +02:00
|
|
|
Optional<ConstantRange> LazyValueInfoImpl::getRangeFor(Value *V,
|
|
|
|
Instruction *CxtI,
|
|
|
|
BasicBlock *BB) {
|
|
|
|
Optional<ValueLatticeElement> OptVal = getBlockValue(V, BB);
|
2020-04-09 21:13:03 +02:00
|
|
|
if (!OptVal)
|
2020-03-24 20:31:13 +01:00
|
|
|
return None;
|
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
ValueLatticeElement &Val = *OptVal;
|
2020-07-25 16:32:22 +02:00
|
|
|
intersectAssumeOrGuardBlockValueConstantRange(V, Val, CxtI);
|
2020-03-24 20:31:13 +01:00
|
|
|
if (Val.isConstantRange())
|
|
|
|
return Val.getConstantRange();
|
2018-11-21 06:24:12 +01:00
|
|
|
|
2020-07-25 16:32:22 +02:00
|
|
|
const unsigned OperandBitWidth = DL.getTypeSizeInBits(V->getType());
|
2020-03-24 20:31:13 +01:00
|
|
|
return ConstantRange::getFull(OperandBitWidth);
|
2018-11-21 06:24:12 +01:00
|
|
|
}
|
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> LazyValueInfoImpl::solveBlockValueCast(
|
|
|
|
CastInst *CI, BasicBlock *BB) {
|
|
|
|
// Without knowing how wide the input is, we can't analyze it in any useful
|
|
|
|
// way.
|
|
|
|
if (!CI->getOperand(0)->getType()->isSized())
|
|
|
|
return ValueLatticeElement::getOverdefined();
|
2016-04-27 01:27:33 +02:00
|
|
|
|
|
|
|
// Filter out casts we don't know how to reason about before attempting to
|
|
|
|
// recurse on our operand. This can cut a long search short if we know we're
|
|
|
|
// not going to be able to get any useful information anways.
|
2017-06-03 09:47:08 +02:00
|
|
|
switch (CI->getOpcode()) {
|
2016-04-27 01:27:33 +02:00
|
|
|
case Instruction::Trunc:
|
|
|
|
case Instruction::SExt:
|
|
|
|
case Instruction::ZExt:
|
|
|
|
case Instruction::BitCast:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
// Unhandled instructions are overdefined.
|
2018-05-14 14:53:11 +02:00
|
|
|
LLVM_DEBUG(dbgs() << " compute BB '" << BB->getName()
|
|
|
|
<< "' - overdefined (unknown cast).\n");
|
2020-04-09 21:13:03 +02:00
|
|
|
return ValueLatticeElement::getOverdefined();
|
2016-04-27 01:27:33 +02:00
|
|
|
}
|
|
|
|
|
2016-04-26 23:48:16 +02:00
|
|
|
// Figure out the range of the LHS. If that fails, we still apply the
|
|
|
|
// transfer rule on the full set since we may be able to locally infer
|
|
|
|
// interesting facts.
|
2020-07-25 16:32:22 +02:00
|
|
|
Optional<ConstantRange> LHSRes = getRangeFor(CI->getOperand(0), CI, BB);
|
2018-11-21 06:24:12 +01:00
|
|
|
if (!LHSRes.hasValue())
|
|
|
|
// More work to do before applying this transfer rule.
|
2020-04-09 21:13:03 +02:00
|
|
|
return None;
|
|
|
|
const ConstantRange &LHSRange = LHSRes.getValue();
|
2016-04-25 20:30:31 +02:00
|
|
|
|
2017-06-03 09:47:14 +02:00
|
|
|
const unsigned ResultBitWidth = CI->getType()->getIntegerBitWidth();
|
2016-04-25 20:30:31 +02:00
|
|
|
|
|
|
|
// NOTE: We're currently limited by the set of operations that ConstantRange
|
|
|
|
// can evaluate symbolically. Enhancing that set will allows us to analyze
|
|
|
|
// more definitions.
|
2020-04-09 21:13:03 +02:00
|
|
|
return ValueLatticeElement::getRange(LHSRange.castOp(CI->getOpcode(),
|
2017-09-28 13:09:22 +02:00
|
|
|
ResultBitWidth));
|
2016-04-25 20:30:31 +02:00
|
|
|
}
|
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> LazyValueInfoImpl::solveBlockValueBinaryOpImpl(
|
|
|
|
Instruction *I, BasicBlock *BB,
|
2019-05-25 11:53:37 +02:00
|
|
|
std::function<ConstantRange(const ConstantRange &,
|
|
|
|
const ConstantRange &)> OpFn) {
|
|
|
|
// Figure out the ranges of the operands. If that fails, use a
|
|
|
|
// conservative range, but apply the transfer rule anyways. This
|
|
|
|
// lets us pick up facts from expressions like "and i32 (call i32
|
|
|
|
// @foo()), 32"
|
2020-07-25 16:32:22 +02:00
|
|
|
Optional<ConstantRange> LHSRes = getRangeFor(I->getOperand(0), I, BB);
|
|
|
|
Optional<ConstantRange> RHSRes = getRangeFor(I->getOperand(1), I, BB);
|
2019-05-25 11:53:37 +02:00
|
|
|
if (!LHSRes.hasValue() || !RHSRes.hasValue())
|
|
|
|
// More work to do before applying this transfer rule.
|
2020-04-09 21:13:03 +02:00
|
|
|
return None;
|
2019-05-25 11:53:37 +02:00
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
const ConstantRange &LHSRange = LHSRes.getValue();
|
|
|
|
const ConstantRange &RHSRange = RHSRes.getValue();
|
|
|
|
return ValueLatticeElement::getRange(OpFn(LHSRange, RHSRange));
|
2019-05-25 11:53:37 +02:00
|
|
|
}
|
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> LazyValueInfoImpl::solveBlockValueBinaryOp(
|
|
|
|
BinaryOperator *BO, BasicBlock *BB) {
|
2017-06-02 18:33:13 +02:00
|
|
|
assert(BO->getOperand(0)->getType()->isSized() &&
|
2016-04-27 01:10:35 +02:00
|
|
|
"all operands to binary operators are sized");
|
2019-06-04 18:24:09 +02:00
|
|
|
if (BO->getOpcode() == Instruction::Xor) {
|
|
|
|
// Xor is the only operation not supported by ConstantRange::binaryOp().
|
2018-05-14 14:53:11 +02:00
|
|
|
LLVM_DEBUG(dbgs() << " compute BB '" << BB->getName()
|
|
|
|
<< "' - overdefined (unknown binary operator).\n");
|
2020-04-09 21:13:03 +02:00
|
|
|
return ValueLatticeElement::getOverdefined();
|
2019-06-04 18:24:09 +02:00
|
|
|
}
|
|
|
|
|
2019-10-23 15:56:04 +02:00
|
|
|
if (auto *OBO = dyn_cast<OverflowingBinaryOperator>(BO)) {
|
|
|
|
unsigned NoWrapKind = 0;
|
|
|
|
if (OBO->hasNoUnsignedWrap())
|
|
|
|
NoWrapKind |= OverflowingBinaryOperator::NoUnsignedWrap;
|
|
|
|
if (OBO->hasNoSignedWrap())
|
|
|
|
NoWrapKind |= OverflowingBinaryOperator::NoSignedWrap;
|
|
|
|
|
|
|
|
return solveBlockValueBinaryOpImpl(
|
2020-04-09 21:13:03 +02:00
|
|
|
BO, BB,
|
2019-10-23 15:56:04 +02:00
|
|
|
[BO, NoWrapKind](const ConstantRange &CR1, const ConstantRange &CR2) {
|
|
|
|
return CR1.overflowingBinaryOp(BO->getOpcode(), CR2, NoWrapKind);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
return solveBlockValueBinaryOpImpl(
|
2020-04-09 21:13:03 +02:00
|
|
|
BO, BB, [BO](const ConstantRange &CR1, const ConstantRange &CR2) {
|
2019-06-04 18:24:09 +02:00
|
|
|
return CR1.binaryOp(BO->getOpcode(), CR2);
|
|
|
|
});
|
2009-11-11 23:48:44 +01:00
|
|
|
}
|
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement>
|
|
|
|
LazyValueInfoImpl::solveBlockValueOverflowIntrinsic(WithOverflowInst *WO,
|
|
|
|
BasicBlock *BB) {
|
|
|
|
return solveBlockValueBinaryOpImpl(
|
|
|
|
WO, BB, [WO](const ConstantRange &CR1, const ConstantRange &CR2) {
|
2019-05-25 11:53:45 +02:00
|
|
|
return CR1.binaryOp(WO->getBinaryOp(), CR2);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> LazyValueInfoImpl::solveBlockValueIntrinsic(
|
|
|
|
IntrinsicInst *II, BasicBlock *BB) {
|
2020-07-25 16:21:55 +02:00
|
|
|
if (!ConstantRange::isIntrinsicSupported(II->getIntrinsicID())) {
|
|
|
|
LLVM_DEBUG(dbgs() << " compute BB '" << BB->getName()
|
|
|
|
<< "' - overdefined (unknown intrinsic).\n");
|
|
|
|
return ValueLatticeElement::getOverdefined();
|
|
|
|
}
|
2019-10-23 17:05:05 +02:00
|
|
|
|
2020-07-25 16:21:55 +02:00
|
|
|
SmallVector<ConstantRange, 2> OpRanges;
|
|
|
|
for (Value *Op : II->args()) {
|
|
|
|
Optional<ConstantRange> Range = getRangeFor(Op, II, BB);
|
|
|
|
if (!Range)
|
|
|
|
return None;
|
|
|
|
OpRanges.push_back(*Range);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ValueLatticeElement::getRange(
|
|
|
|
ConstantRange::intrinsic(II->getIntrinsicID(), OpRanges));
|
2019-05-25 18:44:14 +02:00
|
|
|
}
|
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> LazyValueInfoImpl::solveBlockValueExtractValue(
|
|
|
|
ExtractValueInst *EVI, BasicBlock *BB) {
|
2019-08-31 11:58:50 +02:00
|
|
|
if (auto *WO = dyn_cast<WithOverflowInst>(EVI->getAggregateOperand()))
|
|
|
|
if (EVI->getNumIndices() == 1 && *EVI->idx_begin() == 0)
|
2020-04-09 21:13:03 +02:00
|
|
|
return solveBlockValueOverflowIntrinsic(WO, BB);
|
2019-08-31 11:58:50 +02:00
|
|
|
|
2019-09-07 14:03:59 +02:00
|
|
|
// Handle extractvalue of insertvalue to allow further simplification
|
|
|
|
// based on replaced with.overflow intrinsics.
|
|
|
|
if (Value *V = SimplifyExtractValueInst(
|
|
|
|
EVI->getAggregateOperand(), EVI->getIndices(),
|
2020-03-24 20:31:13 +01:00
|
|
|
EVI->getModule()->getDataLayout()))
|
2020-04-09 21:13:03 +02:00
|
|
|
return getBlockValue(V, BB);
|
2019-09-07 14:03:59 +02:00
|
|
|
|
2019-08-31 11:58:50 +02:00
|
|
|
LLVM_DEBUG(dbgs() << " compute BB '" << BB->getName()
|
|
|
|
<< "' - overdefined (unknown extractvalue).\n");
|
2020-04-09 21:13:03 +02:00
|
|
|
return ValueLatticeElement::getOverdefined();
|
2019-08-31 11:58:50 +02:00
|
|
|
}
|
|
|
|
|
2020-06-28 14:47:29 +02:00
|
|
|
static bool matchICmpOperand(const APInt *&Offset, Value *LHS, Value *Val,
|
|
|
|
ICmpInst::Predicate Pred) {
|
2020-06-28 15:04:02 +02:00
|
|
|
if (LHS == Val)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// Handle range checking idiom produced by InstCombine. We will subtract the
|
|
|
|
// offset from the allowed range for RHS in this case.
|
|
|
|
if (match(LHS, m_Add(m_Specific(Val), m_APInt(Offset))))
|
|
|
|
return true;
|
|
|
|
|
2020-06-28 14:47:29 +02:00
|
|
|
// If (x | y) < C, then (x < C) && (y < C).
|
|
|
|
if (match(LHS, m_c_Or(m_Specific(Val), m_Value())) &&
|
|
|
|
(Pred == ICmpInst::ICMP_ULT || Pred == ICmpInst::ICMP_ULE))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// If (x & y) > C, then (x > C) && (y > C).
|
|
|
|
if (match(LHS, m_c_And(m_Specific(Val), m_Value())) &&
|
|
|
|
(Pred == ICmpInst::ICMP_UGT || Pred == ICmpInst::ICMP_UGE))
|
|
|
|
return true;
|
|
|
|
|
2020-06-28 15:04:02 +02:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2020-09-20 20:46:51 +02:00
|
|
|
/// Get value range for a "(Val + Offset) Pred RHS" condition.
|
|
|
|
static ValueLatticeElement getValueFromSimpleICmpCondition(
|
|
|
|
CmpInst::Predicate Pred, Value *RHS, const APInt *Offset) {
|
|
|
|
ConstantRange RHSRange(RHS->getType()->getIntegerBitWidth(),
|
|
|
|
/*isFullSet=*/true);
|
|
|
|
if (ConstantInt *CI = dyn_cast<ConstantInt>(RHS))
|
|
|
|
RHSRange = ConstantRange(CI->getValue());
|
|
|
|
else if (Instruction *I = dyn_cast<Instruction>(RHS))
|
|
|
|
if (auto *Ranges = I->getMetadata(LLVMContext::MD_range))
|
|
|
|
RHSRange = getConstantRangeFromMetadata(*Ranges);
|
|
|
|
|
|
|
|
ConstantRange TrueValues =
|
|
|
|
ConstantRange::makeAllowedICmpRegion(Pred, RHSRange);
|
|
|
|
|
|
|
|
if (Offset)
|
|
|
|
TrueValues = TrueValues.subtract(*Offset);
|
|
|
|
|
|
|
|
return ValueLatticeElement::getRange(std::move(TrueValues));
|
|
|
|
}
|
|
|
|
|
2017-09-28 13:09:22 +02:00
|
|
|
static ValueLatticeElement getValueFromICmpCondition(Value *Val, ICmpInst *ICI,
|
|
|
|
bool isTrueDest) {
|
2016-08-08 16:08:37 +02:00
|
|
|
Value *LHS = ICI->getOperand(0);
|
|
|
|
Value *RHS = ICI->getOperand(1);
|
2020-06-28 15:04:02 +02:00
|
|
|
|
|
|
|
// Get the predicate that must hold along the considered edge.
|
|
|
|
CmpInst::Predicate EdgePred =
|
|
|
|
isTrueDest ? ICI->getPredicate() : ICI->getInversePredicate();
|
2016-08-08 16:08:37 +02:00
|
|
|
|
|
|
|
if (isa<Constant>(RHS)) {
|
|
|
|
if (ICI->isEquality() && LHS == Val) {
|
2020-06-28 15:04:02 +02:00
|
|
|
if (EdgePred == ICmpInst::ICMP_EQ)
|
2017-09-28 13:09:22 +02:00
|
|
|
return ValueLatticeElement::get(cast<Constant>(RHS));
|
2020-03-14 17:50:09 +01:00
|
|
|
else if (!isa<UndefValue>(RHS))
|
2017-09-28 13:09:22 +02:00
|
|
|
return ValueLatticeElement::getNot(cast<Constant>(RHS));
|
2014-09-07 22:29:59 +02:00
|
|
|
}
|
2016-08-09 16:50:08 +02:00
|
|
|
}
|
2014-09-07 22:29:59 +02:00
|
|
|
|
2016-08-09 16:50:08 +02:00
|
|
|
if (!Val->getType()->isIntegerTy())
|
2017-09-28 13:09:22 +02:00
|
|
|
return ValueLatticeElement::getOverdefined();
|
2016-08-08 16:33:11 +02:00
|
|
|
|
2020-06-28 15:04:02 +02:00
|
|
|
const APInt *Offset = nullptr;
|
2020-09-20 20:46:51 +02:00
|
|
|
if (matchICmpOperand(Offset, LHS, Val, EdgePred))
|
|
|
|
return getValueFromSimpleICmpCondition(EdgePred, RHS, Offset);
|
2016-07-04 03:26:33 +02:00
|
|
|
|
2020-09-20 20:46:51 +02:00
|
|
|
CmpInst::Predicate SwappedPred = CmpInst::getSwappedPredicate(EdgePred);
|
|
|
|
if (matchICmpOperand(Offset, RHS, Val, SwappedPred))
|
|
|
|
return getValueFromSimpleICmpCondition(SwappedPred, LHS, Offset);
|
2020-06-28 15:04:02 +02:00
|
|
|
|
2020-09-20 21:07:52 +02:00
|
|
|
// If (Val & Mask) == C then all the masked bits are known and we can compute
|
|
|
|
// a value range based on that.
|
|
|
|
const APInt *Mask, *C;
|
|
|
|
if (EdgePred == ICmpInst::ICMP_EQ &&
|
|
|
|
match(LHS, m_And(m_Specific(Val), m_APInt(Mask))) &&
|
|
|
|
match(RHS, m_APInt(C))) {
|
|
|
|
KnownBits Known;
|
|
|
|
Known.Zero = ~*C & *Mask;
|
|
|
|
Known.One = *C & *Mask;
|
|
|
|
return ValueLatticeElement::getRange(
|
|
|
|
ConstantRange::fromKnownBits(Known, /*IsSigned*/ false));
|
|
|
|
}
|
|
|
|
|
2020-09-20 20:46:51 +02:00
|
|
|
return ValueLatticeElement::getOverdefined();
|
2014-09-07 22:29:59 +02:00
|
|
|
}
|
|
|
|
|
2019-04-17 18:57:42 +02:00
|
|
|
// Handle conditions of the form
|
|
|
|
// extractvalue(op.with.overflow(%x, C), 1).
|
|
|
|
static ValueLatticeElement getValueFromOverflowCondition(
|
|
|
|
Value *Val, WithOverflowInst *WO, bool IsTrueDest) {
|
|
|
|
// TODO: This only works with a constant RHS for now. We could also compute
|
|
|
|
// the range of the RHS, but this doesn't fit into the current structure of
|
|
|
|
// the edge value calculation.
|
|
|
|
const APInt *C;
|
|
|
|
if (WO->getLHS() != Val || !match(WO->getRHS(), m_APInt(C)))
|
|
|
|
return ValueLatticeElement::getOverdefined();
|
|
|
|
|
|
|
|
// Calculate the possible values of %x for which no overflow occurs.
|
2019-04-28 17:40:56 +02:00
|
|
|
ConstantRange NWR = ConstantRange::makeExactNoWrapRegion(
|
|
|
|
WO->getBinaryOp(), *C, WO->getNoWrapKind());
|
2019-04-17 18:57:42 +02:00
|
|
|
|
|
|
|
// If overflow is false, %x is constrained to NWR. If overflow is true, %x is
|
|
|
|
// constrained to it's inverse (all values that might cause overflow).
|
|
|
|
if (IsTrueDest)
|
|
|
|
NWR = NWR.inverse();
|
|
|
|
return ValueLatticeElement::getRange(NWR);
|
|
|
|
}
|
|
|
|
|
2017-09-28 13:09:22 +02:00
|
|
|
static ValueLatticeElement
|
2016-08-10 17:13:15 +02:00
|
|
|
getValueFromCondition(Value *Val, Value *Cond, bool isTrueDest,
|
2020-03-21 14:54:46 +01:00
|
|
|
SmallDenseMap<Value*, ValueLatticeElement> &Visited);
|
2016-08-10 17:13:15 +02:00
|
|
|
|
2017-09-28 13:09:22 +02:00
|
|
|
static ValueLatticeElement
|
2016-08-10 17:13:15 +02:00
|
|
|
getValueFromConditionImpl(Value *Val, Value *Cond, bool isTrueDest,
|
2020-03-21 14:54:46 +01:00
|
|
|
SmallDenseMap<Value*, ValueLatticeElement> &Visited) {
|
2016-08-10 17:13:15 +02:00
|
|
|
if (ICmpInst *ICI = dyn_cast<ICmpInst>(Cond))
|
|
|
|
return getValueFromICmpCondition(Val, ICI, isTrueDest);
|
|
|
|
|
2019-04-17 18:57:42 +02:00
|
|
|
if (auto *EVI = dyn_cast<ExtractValueInst>(Cond))
|
|
|
|
if (auto *WO = dyn_cast<WithOverflowInst>(EVI->getAggregateOperand()))
|
|
|
|
if (EVI->getNumIndices() == 1 && *EVI->idx_begin() == 1)
|
|
|
|
return getValueFromOverflowCondition(Val, WO, isTrueDest);
|
|
|
|
|
2020-12-22 21:20:56 +01:00
|
|
|
Value *L, *R;
|
2021-01-01 16:32:19 +01:00
|
|
|
bool IsAnd;
|
|
|
|
if (match(Cond, m_LogicalAnd(m_Value(L), m_Value(R))))
|
|
|
|
IsAnd = true;
|
|
|
|
else if (match(Cond, m_LogicalOr(m_Value(L), m_Value(R))))
|
|
|
|
IsAnd = false;
|
|
|
|
else
|
2017-09-28 13:09:22 +02:00
|
|
|
return ValueLatticeElement::getOverdefined();
|
2016-08-10 17:13:15 +02:00
|
|
|
|
[LazyValueInfo] PR33357 prevent infinite recursion on BinaryOperator
Summary:
It is possible for LVI to encounter instructions that are not in valid
SSA form and reference themselves. One example is the following:
%tmp4 = and i1 %tmp4, undef
Before this patch LVI would recurse until running out of stack memory
and crashed. This patch marks these self-referential instructions as
Overdefined and aborts analysis on the instruction.
Fixes https://bugs.llvm.org/show_bug.cgi?id=33357
Reviewers: craig.topper, anna, efriedma, dberlin, sebpop, kuhar
Reviewed by: dberlin
Subscribers: uabelho, spatel, a.elovikov, fhahn, eli.friedman, mzolotukhin, spop, evandro, davide, llvm-commits
Differential Revision: https://reviews.llvm.org/D34135
llvm-svn: 327432
2018-03-13 19:14:10 +01:00
|
|
|
// Prevent infinite recursion if Cond references itself as in this example:
|
|
|
|
// Cond: "%tmp4 = and i1 %tmp4, undef"
|
|
|
|
// BL: "%tmp4 = and i1 %tmp4, undef"
|
|
|
|
// BR: "i1 undef"
|
2020-12-22 21:20:56 +01:00
|
|
|
if (L == Cond || R == Cond)
|
[LazyValueInfo] PR33357 prevent infinite recursion on BinaryOperator
Summary:
It is possible for LVI to encounter instructions that are not in valid
SSA form and reference themselves. One example is the following:
%tmp4 = and i1 %tmp4, undef
Before this patch LVI would recurse until running out of stack memory
and crashed. This patch marks these self-referential instructions as
Overdefined and aborts analysis on the instruction.
Fixes https://bugs.llvm.org/show_bug.cgi?id=33357
Reviewers: craig.topper, anna, efriedma, dberlin, sebpop, kuhar
Reviewed by: dberlin
Subscribers: uabelho, spatel, a.elovikov, fhahn, eli.friedman, mzolotukhin, spop, evandro, davide, llvm-commits
Differential Revision: https://reviews.llvm.org/D34135
llvm-svn: 327432
2018-03-13 19:14:10 +01:00
|
|
|
return ValueLatticeElement::getOverdefined();
|
|
|
|
|
2021-01-01 16:32:19 +01:00
|
|
|
// if (L && R) -> intersect L and R
|
|
|
|
// if (!(L || R)) -> intersect L and R
|
|
|
|
// if (L || R) -> union L and R
|
|
|
|
// if (!(L && R)) -> union L and R
|
|
|
|
if (isTrueDest ^ IsAnd) {
|
|
|
|
ValueLatticeElement V = getValueFromCondition(Val, L, isTrueDest, Visited);
|
|
|
|
if (V.isOverdefined())
|
|
|
|
return V;
|
|
|
|
V.mergeIn(getValueFromCondition(Val, R, isTrueDest, Visited));
|
|
|
|
return V;
|
|
|
|
}
|
|
|
|
|
2020-12-22 21:20:56 +01:00
|
|
|
return intersect(getValueFromCondition(Val, L, isTrueDest, Visited),
|
|
|
|
getValueFromCondition(Val, R, isTrueDest, Visited));
|
2016-08-10 17:13:15 +02:00
|
|
|
}
|
|
|
|
|
2017-09-28 13:09:22 +02:00
|
|
|
static ValueLatticeElement
|
2016-08-10 17:13:15 +02:00
|
|
|
getValueFromCondition(Value *Val, Value *Cond, bool isTrueDest,
|
2020-03-21 14:54:46 +01:00
|
|
|
SmallDenseMap<Value*, ValueLatticeElement> &Visited) {
|
2016-08-10 17:13:15 +02:00
|
|
|
auto I = Visited.find(Cond);
|
|
|
|
if (I != Visited.end())
|
|
|
|
return I->second;
|
2016-08-12 17:08:15 +02:00
|
|
|
|
|
|
|
auto Result = getValueFromConditionImpl(Val, Cond, isTrueDest, Visited);
|
|
|
|
Visited[Cond] = Result;
|
|
|
|
return Result;
|
2016-08-10 17:13:15 +02:00
|
|
|
}
|
|
|
|
|
2017-09-28 13:09:22 +02:00
|
|
|
ValueLatticeElement getValueFromCondition(Value *Val, Value *Cond,
|
|
|
|
bool isTrueDest) {
|
2016-08-10 17:13:15 +02:00
|
|
|
assert(Cond && "precondition");
|
2020-03-21 14:54:46 +01:00
|
|
|
SmallDenseMap<Value*, ValueLatticeElement> Visited;
|
2016-08-10 17:13:15 +02:00
|
|
|
return getValueFromCondition(Val, Cond, isTrueDest, Visited);
|
|
|
|
}
|
|
|
|
|
2017-08-03 23:11:30 +02:00
|
|
|
// Return true if Usr has Op as an operand, otherwise false.
|
|
|
|
static bool usesOperand(User *Usr, Value *Op) {
|
2020-12-12 06:19:31 +01:00
|
|
|
return is_contained(Usr->operands(), Op);
|
2017-08-03 23:11:30 +02:00
|
|
|
}
|
|
|
|
|
2017-08-10 04:23:14 +02:00
|
|
|
// Return true if the instruction type of Val is supported by
|
2020-08-11 03:15:18 +02:00
|
|
|
// constantFoldUser(). Currently CastInst, BinaryOperator and FreezeInst only.
|
|
|
|
// Call this before calling constantFoldUser() to find out if it's even worth
|
|
|
|
// attempting to call it.
|
2017-08-10 04:23:14 +02:00
|
|
|
static bool isOperationFoldable(User *Usr) {
|
2020-08-11 03:15:18 +02:00
|
|
|
return isa<CastInst>(Usr) || isa<BinaryOperator>(Usr) || isa<FreezeInst>(Usr);
|
2017-08-10 04:23:14 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// Check if Usr can be simplified to an integer constant when the value of one
|
2017-08-03 23:11:30 +02:00
|
|
|
// of its operands Op is an integer constant OpConstVal. If so, return it as an
|
|
|
|
// lattice value range with a single element or otherwise return an overdefined
|
|
|
|
// lattice value.
|
2017-09-28 13:09:22 +02:00
|
|
|
static ValueLatticeElement constantFoldUser(User *Usr, Value *Op,
|
|
|
|
const APInt &OpConstVal,
|
|
|
|
const DataLayout &DL) {
|
2017-08-10 04:23:14 +02:00
|
|
|
assert(isOperationFoldable(Usr) && "Precondition");
|
2017-08-03 23:11:30 +02:00
|
|
|
Constant* OpConst = Constant::getIntegerValue(Op->getType(), OpConstVal);
|
2017-08-10 04:23:14 +02:00
|
|
|
// Check if Usr can be simplified to a constant.
|
|
|
|
if (auto *CI = dyn_cast<CastInst>(Usr)) {
|
2017-08-03 23:11:30 +02:00
|
|
|
assert(CI->getOperand(0) == Op && "Operand 0 isn't Op");
|
|
|
|
if (auto *C = dyn_cast_or_null<ConstantInt>(
|
|
|
|
SimplifyCastInst(CI->getOpcode(), OpConst,
|
|
|
|
CI->getDestTy(), DL))) {
|
2017-09-28 13:09:22 +02:00
|
|
|
return ValueLatticeElement::getRange(ConstantRange(C->getValue()));
|
2017-08-03 23:11:30 +02:00
|
|
|
}
|
2017-08-10 04:23:14 +02:00
|
|
|
} else if (auto *BO = dyn_cast<BinaryOperator>(Usr)) {
|
2017-08-03 23:11:30 +02:00
|
|
|
bool Op0Match = BO->getOperand(0) == Op;
|
|
|
|
bool Op1Match = BO->getOperand(1) == Op;
|
|
|
|
assert((Op0Match || Op1Match) &&
|
|
|
|
"Operand 0 nor Operand 1 isn't a match");
|
|
|
|
Value *LHS = Op0Match ? OpConst : BO->getOperand(0);
|
|
|
|
Value *RHS = Op1Match ? OpConst : BO->getOperand(1);
|
|
|
|
if (auto *C = dyn_cast_or_null<ConstantInt>(
|
|
|
|
SimplifyBinOp(BO->getOpcode(), LHS, RHS, DL))) {
|
2017-09-28 13:09:22 +02:00
|
|
|
return ValueLatticeElement::getRange(ConstantRange(C->getValue()));
|
2017-08-03 23:11:30 +02:00
|
|
|
}
|
2020-08-13 16:43:20 +02:00
|
|
|
} else if (isa<FreezeInst>(Usr)) {
|
|
|
|
assert(cast<FreezeInst>(Usr)->getOperand(0) == Op && "Operand 0 isn't Op");
|
2020-08-11 03:15:18 +02:00
|
|
|
return ValueLatticeElement::getRange(ConstantRange(OpConstVal));
|
2017-08-03 23:11:30 +02:00
|
|
|
}
|
2017-09-28 13:09:22 +02:00
|
|
|
return ValueLatticeElement::getOverdefined();
|
2017-08-03 23:11:30 +02:00
|
|
|
}
|
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Compute the value of Val on the edge BBFrom -> BBTo. Returns false if
|
2016-02-02 00:21:11 +01:00
|
|
|
/// Val is not constrained on the edge. Result is unspecified if return value
|
|
|
|
/// is false.
|
2020-04-09 21:13:03 +02:00
|
|
|
static Optional<ValueLatticeElement> getEdgeValueLocal(Value *Val,
|
|
|
|
BasicBlock *BBFrom,
|
|
|
|
BasicBlock *BBTo) {
|
2015-07-28 17:53:21 +02:00
|
|
|
// TODO: Handle more complex conditionals. If (v == 0 || v2 < 1) is false, we
|
2009-11-15 21:02:12 +01:00
|
|
|
// know that v != 0.
|
2009-11-15 20:59:49 +01:00
|
|
|
if (BranchInst *BI = dyn_cast<BranchInst>(BBFrom->getTerminator())) {
|
|
|
|
// If this is a conditional branch and only one successor goes to BBTo, then
|
2015-01-09 17:35:37 +01:00
|
|
|
// we may be able to infer something from the condition.
|
2009-11-15 20:59:49 +01:00
|
|
|
if (BI->isConditional() &&
|
|
|
|
BI->getSuccessor(0) != BI->getSuccessor(1)) {
|
|
|
|
bool isTrueDest = BI->getSuccessor(0) == BBTo;
|
|
|
|
assert(BI->getSuccessor(!isTrueDest) == BBTo &&
|
|
|
|
"BBTo isn't a successor of BBFrom");
|
2017-08-03 23:11:30 +02:00
|
|
|
Value *Condition = BI->getCondition();
|
2015-07-28 17:53:21 +02:00
|
|
|
|
2009-11-15 20:59:49 +01:00
|
|
|
// If V is the condition of the branch itself, then we know exactly what
|
|
|
|
// it is.
|
2020-04-09 21:13:03 +02:00
|
|
|
if (Condition == Val)
|
|
|
|
return ValueLatticeElement::get(ConstantInt::get(
|
2010-08-10 22:03:09 +02:00
|
|
|
Type::getInt1Ty(Val->getContext()), isTrueDest));
|
2015-07-28 17:53:21 +02:00
|
|
|
|
2009-11-15 20:59:49 +01:00
|
|
|
// If the condition of the branch is an equality comparison, we may be
|
|
|
|
// able to infer the value.
|
2020-04-09 21:13:03 +02:00
|
|
|
ValueLatticeElement Result = getValueFromCondition(Val, Condition,
|
|
|
|
isTrueDest);
|
2017-08-03 23:11:30 +02:00
|
|
|
if (!Result.isOverdefined())
|
2020-04-09 21:13:03 +02:00
|
|
|
return Result;
|
2017-08-03 23:11:30 +02:00
|
|
|
|
|
|
|
if (User *Usr = dyn_cast<User>(Val)) {
|
|
|
|
assert(Result.isOverdefined() && "Result isn't overdefined");
|
2017-08-10 04:23:14 +02:00
|
|
|
// Check with isOperationFoldable() first to avoid linearly iterating
|
|
|
|
// over the operands unnecessarily which can be expensive for
|
|
|
|
// instructions with many operands.
|
|
|
|
if (isa<IntegerType>(Usr->getType()) && isOperationFoldable(Usr)) {
|
2017-08-03 23:11:30 +02:00
|
|
|
const DataLayout &DL = BBTo->getModule()->getDataLayout();
|
|
|
|
if (usesOperand(Usr, Condition)) {
|
|
|
|
// If Val has Condition as an operand and Val can be folded into a
|
|
|
|
// constant with either Condition == true or Condition == false,
|
|
|
|
// propagate the constant.
|
|
|
|
// eg.
|
|
|
|
// ; %Val is true on the edge to %then.
|
|
|
|
// %Val = and i1 %Condition, true.
|
|
|
|
// br %Condition, label %then, label %else
|
|
|
|
APInt ConditionVal(1, isTrueDest ? 1 : 0);
|
2017-08-10 04:23:14 +02:00
|
|
|
Result = constantFoldUser(Usr, Condition, ConditionVal, DL);
|
2017-08-03 23:11:30 +02:00
|
|
|
} else {
|
|
|
|
// If one of Val's operand has an inferred value, we may be able to
|
|
|
|
// infer the value of Val.
|
|
|
|
// eg.
|
|
|
|
// ; %Val is 94 on the edge to %then.
|
|
|
|
// %Val = add i8 %Op, 1
|
|
|
|
// %Condition = icmp eq i8 %Op, 93
|
|
|
|
// br i1 %Condition, label %then, label %else
|
|
|
|
for (unsigned i = 0; i < Usr->getNumOperands(); ++i) {
|
|
|
|
Value *Op = Usr->getOperand(i);
|
2017-09-28 13:09:22 +02:00
|
|
|
ValueLatticeElement OpLatticeVal =
|
2017-08-03 23:11:30 +02:00
|
|
|
getValueFromCondition(Op, Condition, isTrueDest);
|
|
|
|
if (Optional<APInt> OpConst = OpLatticeVal.asConstantInteger()) {
|
2017-08-10 04:23:14 +02:00
|
|
|
Result = constantFoldUser(Usr, Op, OpConst.getValue(), DL);
|
2017-08-03 23:11:30 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2016-08-10 15:38:07 +02:00
|
|
|
if (!Result.isOverdefined())
|
2020-04-09 21:13:03 +02:00
|
|
|
return Result;
|
2009-11-15 20:59:49 +01:00
|
|
|
}
|
|
|
|
}
|
2009-11-15 21:02:12 +01:00
|
|
|
|
|
|
|
// If the edge was formed by a switch on the value, then we may know exactly
|
|
|
|
// what it is.
|
|
|
|
if (SwitchInst *SI = dyn_cast<SwitchInst>(BBFrom->getTerminator())) {
|
2017-08-03 23:11:30 +02:00
|
|
|
Value *Condition = SI->getCondition();
|
|
|
|
if (!isa<IntegerType>(Val->getType()))
|
2020-04-09 21:13:03 +02:00
|
|
|
return None;
|
2017-08-10 04:23:14 +02:00
|
|
|
bool ValUsesConditionAndMayBeFoldable = false;
|
2017-08-03 23:11:30 +02:00
|
|
|
if (Condition != Val) {
|
|
|
|
// Check if Val has Condition as an operand.
|
|
|
|
if (User *Usr = dyn_cast<User>(Val))
|
2017-08-10 04:23:14 +02:00
|
|
|
ValUsesConditionAndMayBeFoldable = isOperationFoldable(Usr) &&
|
|
|
|
usesOperand(Usr, Condition);
|
|
|
|
if (!ValUsesConditionAndMayBeFoldable)
|
2020-04-09 21:13:03 +02:00
|
|
|
return None;
|
2017-08-03 23:11:30 +02:00
|
|
|
}
|
2017-08-10 04:23:14 +02:00
|
|
|
assert((Condition == Val || ValUsesConditionAndMayBeFoldable) &&
|
2017-08-03 23:11:30 +02:00
|
|
|
"Condition != Val nor Val doesn't use Condition");
|
2012-06-28 18:13:37 +02:00
|
|
|
|
|
|
|
bool DefaultCase = SI->getDefaultDest() == BBTo;
|
|
|
|
unsigned BitWidth = Val->getType()->getIntegerBitWidth();
|
|
|
|
ConstantRange EdgesVals(BitWidth, DefaultCase/*isFullSet*/);
|
|
|
|
|
2017-04-12 09:27:28 +02:00
|
|
|
for (auto Case : SI->cases()) {
|
2017-08-03 23:11:30 +02:00
|
|
|
APInt CaseValue = Case.getCaseValue()->getValue();
|
|
|
|
ConstantRange EdgeVal(CaseValue);
|
2017-08-10 04:23:14 +02:00
|
|
|
if (ValUsesConditionAndMayBeFoldable) {
|
|
|
|
User *Usr = cast<User>(Val);
|
2017-08-03 23:11:30 +02:00
|
|
|
const DataLayout &DL = BBTo->getModule()->getDataLayout();
|
2017-09-28 13:09:22 +02:00
|
|
|
ValueLatticeElement EdgeLatticeVal =
|
2017-08-10 04:23:14 +02:00
|
|
|
constantFoldUser(Usr, Condition, CaseValue, DL);
|
2017-08-03 23:11:30 +02:00
|
|
|
if (EdgeLatticeVal.isOverdefined())
|
2020-04-09 21:13:03 +02:00
|
|
|
return None;
|
2017-08-03 23:11:30 +02:00
|
|
|
EdgeVal = EdgeLatticeVal.getConstantRange();
|
|
|
|
}
|
2012-09-06 01:45:58 +02:00
|
|
|
if (DefaultCase) {
|
|
|
|
// It is possible that the default destination is the destination of
|
2017-08-03 23:11:30 +02:00
|
|
|
// some cases. We cannot perform difference for those cases.
|
|
|
|
// We know Condition != CaseValue in BBTo. In some cases we can use
|
|
|
|
// this to infer Val == f(Condition) is != f(CaseValue). For now, we
|
|
|
|
// only do this when f is identity (i.e. Val == Condition), but we
|
|
|
|
// should be able to do this for any injective f.
|
|
|
|
if (Case.getCaseSuccessor() != BBTo && Condition == Val)
|
2012-09-06 01:45:58 +02:00
|
|
|
EdgesVals = EdgesVals.difference(EdgeVal);
|
2017-04-12 09:27:28 +02:00
|
|
|
} else if (Case.getCaseSuccessor() == BBTo)
|
2012-05-18 23:02:10 +02:00
|
|
|
EdgesVals = EdgesVals.unionWith(EdgeVal);
|
2009-11-15 21:02:12 +01:00
|
|
|
}
|
2020-04-09 21:13:03 +02:00
|
|
|
return ValueLatticeElement::getRange(std::move(EdgesVals));
|
2009-11-15 21:02:12 +01:00
|
|
|
}
|
2020-04-09 21:13:03 +02:00
|
|
|
return None;
|
2012-06-28 03:16:18 +02:00
|
|
|
}
|
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Compute the value of Val on the edge BBFrom -> BBTo or the value at
|
2015-01-09 17:35:37 +01:00
|
|
|
/// the basic block if the edge does not constrain Val.
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> LazyValueInfoImpl::getEdgeValue(
|
|
|
|
Value *Val, BasicBlock *BBFrom, BasicBlock *BBTo, Instruction *CxtI) {
|
2012-06-28 03:16:18 +02:00
|
|
|
// If already a constant, there is nothing to compute.
|
2020-04-09 21:13:03 +02:00
|
|
|
if (Constant *VC = dyn_cast<Constant>(Val))
|
|
|
|
return ValueLatticeElement::get(VC);
|
2012-06-28 03:16:18 +02:00
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
ValueLatticeElement LocalResult = getEdgeValueLocal(Val, BBFrom, BBTo)
|
|
|
|
.getValueOr(ValueLatticeElement::getOverdefined());
|
|
|
|
if (hasSingleValue(LocalResult))
|
2016-02-02 04:15:40 +01:00
|
|
|
// Can't get any more precise here
|
2020-04-09 21:13:03 +02:00
|
|
|
return LocalResult;
|
2012-06-28 03:16:18 +02:00
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> OptInBlock = getBlockValue(Val, BBFrom);
|
|
|
|
if (!OptInBlock)
|
|
|
|
return None;
|
|
|
|
ValueLatticeElement &InBlock = *OptInBlock;
|
2012-06-28 03:16:18 +02:00
|
|
|
|
2016-02-02 04:15:40 +01:00
|
|
|
// Try to intersect ranges of the BB and the constraint on the edge.
|
2016-08-12 17:52:23 +02:00
|
|
|
intersectAssumeOrGuardBlockValueConstantRange(Val, InBlock,
|
|
|
|
BBFrom->getTerminator());
|
2014-10-16 02:40:05 +02:00
|
|
|
// We can use the context instruction (generically the ultimate instruction
|
|
|
|
// the calling pass is trying to simplify) here, even though the result of
|
|
|
|
// this function is generally cached when called from the solve* functions
|
|
|
|
// (and that cached result might be used with queries using a different
|
|
|
|
// context instruction), because when this function is called from the solve*
|
|
|
|
// functions, the context instruction is not provided. When called from
|
2016-09-12 23:46:58 +02:00
|
|
|
// LazyValueInfoImpl::getValueOnEdge, the context instruction is provided,
|
2014-10-16 02:40:05 +02:00
|
|
|
// but then the result is not cached.
|
2016-08-12 17:52:23 +02:00
|
|
|
intersectAssumeOrGuardBlockValueConstantRange(Val, InBlock, CxtI);
|
2016-02-02 04:15:40 +01:00
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
return intersect(LocalResult, InBlock);
|
2009-11-15 20:59:49 +01:00
|
|
|
}
|
|
|
|
|
2017-09-28 13:09:22 +02:00
|
|
|
ValueLatticeElement LazyValueInfoImpl::getValueInBlock(Value *V, BasicBlock *BB,
|
|
|
|
Instruction *CxtI) {
|
2018-05-14 14:53:11 +02:00
|
|
|
LLVM_DEBUG(dbgs() << "LVI Getting block end value " << *V << " at '"
|
|
|
|
<< BB->getName() << "'\n");
|
2015-07-28 17:53:21 +02:00
|
|
|
|
2014-11-25 18:23:05 +01:00
|
|
|
assert(BlockValueStack.empty() && BlockValueSet.empty());
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> OptResult = getBlockValue(V, BB);
|
|
|
|
if (!OptResult) {
|
2016-02-10 22:46:32 +01:00
|
|
|
solve();
|
2020-04-09 21:13:03 +02:00
|
|
|
OptResult = getBlockValue(V, BB);
|
|
|
|
assert(OptResult && "Value not available after solving");
|
2016-02-10 22:46:32 +01:00
|
|
|
}
|
2020-04-09 21:13:03 +02:00
|
|
|
ValueLatticeElement Result = *OptResult;
|
2016-08-12 17:52:23 +02:00
|
|
|
intersectAssumeOrGuardBlockValueConstantRange(V, Result, CxtI);
|
2014-09-07 22:29:59 +02:00
|
|
|
|
2018-05-14 14:53:11 +02:00
|
|
|
LLVM_DEBUG(dbgs() << " Result = " << Result << "\n");
|
2014-09-07 22:29:59 +02:00
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
2017-09-28 13:09:22 +02:00
|
|
|
ValueLatticeElement LazyValueInfoImpl::getValueAt(Value *V, Instruction *CxtI) {
|
2018-05-14 14:53:11 +02:00
|
|
|
LLVM_DEBUG(dbgs() << "LVI Getting value " << *V << " at '" << CxtI->getName()
|
|
|
|
<< "'\n");
|
2014-09-07 22:29:59 +02:00
|
|
|
|
2016-02-10 22:46:32 +01:00
|
|
|
if (auto *C = dyn_cast<Constant>(V))
|
2017-09-28 13:09:22 +02:00
|
|
|
return ValueLatticeElement::get(C);
|
2016-02-10 22:46:32 +01:00
|
|
|
|
2017-09-28 13:09:22 +02:00
|
|
|
ValueLatticeElement Result = ValueLatticeElement::getOverdefined();
|
[LVI/CVP] Teach LVI about range metadata
Somewhat shockingly for an analysis pass which is computing constant ranges, LVI did not understand the ranges provided by range metadata.
As part of this change, I included a change to CVP primarily because doing so made it much easier to write small self contained test cases. CVP was previously only handling the non-local operand case, but given that LVI can sometimes figure out information about instructions standalone, I don't see any reason to restrict this. There could possibly be a compile time impact from this, but I suspect it should be minimal. If anyone has an example which substaintially regresses, please let me know. I could restrict the block local handling to ICmps feeding Terminator instructions if needed.
Note that this patch continues a somewhat bad practice in LVI. In many cases, we know facts about values, and separate context sensitive facts about values. LVI makes no effort to distinguish and will frequently cache the same value fact repeatedly for different contexts. I would like to change this, but that's a large enough change that I want it to go in separately with clear documentation of what's changing. Other examples of this include the non-null handling, and arguments.
As a meta comment: the entire motivation of this change was being able to write smaller (aka reasonable sized) test cases for a future patch teaching LVI about select instructions.
Differential Revision: http://reviews.llvm.org/D13543
llvm-svn: 251606
2015-10-29 04:57:17 +01:00
|
|
|
if (auto *I = dyn_cast<Instruction>(V))
|
|
|
|
Result = getFromRangeMetadata(I);
|
2016-08-12 17:52:23 +02:00
|
|
|
intersectAssumeOrGuardBlockValueConstantRange(V, Result, CxtI);
|
2016-02-02 01:45:30 +01:00
|
|
|
|
2018-05-14 14:53:11 +02:00
|
|
|
LLVM_DEBUG(dbgs() << " Result = " << Result << "\n");
|
2009-11-15 20:59:49 +01:00
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
2017-09-28 13:09:22 +02:00
|
|
|
ValueLatticeElement LazyValueInfoImpl::
|
2014-09-07 22:29:59 +02:00
|
|
|
getValueOnEdge(Value *V, BasicBlock *FromBB, BasicBlock *ToBB,
|
|
|
|
Instruction *CxtI) {
|
2018-05-14 14:53:11 +02:00
|
|
|
LLVM_DEBUG(dbgs() << "LVI Getting edge value " << *V << " from '"
|
|
|
|
<< FromBB->getName() << "' to '" << ToBB->getName()
|
|
|
|
<< "'\n");
|
2015-07-28 17:53:21 +02:00
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
Optional<ValueLatticeElement> Result = getEdgeValue(V, FromBB, ToBB, CxtI);
|
|
|
|
if (!Result) {
|
2010-12-18 02:00:40 +01:00
|
|
|
solve();
|
2020-04-09 21:13:03 +02:00
|
|
|
Result = getEdgeValue(V, FromBB, ToBB, CxtI);
|
|
|
|
assert(Result && "More work to do after problem solved?");
|
2010-12-18 02:00:40 +01:00
|
|
|
}
|
|
|
|
|
2020-04-09 21:13:03 +02:00
|
|
|
LLVM_DEBUG(dbgs() << " Result = " << *Result << "\n");
|
|
|
|
return *Result;
|
2009-11-15 20:59:49 +01:00
|
|
|
}
|
|
|
|
|
2016-09-12 23:46:58 +02:00
|
|
|
void LazyValueInfoImpl::threadEdge(BasicBlock *PredBB, BasicBlock *OldSucc,
|
2016-09-13 00:38:44 +02:00
|
|
|
BasicBlock *NewSucc) {
|
|
|
|
TheCache.threadEdgeImpl(OldSucc, NewSucc);
|
2010-07-26 20:48:03 +02:00
|
|
|
}
|
|
|
|
|
2009-11-15 20:59:49 +01:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// LazyValueInfo Impl
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2016-09-12 23:46:58 +02:00
|
|
|
/// This lazily constructs the LazyValueInfoImpl.
|
2016-12-19 09:22:17 +01:00
|
|
|
static LazyValueInfoImpl &getImpl(void *&PImpl, AssumptionCache *AC,
|
2020-06-13 15:36:55 +02:00
|
|
|
const Module *M) {
|
2015-03-10 03:37:25 +01:00
|
|
|
if (!PImpl) {
|
2020-06-13 15:36:55 +02:00
|
|
|
assert(M && "getCache() called with a null Module");
|
|
|
|
const DataLayout &DL = M->getDataLayout();
|
|
|
|
Function *GuardDecl = M->getFunction(
|
|
|
|
Intrinsic::getName(Intrinsic::experimental_guard));
|
|
|
|
PImpl = new LazyValueInfoImpl(AC, DL, GuardDecl);
|
2015-03-10 03:37:25 +01:00
|
|
|
}
|
2016-09-12 23:46:58 +02:00
|
|
|
return *static_cast<LazyValueInfoImpl*>(PImpl);
|
2009-11-15 20:59:49 +01:00
|
|
|
}
|
|
|
|
|
2016-06-14 00:01:25 +02:00
|
|
|
bool LazyValueInfoWrapperPass::runOnFunction(Function &F) {
|
2016-12-19 09:22:17 +01:00
|
|
|
Info.AC = &getAnalysis<AssumptionCacheTracker>().getAssumptionCache(F);
|
Change TargetLibraryInfo analysis passes to always require Function
Summary:
This is the first change to enable the TLI to be built per-function so
that -fno-builtin* handling can be migrated to use function attributes.
See discussion on D61634 for background. This is an enabler for fixing
handling of these options for LTO, for example.
This change should not affect behavior, as the provided function is not
yet used to build a specifically per-function TLI, but rather enables
that migration.
Most of the changes were very mechanical, e.g. passing a Function to the
legacy analysis pass's getTLI interface, or in Module level cases,
adding a callback. This is similar to the way the per-function TTI
analysis works.
There was one place where we were looking for builtins but not in the
context of a specific function. See FindCXAAtExit in
lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround
could provide the wrong behavior in some corner cases. Suggestions
welcome.
Reviewers: chandlerc, hfinkel
Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66428
llvm-svn: 371284
2019-09-07 05:09:36 +02:00
|
|
|
Info.TLI = &getAnalysis<TargetLibraryInfoWrapperPass>().getTLI(F);
|
2011-12-02 02:26:24 +01:00
|
|
|
|
2016-06-14 00:01:25 +02:00
|
|
|
if (Info.PImpl)
|
2020-06-13 15:36:55 +02:00
|
|
|
getImpl(Info.PImpl, Info.AC, F.getParent()).clear();
|
2014-09-07 22:29:59 +02:00
|
|
|
|
2010-08-18 20:39:01 +02:00
|
|
|
// Fully lazy.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-06-14 00:01:25 +02:00
|
|
|
void LazyValueInfoWrapperPass::getAnalysisUsage(AnalysisUsage &AU) const {
|
2011-12-02 02:26:24 +01:00
|
|
|
AU.setPreservesAll();
|
2016-12-19 09:22:17 +01:00
|
|
|
AU.addRequired<AssumptionCacheTracker>();
|
2015-01-15 11:41:28 +01:00
|
|
|
AU.addRequired<TargetLibraryInfoWrapperPass>();
|
2011-12-02 02:26:24 +01:00
|
|
|
}
|
|
|
|
|
2016-06-14 00:01:25 +02:00
|
|
|
LazyValueInfo &LazyValueInfoWrapperPass::getLVI() { return Info; }
|
|
|
|
|
|
|
|
LazyValueInfo::~LazyValueInfo() { releaseMemory(); }
|
|
|
|
|
2009-11-15 20:59:49 +01:00
|
|
|
void LazyValueInfo::releaseMemory() {
|
|
|
|
// If the cache was allocated, free it.
|
|
|
|
if (PImpl) {
|
2016-12-19 09:22:17 +01:00
|
|
|
delete &getImpl(PImpl, AC, nullptr);
|
2014-04-15 06:59:12 +02:00
|
|
|
PImpl = nullptr;
|
2009-11-15 20:59:49 +01:00
|
|
|
}
|
|
|
|
}
|
2009-11-11 23:48:44 +01:00
|
|
|
|
2017-01-23 07:35:12 +01:00
|
|
|
bool LazyValueInfo::invalidate(Function &F, const PreservedAnalyses &PA,
|
|
|
|
FunctionAnalysisManager::Invalidator &Inv) {
|
|
|
|
// We need to invalidate if we have either failed to preserve this analyses
|
|
|
|
// result directly or if any of its dependencies have been invalidated.
|
|
|
|
auto PAC = PA.getChecker<LazyValueAnalysis>();
|
2020-03-25 20:02:07 +01:00
|
|
|
if (!(PAC.preserved() || PAC.preservedSet<AllAnalysesOn<Function>>()))
|
2017-01-23 07:35:12 +01:00
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-06-14 00:01:25 +02:00
|
|
|
void LazyValueInfoWrapperPass::releaseMemory() { Info.releaseMemory(); }
|
|
|
|
|
2017-09-28 13:09:22 +02:00
|
|
|
LazyValueInfo LazyValueAnalysis::run(Function &F,
|
|
|
|
FunctionAnalysisManager &FAM) {
|
2016-12-19 09:22:17 +01:00
|
|
|
auto &AC = FAM.getResult<AssumptionAnalysis>(F);
|
2016-06-14 00:01:25 +02:00
|
|
|
auto &TLI = FAM.getResult<TargetLibraryAnalysis>(F);
|
|
|
|
|
2020-03-25 20:02:07 +01:00
|
|
|
return LazyValueInfo(&AC, &F.getParent()->getDataLayout(), &TLI);
|
2016-06-14 00:01:25 +02:00
|
|
|
}
|
|
|
|
|
2016-09-15 08:28:34 +02:00
|
|
|
/// Returns true if we can statically tell that this value will never be a
|
|
|
|
/// "useful" constant. In practice, this means we've got something like an
|
|
|
|
/// alloca or a malloc call for which a comparison against a constant can
|
|
|
|
/// only be guarding dead code. Note that we are potentially giving up some
|
|
|
|
/// precision in dead code (a constant result) in favour of avoiding a
|
|
|
|
/// expensive search for a easily answered common query.
|
|
|
|
static bool isKnownNonConstant(Value *V) {
|
|
|
|
V = V->stripPointerCasts();
|
|
|
|
// The return val of alloc cannot be a Constant.
|
|
|
|
if (isa<AllocaInst>(V))
|
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2020-09-27 17:41:39 +02:00
|
|
|
Constant *LazyValueInfo::getConstant(Value *V, Instruction *CxtI) {
|
2016-09-15 08:28:34 +02:00
|
|
|
// Bail out early if V is known not to be a Constant.
|
|
|
|
if (isKnownNonConstant(V))
|
|
|
|
return nullptr;
|
|
|
|
|
2020-09-27 17:41:39 +02:00
|
|
|
BasicBlock *BB = CxtI->getParent();
|
2017-09-28 13:09:22 +02:00
|
|
|
ValueLatticeElement Result =
|
2020-06-13 15:36:55 +02:00
|
|
|
getImpl(PImpl, AC, BB->getModule()).getValueInBlock(V, BB, CxtI);
|
2015-01-04 13:03:27 +01:00
|
|
|
|
2009-11-11 23:48:44 +01:00
|
|
|
if (Result.isConstant())
|
|
|
|
return Result.getConstant();
|
2010-12-15 19:57:18 +01:00
|
|
|
if (Result.isConstantRange()) {
|
2017-05-06 05:35:15 +02:00
|
|
|
const ConstantRange &CR = Result.getConstantRange();
|
2010-08-28 01:29:38 +02:00
|
|
|
if (const APInt *SingleVal = CR.getSingleElement())
|
|
|
|
return ConstantInt::get(V->getContext(), *SingleVal);
|
|
|
|
}
|
2014-04-15 06:59:12 +02:00
|
|
|
return nullptr;
|
2009-11-11 23:48:44 +01:00
|
|
|
}
|
2009-11-11 03:08:33 +01:00
|
|
|
|
2020-09-27 17:41:39 +02:00
|
|
|
ConstantRange LazyValueInfo::getConstantRange(Value *V, Instruction *CxtI,
|
[ValueLattice] Distinguish between constant ranges with/without undef.
This patch updates ValueLattice to distinguish between ranges that are
guaranteed to not include undef and ranges that may include undef.
A constant range guaranteed to not contain undef can be used to simplify
instructions to arbitrary values. A constant range that may contain
undef can only be used to simplify to a constant. If the value can be
undef, it might take a value outside the range. For example, consider
the snipped below
define i32 @f(i32 %a, i1 %c) {
br i1 %c, label %true, label %false
true:
%a.255 = and i32 %a, 255
br label %exit
false:
br label %exit
exit:
%p = phi i32 [ %a.255, %true ], [ undef, %false ]
%f.1 = icmp eq i32 %p, 300
call void @use(i1 %f.1)
%res = and i32 %p, 255
ret i32 %res
}
In the exit block, %p would be a constant range [0, 256) including undef as
%p could be undef. We can use the range information to replace %f.1 with
false because we remove the compare, effectively forcing the use of the
constant to be != 300. We cannot replace %res with %p however, because
if %a would be undef %cond may be true but the second use might not be
< 256.
Currently LazyValueInfo uses the new behavior just when simplifying AND
instructions and does not distinguish between constant ranges with and
without undef otherwise. I think we should address the remaining issues
in LVI incrementally.
Reviewers: efriedma, reames, aqjune, jdoerfert, sstefan1
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D76931
2020-03-31 12:10:00 +02:00
|
|
|
bool UndefAllowed) {
|
2016-05-02 21:58:00 +02:00
|
|
|
assert(V->getType()->isIntegerTy());
|
|
|
|
unsigned Width = V->getType()->getIntegerBitWidth();
|
2020-09-27 17:41:39 +02:00
|
|
|
BasicBlock *BB = CxtI->getParent();
|
2017-09-28 13:09:22 +02:00
|
|
|
ValueLatticeElement Result =
|
2020-06-13 15:36:55 +02:00
|
|
|
getImpl(PImpl, AC, BB->getModule()).getValueInBlock(V, BB, CxtI);
|
2020-03-14 17:50:09 +01:00
|
|
|
if (Result.isUnknown())
|
2019-03-24 10:34:40 +01:00
|
|
|
return ConstantRange::getEmpty(Width);
|
[ValueLattice] Distinguish between constant ranges with/without undef.
This patch updates ValueLattice to distinguish between ranges that are
guaranteed to not include undef and ranges that may include undef.
A constant range guaranteed to not contain undef can be used to simplify
instructions to arbitrary values. A constant range that may contain
undef can only be used to simplify to a constant. If the value can be
undef, it might take a value outside the range. For example, consider
the snipped below
define i32 @f(i32 %a, i1 %c) {
br i1 %c, label %true, label %false
true:
%a.255 = and i32 %a, 255
br label %exit
false:
br label %exit
exit:
%p = phi i32 [ %a.255, %true ], [ undef, %false ]
%f.1 = icmp eq i32 %p, 300
call void @use(i1 %f.1)
%res = and i32 %p, 255
ret i32 %res
}
In the exit block, %p would be a constant range [0, 256) including undef as
%p could be undef. We can use the range information to replace %f.1 with
false because we remove the compare, effectively forcing the use of the
constant to be != 300. We cannot replace %res with %p however, because
if %a would be undef %cond may be true but the second use might not be
< 256.
Currently LazyValueInfo uses the new behavior just when simplifying AND
instructions and does not distinguish between constant ranges with and
without undef otherwise. I think we should address the remaining issues
in LVI incrementally.
Reviewers: efriedma, reames, aqjune, jdoerfert, sstefan1
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D76931
2020-03-31 12:10:00 +02:00
|
|
|
if (Result.isConstantRange(UndefAllowed))
|
|
|
|
return Result.getConstantRange(UndefAllowed);
|
2016-08-10 14:54:54 +02:00
|
|
|
// We represent ConstantInt constants as constant ranges but other kinds
|
|
|
|
// of integer constants, i.e. ConstantExpr will be tagged as constants
|
|
|
|
assert(!(Result.isConstant() && isa<ConstantInt>(Result.getConstant())) &&
|
|
|
|
"ConstantInt value must be represented as constantrange");
|
2019-03-24 10:34:40 +01:00
|
|
|
return ConstantRange::getFull(Width);
|
2016-05-02 21:58:00 +02:00
|
|
|
}
|
|
|
|
|
2015-01-09 17:47:20 +01:00
|
|
|
/// Determine whether the specified value is known to be a
|
2015-07-28 17:53:21 +02:00
|
|
|
/// constant on the specified edge. Return null if not.
|
2009-11-12 02:29:10 +01:00
|
|
|
Constant *LazyValueInfo::getConstantOnEdge(Value *V, BasicBlock *FromBB,
|
2014-09-07 22:29:59 +02:00
|
|
|
BasicBlock *ToBB,
|
|
|
|
Instruction *CxtI) {
|
2020-06-13 15:36:55 +02:00
|
|
|
Module *M = FromBB->getModule();
|
2017-09-28 13:09:22 +02:00
|
|
|
ValueLatticeElement Result =
|
2020-06-13 15:36:55 +02:00
|
|
|
getImpl(PImpl, AC, M).getValueOnEdge(V, FromBB, ToBB, CxtI);
|
2015-01-04 13:03:27 +01:00
|
|
|
|
2009-11-12 02:29:10 +01:00
|
|
|
if (Result.isConstant())
|
|
|
|
return Result.getConstant();
|
2010-12-15 19:57:18 +01:00
|
|
|
if (Result.isConstantRange()) {
|
2017-05-06 05:35:15 +02:00
|
|
|
const ConstantRange &CR = Result.getConstantRange();
|
2010-08-10 22:03:09 +02:00
|
|
|
if (const APInt *SingleVal = CR.getSingleElement())
|
|
|
|
return ConstantInt::get(V->getContext(), *SingleVal);
|
|
|
|
}
|
2014-04-15 06:59:12 +02:00
|
|
|
return nullptr;
|
2009-11-12 02:29:10 +01:00
|
|
|
}
|
|
|
|
|
2017-06-23 07:41:35 +02:00
|
|
|
ConstantRange LazyValueInfo::getConstantRangeOnEdge(Value *V,
|
|
|
|
BasicBlock *FromBB,
|
|
|
|
BasicBlock *ToBB,
|
|
|
|
Instruction *CxtI) {
|
|
|
|
unsigned Width = V->getType()->getIntegerBitWidth();
|
2020-06-13 15:36:55 +02:00
|
|
|
Module *M = FromBB->getModule();
|
2017-09-28 13:09:22 +02:00
|
|
|
ValueLatticeElement Result =
|
2020-06-13 15:36:55 +02:00
|
|
|
getImpl(PImpl, AC, M).getValueOnEdge(V, FromBB, ToBB, CxtI);
|
2017-06-23 07:41:35 +02:00
|
|
|
|
2020-03-14 17:50:09 +01:00
|
|
|
if (Result.isUnknown())
|
2019-03-24 10:34:40 +01:00
|
|
|
return ConstantRange::getEmpty(Width);
|
2017-06-23 07:41:35 +02:00
|
|
|
if (Result.isConstantRange())
|
|
|
|
return Result.getConstantRange();
|
|
|
|
// We represent ConstantInt constants as constant ranges but other kinds
|
|
|
|
// of integer constants, i.e. ConstantExpr will be tagged as constants
|
|
|
|
assert(!(Result.isConstant() && isa<ConstantInt>(Result.getConstant())) &&
|
|
|
|
"ConstantInt value must be represented as constantrange");
|
2019-03-24 10:34:40 +01:00
|
|
|
return ConstantRange::getFull(Width);
|
2017-06-23 07:41:35 +02:00
|
|
|
}
|
|
|
|
|
2017-09-28 13:09:22 +02:00
|
|
|
static LazyValueInfo::Tristate
|
|
|
|
getPredicateResult(unsigned Pred, Constant *C, const ValueLatticeElement &Val,
|
|
|
|
const DataLayout &DL, TargetLibraryInfo *TLI) {
|
2009-11-12 05:36:58 +01:00
|
|
|
// If we know the value is a constant, evaluate the conditional.
|
2014-04-15 06:59:12 +02:00
|
|
|
Constant *Res = nullptr;
|
2017-06-09 23:18:16 +02:00
|
|
|
if (Val.isConstant()) {
|
|
|
|
Res = ConstantFoldCompareInstOperands(Pred, Val.getConstant(), C, DL, TLI);
|
2010-12-15 19:57:18 +01:00
|
|
|
if (ConstantInt *ResCI = dyn_cast<ConstantInt>(Res))
|
2014-09-07 22:29:59 +02:00
|
|
|
return ResCI->isZero() ? LazyValueInfo::False : LazyValueInfo::True;
|
|
|
|
return LazyValueInfo::Unknown;
|
2009-11-15 20:59:49 +01:00
|
|
|
}
|
2015-07-28 17:53:21 +02:00
|
|
|
|
2017-06-09 23:18:16 +02:00
|
|
|
if (Val.isConstantRange()) {
|
2010-08-24 09:55:44 +02:00
|
|
|
ConstantInt *CI = dyn_cast<ConstantInt>(C);
|
2014-09-07 22:29:59 +02:00
|
|
|
if (!CI) return LazyValueInfo::Unknown;
|
2015-07-28 17:53:21 +02:00
|
|
|
|
2017-06-09 23:18:16 +02:00
|
|
|
const ConstantRange &CR = Val.getConstantRange();
|
2010-08-10 22:03:09 +02:00
|
|
|
if (Pred == ICmpInst::ICMP_EQ) {
|
|
|
|
if (!CR.contains(CI->getValue()))
|
2014-09-07 22:29:59 +02:00
|
|
|
return LazyValueInfo::False;
|
2015-07-28 17:53:21 +02:00
|
|
|
|
2017-06-07 02:58:09 +02:00
|
|
|
if (CR.isSingleElement())
|
2014-09-07 22:29:59 +02:00
|
|
|
return LazyValueInfo::True;
|
2010-08-10 22:03:09 +02:00
|
|
|
} else if (Pred == ICmpInst::ICMP_NE) {
|
|
|
|
if (!CR.contains(CI->getValue()))
|
2014-09-07 22:29:59 +02:00
|
|
|
return LazyValueInfo::True;
|
2015-07-28 17:53:21 +02:00
|
|
|
|
2017-06-07 02:58:09 +02:00
|
|
|
if (CR.isSingleElement())
|
2014-09-07 22:29:59 +02:00
|
|
|
return LazyValueInfo::False;
|
2017-06-09 18:16:20 +02:00
|
|
|
} else {
|
|
|
|
// Handle more complex predicates.
|
|
|
|
ConstantRange TrueValues = ConstantRange::makeExactICmpRegion(
|
|
|
|
(ICmpInst::Predicate)Pred, CI->getValue());
|
|
|
|
if (TrueValues.contains(CR))
|
|
|
|
return LazyValueInfo::True;
|
|
|
|
if (TrueValues.inverse().contains(CR))
|
|
|
|
return LazyValueInfo::False;
|
2010-08-10 22:03:09 +02:00
|
|
|
}
|
2014-09-07 22:29:59 +02:00
|
|
|
return LazyValueInfo::Unknown;
|
2010-08-10 22:03:09 +02:00
|
|
|
}
|
2015-07-28 17:53:21 +02:00
|
|
|
|
2017-06-09 23:18:16 +02:00
|
|
|
if (Val.isNotConstant()) {
|
2009-11-12 05:36:58 +01:00
|
|
|
// If this is an equality comparison, we can try to fold it knowing that
|
|
|
|
// "V != C1".
|
|
|
|
if (Pred == ICmpInst::ICMP_EQ) {
|
2012-09-27 12:14:43 +02:00
|
|
|
// !C1 == C -> false iff C1 == C.
|
2009-11-12 05:36:58 +01:00
|
|
|
Res = ConstantFoldCompareInstOperands(ICmpInst::ICMP_NE,
|
2017-06-09 23:18:16 +02:00
|
|
|
Val.getNotConstant(), C, DL,
|
2011-12-02 02:26:24 +01:00
|
|
|
TLI);
|
2009-11-12 05:36:58 +01:00
|
|
|
if (Res->isNullValue())
|
2014-09-07 22:29:59 +02:00
|
|
|
return LazyValueInfo::False;
|
2009-11-12 05:36:58 +01:00
|
|
|
} else if (Pred == ICmpInst::ICMP_NE) {
|
2012-09-27 12:14:43 +02:00
|
|
|
// !C1 != C -> true iff C1 == C.
|
2009-11-15 21:01:24 +01:00
|
|
|
Res = ConstantFoldCompareInstOperands(ICmpInst::ICMP_NE,
|
2017-06-09 23:18:16 +02:00
|
|
|
Val.getNotConstant(), C, DL,
|
2011-12-02 02:26:24 +01:00
|
|
|
TLI);
|
2009-11-12 05:36:58 +01:00
|
|
|
if (Res->isNullValue())
|
2014-09-07 22:29:59 +02:00
|
|
|
return LazyValueInfo::True;
|
2009-11-12 05:36:58 +01:00
|
|
|
}
|
2014-09-07 22:29:59 +02:00
|
|
|
return LazyValueInfo::Unknown;
|
2009-11-11 03:08:33 +01:00
|
|
|
}
|
2015-07-28 17:53:21 +02:00
|
|
|
|
2014-09-07 22:29:59 +02:00
|
|
|
return LazyValueInfo::Unknown;
|
|
|
|
}
|
|
|
|
|
2015-01-09 17:47:20 +01:00
|
|
|
/// Determine whether the specified value comparison with a constant is known to
|
|
|
|
/// be true or false on the specified CFG edge. Pred is a CmpInst predicate.
|
2014-09-07 22:29:59 +02:00
|
|
|
LazyValueInfo::Tristate
|
|
|
|
LazyValueInfo::getPredicateOnEdge(unsigned Pred, Value *V, Constant *C,
|
|
|
|
BasicBlock *FromBB, BasicBlock *ToBB,
|
|
|
|
Instruction *CxtI) {
|
2020-06-13 15:36:55 +02:00
|
|
|
Module *M = FromBB->getModule();
|
2017-09-28 13:09:22 +02:00
|
|
|
ValueLatticeElement Result =
|
2020-06-13 15:36:55 +02:00
|
|
|
getImpl(PImpl, AC, M).getValueOnEdge(V, FromBB, ToBB, CxtI);
|
2014-09-07 22:29:59 +02:00
|
|
|
|
2020-06-13 15:36:55 +02:00
|
|
|
return getPredicateResult(Pred, C, Result, M->getDataLayout(), TLI);
|
2014-09-07 22:29:59 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
LazyValueInfo::Tristate
|
|
|
|
LazyValueInfo::getPredicateAt(unsigned Pred, Value *V, Constant *C,
|
2020-08-30 16:20:12 +02:00
|
|
|
Instruction *CxtI, bool UseBlockValue) {
|
2016-09-15 08:28:34 +02:00
|
|
|
// Is or is not NonNull are common predicates being queried. If
|
2017-09-09 20:23:11 +02:00
|
|
|
// isKnownNonZero can tell us the result of the predicate, we can
|
2016-09-15 08:28:34 +02:00
|
|
|
// return it quickly. But this is only a fastpath, and falling
|
|
|
|
// through would still be correct.
|
2020-06-13 15:36:55 +02:00
|
|
|
Module *M = CxtI->getModule();
|
|
|
|
const DataLayout &DL = M->getDataLayout();
|
2016-09-15 08:28:34 +02:00
|
|
|
if (V->getType()->isPointerTy() && C->isNullValue() &&
|
Introduce Value::stripPointerCastsSameRepresentation
This patch allows current users of Value::stripPointerCasts() to force
the result of the function to have the same representation as the value
it was called on. This is useful in various cases, e.g., (non-)null
checks.
In this patch only a single call site was adjusted to fix an existing
misuse that would cause nonnull where they may be wrong. Uses in
attribute deduction and other areas, e.g., D60047, are to be expected.
For a discussion on this topic, please see [0].
[0] http://lists.llvm.org/pipermail/llvm-dev/2018-December/128423.html
Reviewers: hfinkel, arsenm, reames
Subscribers: wdng, hiraditya, bollu, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61607
llvm-svn: 362545
2019-06-04 22:21:46 +02:00
|
|
|
isKnownNonZero(V->stripPointerCastsSameRepresentation(), DL)) {
|
2016-09-15 08:28:34 +02:00
|
|
|
if (Pred == ICmpInst::ICMP_EQ)
|
|
|
|
return LazyValueInfo::False;
|
|
|
|
else if (Pred == ICmpInst::ICMP_NE)
|
|
|
|
return LazyValueInfo::True;
|
|
|
|
}
|
2020-08-30 16:20:12 +02:00
|
|
|
|
|
|
|
ValueLatticeElement Result = UseBlockValue
|
|
|
|
? getImpl(PImpl, AC, M).getValueInBlock(V, CxtI->getParent(), CxtI)
|
|
|
|
: getImpl(PImpl, AC, M).getValueAt(V, CxtI);
|
2015-06-16 02:49:59 +02:00
|
|
|
Tristate Ret = getPredicateResult(Pred, C, Result, DL, TLI);
|
|
|
|
if (Ret != Unknown)
|
|
|
|
return Ret;
|
|
|
|
|
2015-11-04 02:47:04 +01:00
|
|
|
// Note: The following bit of code is somewhat distinct from the rest of LVI;
|
|
|
|
// LVI as a whole tries to compute a lattice value which is conservatively
|
|
|
|
// correct at a given location. In this case, we have a predicate which we
|
|
|
|
// weren't able to prove about the merged result, and we're pushing that
|
|
|
|
// predicate back along each incoming edge to see if we can prove it
|
|
|
|
// separately for each input. As a motivating example, consider:
|
|
|
|
// bb1:
|
|
|
|
// %v1 = ... ; constantrange<1, 5>
|
|
|
|
// br label %merge
|
|
|
|
// bb2:
|
|
|
|
// %v2 = ... ; constantrange<10, 20>
|
|
|
|
// br label %merge
|
|
|
|
// merge:
|
|
|
|
// %phi = phi [%v1, %v2] ; constantrange<1,20>
|
|
|
|
// %pred = icmp eq i32 %phi, 8
|
|
|
|
// We can't tell from the lattice value for '%phi' that '%pred' is false
|
|
|
|
// along each path, but by checking the predicate over each input separately,
|
|
|
|
// we can.
|
|
|
|
// We limit the search to one step backwards from the current BB and value.
|
|
|
|
// We could consider extending this to search further backwards through the
|
|
|
|
// CFG and/or value graph, but there are non-obvious compile time vs quality
|
2016-07-04 03:26:27 +02:00
|
|
|
// tradeoffs.
|
2015-06-16 02:49:59 +02:00
|
|
|
if (CxtI) {
|
2015-08-31 20:31:48 +02:00
|
|
|
BasicBlock *BB = CxtI->getParent();
|
|
|
|
|
|
|
|
// Function entry or an unreachable block. Bail to avoid confusing
|
|
|
|
// analysis below.
|
|
|
|
pred_iterator PI = pred_begin(BB), PE = pred_end(BB);
|
|
|
|
if (PI == PE)
|
|
|
|
return Unknown;
|
|
|
|
|
|
|
|
// If V is a PHI node in the same block as the context, we need to ask
|
|
|
|
// questions about the predicate as applied to the incoming value along
|
|
|
|
// each edge. This is useful for eliminating cases where the predicate is
|
|
|
|
// known along all incoming edges.
|
|
|
|
if (auto *PHI = dyn_cast<PHINode>(V))
|
|
|
|
if (PHI->getParent() == BB) {
|
|
|
|
Tristate Baseline = Unknown;
|
|
|
|
for (unsigned i = 0, e = PHI->getNumIncomingValues(); i < e; i++) {
|
|
|
|
Value *Incoming = PHI->getIncomingValue(i);
|
|
|
|
BasicBlock *PredBB = PHI->getIncomingBlock(i);
|
2016-07-04 03:26:27 +02:00
|
|
|
// Note that PredBB may be BB itself.
|
2015-08-31 20:31:48 +02:00
|
|
|
Tristate Result = getPredicateOnEdge(Pred, Incoming, C, PredBB, BB,
|
|
|
|
CxtI);
|
2016-07-04 03:26:33 +02:00
|
|
|
|
2015-08-31 20:31:48 +02:00
|
|
|
// Keep going as long as we've seen a consistent known result for
|
|
|
|
// all inputs.
|
|
|
|
Baseline = (i == 0) ? Result /* First iteration */
|
|
|
|
: (Baseline == Result ? Baseline : Unknown); /* All others */
|
|
|
|
if (Baseline == Unknown)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (Baseline != Unknown)
|
|
|
|
return Baseline;
|
2016-07-25 02:59:46 +02:00
|
|
|
}
|
2015-08-31 20:31:48 +02:00
|
|
|
|
2015-06-16 02:49:59 +02:00
|
|
|
// For a comparison where the V is outside this block, it's possible
|
2015-07-28 17:53:21 +02:00
|
|
|
// that we've branched on it before. Look to see if the value is known
|
2015-06-16 02:49:59 +02:00
|
|
|
// on all incoming edges.
|
2015-08-31 20:31:48 +02:00
|
|
|
if (!isa<Instruction>(V) ||
|
|
|
|
cast<Instruction>(V)->getParent() != BB) {
|
2015-06-16 02:49:59 +02:00
|
|
|
// For predecessor edge, determine if the comparison is true or false
|
2015-07-28 17:53:21 +02:00
|
|
|
// on that edge. If they're all true or all false, we can conclude
|
2015-06-16 02:49:59 +02:00
|
|
|
// the value of the comparison in this block.
|
|
|
|
Tristate Baseline = getPredicateOnEdge(Pred, V, C, *PI, BB, CxtI);
|
|
|
|
if (Baseline != Unknown) {
|
|
|
|
// Check that all remaining incoming values match the first one.
|
|
|
|
while (++PI != PE) {
|
|
|
|
Tristate Ret = getPredicateOnEdge(Pred, V, C, *PI, BB, CxtI);
|
|
|
|
if (Ret != Baseline) break;
|
|
|
|
}
|
|
|
|
// If we terminated early, then one of the values didn't match.
|
|
|
|
if (PI == PE) {
|
|
|
|
return Baseline;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return Unknown;
|
2009-11-11 01:22:30 +01:00
|
|
|
}
|
2009-11-11 03:08:33 +01:00
|
|
|
|
2010-07-26 20:48:03 +02:00
|
|
|
void LazyValueInfo::threadEdge(BasicBlock *PredBB, BasicBlock *OldSucc,
|
2010-12-15 19:57:18 +01:00
|
|
|
BasicBlock *NewSucc) {
|
2015-03-10 03:37:25 +01:00
|
|
|
if (PImpl) {
|
2020-06-13 15:36:55 +02:00
|
|
|
getImpl(PImpl, AC, PredBB->getModule())
|
|
|
|
.threadEdge(PredBB, OldSucc, NewSucc);
|
2015-03-10 03:37:25 +01:00
|
|
|
}
|
2010-08-18 20:39:01 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
void LazyValueInfo::eraseBlock(BasicBlock *BB) {
|
2015-03-10 03:37:25 +01:00
|
|
|
if (PImpl) {
|
2020-06-13 15:36:55 +02:00
|
|
|
getImpl(PImpl, AC, BB->getModule()).eraseBlock(BB);
|
2015-03-10 03:37:25 +01:00
|
|
|
}
|
2010-07-26 20:48:03 +02:00
|
|
|
}
|
2017-03-22 20:27:12 +01:00
|
|
|
|
|
|
|
|
2017-06-06 21:25:31 +02:00
|
|
|
void LazyValueInfo::printLVI(Function &F, DominatorTree &DTree, raw_ostream &OS) {
|
2017-03-22 20:27:12 +01:00
|
|
|
if (PImpl) {
|
2020-06-13 15:36:55 +02:00
|
|
|
getImpl(PImpl, AC, F.getParent()).printLVI(F, DTree, OS);
|
2017-06-06 21:25:31 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Print the LVI for the function arguments at the start of each basic block.
|
|
|
|
void LazyValueInfoAnnotatedWriter::emitBasicBlockStartAnnot(
|
|
|
|
const BasicBlock *BB, formatted_raw_ostream &OS) {
|
|
|
|
// Find if there are latticevalues defined for arguments of the function.
|
|
|
|
auto *F = BB->getParent();
|
|
|
|
for (auto &Arg : F->args()) {
|
2017-09-28 13:09:22 +02:00
|
|
|
ValueLatticeElement Result = LVIImpl->getValueInBlock(
|
2017-06-06 21:25:31 +02:00
|
|
|
const_cast<Argument *>(&Arg), const_cast<BasicBlock *>(BB));
|
2020-03-14 17:50:09 +01:00
|
|
|
if (Result.isUnknown())
|
2017-06-06 21:25:31 +02:00
|
|
|
continue;
|
|
|
|
OS << "; LatticeVal for: '" << Arg << "' is: " << Result << "\n";
|
2017-03-22 20:27:12 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-06 21:25:31 +02:00
|
|
|
// This function prints the LVI analysis for the instruction I at the beginning
|
|
|
|
// of various basic blocks. It relies on calculated values that are stored in
|
2018-04-24 09:38:07 +02:00
|
|
|
// the LazyValueInfoCache, and in the absence of cached values, recalculate the
|
2017-06-06 21:25:31 +02:00
|
|
|
// LazyValueInfo for `I`, and print that info.
|
|
|
|
void LazyValueInfoAnnotatedWriter::emitInstructionAnnot(
|
|
|
|
const Instruction *I, formatted_raw_ostream &OS) {
|
|
|
|
|
|
|
|
auto *ParentBB = I->getParent();
|
|
|
|
SmallPtrSet<const BasicBlock*, 16> BlocksContainingLVI;
|
|
|
|
// We can generate (solve) LVI values only for blocks that are dominated by
|
|
|
|
// the I's parent. However, to avoid generating LVI for all dominating blocks,
|
|
|
|
// that contain redundant/uninteresting information, we print LVI for
|
|
|
|
// blocks that may use this LVI information (such as immediate successor
|
|
|
|
// blocks, and blocks that contain uses of `I`).
|
|
|
|
auto printResult = [&](const BasicBlock *BB) {
|
|
|
|
if (!BlocksContainingLVI.insert(BB).second)
|
|
|
|
return;
|
2017-09-28 13:09:22 +02:00
|
|
|
ValueLatticeElement Result = LVIImpl->getValueInBlock(
|
2017-06-06 21:25:31 +02:00
|
|
|
const_cast<Instruction *>(I), const_cast<BasicBlock *>(BB));
|
|
|
|
OS << "; LatticeVal for: '" << *I << "' in BB: '";
|
|
|
|
BB->printAsOperand(OS, false);
|
|
|
|
OS << "' is: " << Result << "\n";
|
|
|
|
};
|
|
|
|
|
|
|
|
printResult(ParentBB);
|
2018-01-17 13:29:38 +01:00
|
|
|
// Print the LVI analysis results for the immediate successor blocks, that
|
2017-06-06 21:25:31 +02:00
|
|
|
// are dominated by `ParentBB`.
|
|
|
|
for (auto *BBSucc : successors(ParentBB))
|
|
|
|
if (DT.dominates(ParentBB, BBSucc))
|
|
|
|
printResult(BBSucc);
|
|
|
|
|
|
|
|
// Print LVI in blocks where `I` is used.
|
|
|
|
for (auto *U : I->users())
|
|
|
|
if (auto *UseI = dyn_cast<Instruction>(U))
|
|
|
|
if (!isa<PHINode>(UseI) || DT.dominates(ParentBB, UseI->getParent()))
|
|
|
|
printResult(UseI->getParent());
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2017-03-22 20:27:12 +01:00
|
|
|
namespace {
|
|
|
|
// Printer class for LazyValueInfo results.
|
|
|
|
class LazyValueInfoPrinter : public FunctionPass {
|
|
|
|
public:
|
|
|
|
static char ID; // Pass identification, replacement for typeid
|
|
|
|
LazyValueInfoPrinter() : FunctionPass(ID) {
|
|
|
|
initializeLazyValueInfoPrinterPass(*PassRegistry::getPassRegistry());
|
|
|
|
}
|
|
|
|
|
|
|
|
void getAnalysisUsage(AnalysisUsage &AU) const override {
|
|
|
|
AU.setPreservesAll();
|
|
|
|
AU.addRequired<LazyValueInfoWrapperPass>();
|
2017-06-06 21:25:31 +02:00
|
|
|
AU.addRequired<DominatorTreeWrapperPass>();
|
2017-03-22 20:27:12 +01:00
|
|
|
}
|
|
|
|
|
2017-06-06 21:25:31 +02:00
|
|
|
// Get the mandatory dominator tree analysis and pass this in to the
|
|
|
|
// LVIPrinter. We cannot rely on the LVI's DT, since it's optional.
|
2017-03-22 20:27:12 +01:00
|
|
|
bool runOnFunction(Function &F) override {
|
|
|
|
dbgs() << "LVI for function '" << F.getName() << "':\n";
|
|
|
|
auto &LVI = getAnalysis<LazyValueInfoWrapperPass>().getLVI();
|
2017-06-06 21:25:31 +02:00
|
|
|
auto &DTree = getAnalysis<DominatorTreeWrapperPass>().getDomTree();
|
|
|
|
LVI.printLVI(F, DTree, dbgs());
|
2017-03-22 20:27:12 +01:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
char LazyValueInfoPrinter::ID = 0;
|
|
|
|
INITIALIZE_PASS_BEGIN(LazyValueInfoPrinter, "print-lazy-value-info",
|
|
|
|
"Lazy Value Info Printer Pass", false, false)
|
|
|
|
INITIALIZE_PASS_DEPENDENCY(LazyValueInfoWrapperPass)
|
|
|
|
INITIALIZE_PASS_END(LazyValueInfoPrinter, "print-lazy-value-info",
|
|
|
|
"Lazy Value Info Printer Pass", false, false)
|