1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-23 03:02:36 +01:00
llvm-mirror/include/llvm/Analysis/LazyValueInfo.h

165 lines
5.8 KiB
C
Raw Normal View History

//===- LazyValueInfo.h - Value constraint analysis --------------*- C++ -*-===//
//
// 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
//
//===----------------------------------------------------------------------===//
//
// This file defines the interface for lazy computation of value constraint
// information.
//
//===----------------------------------------------------------------------===//
#ifndef LLVM_ANALYSIS_LAZYVALUEINFO_H
#define LLVM_ANALYSIS_LAZYVALUEINFO_H
#include "llvm/IR/PassManager.h"
#include "llvm/Pass.h"
namespace llvm {
class AssumptionCache;
class Constant;
class ConstantRange;
class DataLayout;
class DominatorTree;
class Instruction;
class TargetLibraryInfo;
class Value;
/// This pass computes, caches, and vends lazy value constraint information.
class LazyValueInfo {
friend class LazyValueInfoWrapperPass;
AssumptionCache *AC = nullptr;
const DataLayout *DL = nullptr;
class TargetLibraryInfo *TLI = nullptr;
void *PImpl = nullptr;
LazyValueInfo(const LazyValueInfo&) = delete;
void operator=(const LazyValueInfo&) = delete;
public:
~LazyValueInfo();
LazyValueInfo() {}
LazyValueInfo(AssumptionCache *AC_, const DataLayout *DL_,
TargetLibraryInfo *TLI_)
: AC(AC_), DL(DL_), TLI(TLI_) {}
LazyValueInfo(LazyValueInfo &&Arg)
: AC(Arg.AC), DL(Arg.DL), TLI(Arg.TLI), PImpl(Arg.PImpl) {
Arg.PImpl = nullptr;
}
LazyValueInfo &operator=(LazyValueInfo &&Arg) {
releaseMemory();
AC = Arg.AC;
DL = Arg.DL;
TLI = Arg.TLI;
PImpl = Arg.PImpl;
Arg.PImpl = nullptr;
return *this;
}
/// This is used to return true/false/dunno results.
enum Tristate {
Unknown = -1, False = 0, True = 1
};
// Public query interface.
/// 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.
Tristate getPredicateOnEdge(unsigned Pred, Value *V, Constant *C,
BasicBlock *FromBB, BasicBlock *ToBB,
Instruction *CxtI = nullptr);
/// Determine whether the specified value comparison with a constant is known
/// to be true or false at the specified instruction.
/// \p Pred is a CmpInst predicate. If \p UseBlockValue is true, the block
/// value is also taken into account.
Tristate getPredicateAt(unsigned Pred, Value *V, Constant *C,
Instruction *CxtI, bool UseBlockValue);
/// Determine whether the specified value comparison is known to be true
/// or false at the specified instruction. While this takes two Value's,
/// it still requires that one of them is a constant.
/// \p Pred is a CmpInst predicate.
/// If \p UseBlockValue is true, the block value is also taken into account.
Tristate getPredicateAt(unsigned Pred, Value *LHS, Value *RHS,
Instruction *CxtI, bool UseBlockValue);
/// Determine whether the specified value is known to be a constant at the
/// specified instruction. Return null if not.
Constant *getConstant(Value *V, Instruction *CxtI);
/// Return the ConstantRange constraint that is known to hold for the
/// specified value at the specified instruction. This may only be called
/// on integer-typed Values.
ConstantRange 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 = true);
/// Determine whether the specified value is known to be a
/// constant on the specified edge. Return null if not.
Constant *getConstantOnEdge(Value *V, BasicBlock *FromBB, BasicBlock *ToBB,
Instruction *CxtI = nullptr);
/// Return the ConstantRage constraint that is known to hold for the
/// specified value on the specified edge. This may be only be called
/// on integer-typed Values.
ConstantRange getConstantRangeOnEdge(Value *V, BasicBlock *FromBB,
BasicBlock *ToBB,
Instruction *CxtI = nullptr);
/// Inform the analysis cache that we have threaded an edge from
/// PredBB to OldSucc to be from PredBB to NewSucc instead.
void threadEdge(BasicBlock *PredBB, BasicBlock *OldSucc, BasicBlock *NewSucc);
/// Inform the analysis cache that we have erased a block.
void eraseBlock(BasicBlock *BB);
/// Print the \LazyValueInfo Analysis.
/// We pass in the DTree that is required for identifying which basic blocks
/// we can solve/print for, in the LVIPrinter.
void printLVI(Function &F, DominatorTree &DTree, raw_ostream &OS);
// For old PM pass. Delete once LazyValueInfoWrapperPass is gone.
void releaseMemory();
/// Handle invalidation events in the new pass manager.
bool invalidate(Function &F, const PreservedAnalyses &PA,
FunctionAnalysisManager::Invalidator &Inv);
};
/// Analysis to compute lazy value information.
class LazyValueAnalysis : public AnalysisInfoMixin<LazyValueAnalysis> {
public:
typedef LazyValueInfo Result;
Result run(Function &F, FunctionAnalysisManager &FAM);
private:
[PM] Change the static object whose address is used to uniquely identify analyses to have a common type which is enforced rather than using a char object and a `void *` type when used as an identifier. This has a number of advantages. First, it at least helps some of the confusion raised in Justin Lebar's code review of why `void *` was being used everywhere by having a stronger type that connects to documentation about this. However, perhaps more importantly, it addresses a serious issue where the alignment of these pointer-like identifiers was unknown. This made it hard to use them in pointer-like data structures. We were already dodging this in dangerous ways to create the "all analyses" entry. In a subsequent patch I attempted to use these with TinyPtrVector and things fell apart in a very bad way. And it isn't just a compile time or type system issue. Worse than that, the actual alignment of these pointer-like opaque identifiers wasn't guaranteed to be a useful alignment as they were just characters. This change introduces a type to use as the "key" object whose address forms the opaque identifier. This both forces the objects to have proper alignment, and provides type checking that we get it right everywhere. It also makes the types somewhat less mysterious than `void *`. We could go one step further and introduce a truly opaque pointer-like type to return from the `ID()` static function rather than returning `AnalysisKey *`, but that didn't seem to be a clear win so this is just the initial change to get to a reliably typed and aligned object serving is a key for all the analyses. Thanks to Richard Smith and Justin Lebar for helping pick plausible names and avoid making this refactoring many times. =] And thanks to Sean for the super fast review! While here, I've tried to move away from the "PassID" nomenclature entirely as it wasn't really helping and is overloaded with old pass manager constructs. Now we have IDs for analyses, and key objects whose address can be used as IDs. Where possible and clear I've shortened this to just "ID". In a few places I kept "AnalysisID" to make it clear what was being identified. Differential Revision: https://reviews.llvm.org/D27031 llvm-svn: 287783
2016-11-23 18:53:26 +01:00
static AnalysisKey Key;
friend struct AnalysisInfoMixin<LazyValueAnalysis>;
};
/// Wrapper around LazyValueInfo.
class LazyValueInfoWrapperPass : public FunctionPass {
LazyValueInfoWrapperPass(const LazyValueInfoWrapperPass&) = delete;
void operator=(const LazyValueInfoWrapperPass&) = delete;
public:
static char ID;
LazyValueInfoWrapperPass();
~LazyValueInfoWrapperPass() override {
assert(!Info.PImpl && "releaseMemory not called");
}
LazyValueInfo &getLVI();
void getAnalysisUsage(AnalysisUsage &AU) const override;
void releaseMemory() override;
bool runOnFunction(Function &F) override;
private:
LazyValueInfo Info;
};
} // end namespace llvm
#endif