2008-06-02 09:18:21 +08:00
|
|
|
//===- ValueTracking.cpp - Walk computations to compute properties --------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file contains routines that help analyze properties that chains of
|
|
|
|
// computations have.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "llvm/Analysis/ValueTracking.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/ADT/SmallPtrSet.h"
|
2015-01-14 19:23:27 +08:00
|
|
|
#include "llvm/Analysis/AssumptionCache.h"
|
2010-12-16 04:10:26 +08:00
|
|
|
#include "llvm/Analysis/InstructionSimplify.h"
|
2013-09-25 00:37:51 +08:00
|
|
|
#include "llvm/Analysis/MemoryBuiltins.h"
|
2014-05-20 13:13:21 +08:00
|
|
|
#include "llvm/IR/CallSite.h"
|
2014-03-04 20:24:34 +08:00
|
|
|
#include "llvm/IR/ConstantRange.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/Constants.h"
|
|
|
|
#include "llvm/IR/DataLayout.h"
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
#include "llvm/IR/Dominators.h"
|
2014-03-04 18:40:04 +08:00
|
|
|
#include "llvm/IR/GetElementPtrTypeIterator.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/GlobalAlias.h"
|
|
|
|
#include "llvm/IR/GlobalVariable.h"
|
|
|
|
#include "llvm/IR/Instructions.h"
|
|
|
|
#include "llvm/IR/IntrinsicInst.h"
|
|
|
|
#include "llvm/IR/LLVMContext.h"
|
|
|
|
#include "llvm/IR/Metadata.h"
|
|
|
|
#include "llvm/IR/Operator.h"
|
2014-03-04 19:08:18 +08:00
|
|
|
#include "llvm/IR/PatternMatch.h"
|
2014-07-15 09:55:03 +08:00
|
|
|
#include "llvm/Support/Debug.h"
|
2008-06-02 09:18:21 +08:00
|
|
|
#include "llvm/Support/MathExtras.h"
|
2008-06-04 12:46:14 +08:00
|
|
|
#include <cstring>
|
2008-06-02 09:18:21 +08:00
|
|
|
using namespace llvm;
|
2011-01-25 17:38:29 +08:00
|
|
|
using namespace llvm::PatternMatch;
|
|
|
|
|
|
|
|
const unsigned MaxDepth = 6;
|
|
|
|
|
2014-11-05 00:27:42 +08:00
|
|
|
/// Returns the bitwidth of the given scalar or pointer type (if unknown returns
|
|
|
|
/// 0). For vector types, returns the element type's bitwidth.
|
2012-10-09 00:38:25 +08:00
|
|
|
static unsigned getBitWidth(Type *Ty, const DataLayout *TD) {
|
2011-01-25 17:38:29 +08:00
|
|
|
if (unsigned BitWidth = Ty->getScalarSizeInBits())
|
|
|
|
return BitWidth;
|
2013-08-11 01:34:08 +08:00
|
|
|
|
|
|
|
return TD ? TD->getPointerTypeSizeInBits(Ty) : 0;
|
2011-01-25 17:38:29 +08:00
|
|
|
}
|
2008-06-02 09:18:21 +08:00
|
|
|
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
// Many of these functions have internal versions that take an assumption
|
|
|
|
// exclusion set. This is because of the potential for mutual recursion to
|
|
|
|
// cause computeKnownBits to repeatedly visit the same assume intrinsic. The
|
|
|
|
// classic case of this is assume(x = y), which will attempt to determine
|
|
|
|
// bits in x from bits in y, which will attempt to determine bits in y from
|
|
|
|
// bits in x, etc. Regarding the mutual recursion, computeKnownBits can call
|
|
|
|
// isKnownNonZero, which calls computeKnownBits and ComputeSignBit and
|
|
|
|
// isKnownToBeAPowerOfTwo (all of which can call computeKnownBits), and so on.
|
|
|
|
typedef SmallPtrSet<const Value *, 8> ExclInvsSet;
|
|
|
|
|
2014-09-12 16:56:53 +08:00
|
|
|
namespace {
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
// Simplifying using an assume can only be done in a particular control-flow
|
|
|
|
// context (the context instruction provides that context). If an assume and
|
|
|
|
// the context instruction are not in the same block then the DT helps in
|
|
|
|
// figuring out if we can use it.
|
|
|
|
struct Query {
|
|
|
|
ExclInvsSet ExclInvs;
|
2015-01-04 20:03:27 +08:00
|
|
|
AssumptionCache *AC;
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
const Instruction *CxtI;
|
|
|
|
const DominatorTree *DT;
|
|
|
|
|
2015-01-04 20:03:27 +08:00
|
|
|
Query(AssumptionCache *AC = nullptr, const Instruction *CxtI = nullptr,
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
const DominatorTree *DT = nullptr)
|
2015-01-04 20:03:27 +08:00
|
|
|
: AC(AC), CxtI(CxtI), DT(DT) {}
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
|
|
|
|
Query(const Query &Q, const Value *NewExcl)
|
2015-01-04 20:03:27 +08:00
|
|
|
: ExclInvs(Q.ExclInvs), AC(Q.AC), CxtI(Q.CxtI), DT(Q.DT) {
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
ExclInvs.insert(NewExcl);
|
|
|
|
}
|
|
|
|
};
|
2014-09-12 16:56:53 +08:00
|
|
|
} // end anonymous namespace
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
|
2014-11-05 00:09:50 +08:00
|
|
|
// Given the provided Value and, potentially, a context instruction, return
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
// the preferred context instruction (if any).
|
|
|
|
static const Instruction *safeCxtI(const Value *V, const Instruction *CxtI) {
|
|
|
|
// If we've been provided with a context instruction, then use that (provided
|
|
|
|
// it has been inserted).
|
|
|
|
if (CxtI && CxtI->getParent())
|
|
|
|
return CxtI;
|
|
|
|
|
|
|
|
// If the value is really an already-inserted instruction, then use that.
|
|
|
|
CxtI = dyn_cast<Instruction>(V);
|
|
|
|
if (CxtI && CxtI->getParent())
|
|
|
|
return CxtI;
|
|
|
|
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void computeKnownBits(Value *V, APInt &KnownZero, APInt &KnownOne,
|
|
|
|
const DataLayout *TD, unsigned Depth,
|
|
|
|
const Query &Q);
|
|
|
|
|
|
|
|
void llvm::computeKnownBits(Value *V, APInt &KnownZero, APInt &KnownOne,
|
|
|
|
const DataLayout *TD, unsigned Depth,
|
2015-01-04 20:03:27 +08:00
|
|
|
AssumptionCache *AC, const Instruction *CxtI,
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
const DominatorTree *DT) {
|
|
|
|
::computeKnownBits(V, KnownZero, KnownOne, TD, Depth,
|
2015-01-04 20:03:27 +08:00
|
|
|
Query(AC, safeCxtI(V, CxtI), DT));
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void ComputeSignBit(Value *V, bool &KnownZero, bool &KnownOne,
|
|
|
|
const DataLayout *TD, unsigned Depth,
|
|
|
|
const Query &Q);
|
|
|
|
|
|
|
|
void llvm::ComputeSignBit(Value *V, bool &KnownZero, bool &KnownOne,
|
|
|
|
const DataLayout *TD, unsigned Depth,
|
2015-01-04 20:03:27 +08:00
|
|
|
AssumptionCache *AC, const Instruction *CxtI,
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
const DominatorTree *DT) {
|
|
|
|
::ComputeSignBit(V, KnownZero, KnownOne, TD, Depth,
|
2015-01-04 20:03:27 +08:00
|
|
|
Query(AC, safeCxtI(V, CxtI), DT));
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool isKnownToBeAPowerOfTwo(Value *V, bool OrZero, unsigned Depth,
|
|
|
|
const Query &Q);
|
|
|
|
|
|
|
|
bool llvm::isKnownToBeAPowerOfTwo(Value *V, bool OrZero, unsigned Depth,
|
2015-01-04 20:03:27 +08:00
|
|
|
AssumptionCache *AC, const Instruction *CxtI,
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
const DominatorTree *DT) {
|
|
|
|
return ::isKnownToBeAPowerOfTwo(V, OrZero, Depth,
|
2015-01-04 20:03:27 +08:00
|
|
|
Query(AC, safeCxtI(V, CxtI), DT));
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool isKnownNonZero(Value *V, const DataLayout *TD, unsigned Depth,
|
|
|
|
const Query &Q);
|
|
|
|
|
|
|
|
bool llvm::isKnownNonZero(Value *V, const DataLayout *TD, unsigned Depth,
|
2015-01-04 20:03:27 +08:00
|
|
|
AssumptionCache *AC, const Instruction *CxtI,
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
const DominatorTree *DT) {
|
2015-01-04 20:03:27 +08:00
|
|
|
return ::isKnownNonZero(V, TD, Depth, Query(AC, safeCxtI(V, CxtI), DT));
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool MaskedValueIsZero(Value *V, const APInt &Mask,
|
|
|
|
const DataLayout *TD, unsigned Depth,
|
|
|
|
const Query &Q);
|
|
|
|
|
2015-01-04 20:03:27 +08:00
|
|
|
bool llvm::MaskedValueIsZero(Value *V, const APInt &Mask, const DataLayout *TD,
|
|
|
|
unsigned Depth, AssumptionCache *AC,
|
|
|
|
const Instruction *CxtI, const DominatorTree *DT) {
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
return ::MaskedValueIsZero(V, Mask, TD, Depth,
|
2015-01-04 20:03:27 +08:00
|
|
|
Query(AC, safeCxtI(V, CxtI), DT));
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned ComputeNumSignBits(Value *V, const DataLayout *TD,
|
|
|
|
unsigned Depth, const Query &Q);
|
|
|
|
|
|
|
|
unsigned llvm::ComputeNumSignBits(Value *V, const DataLayout *TD,
|
2015-01-04 20:03:27 +08:00
|
|
|
unsigned Depth, AssumptionCache *AC,
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
const Instruction *CxtI,
|
|
|
|
const DominatorTree *DT) {
|
2015-01-04 20:03:27 +08:00
|
|
|
return ::ComputeNumSignBits(V, TD, Depth, Query(AC, safeCxtI(V, CxtI), DT));
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
}
|
|
|
|
|
2014-05-15 05:14:37 +08:00
|
|
|
static void computeKnownBitsAddSub(bool Add, Value *Op0, Value *Op1, bool NSW,
|
|
|
|
APInt &KnownZero, APInt &KnownOne,
|
|
|
|
APInt &KnownZero2, APInt &KnownOne2,
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
const DataLayout *TD, unsigned Depth,
|
|
|
|
const Query &Q) {
|
|
|
|
if (!Add) {
|
|
|
|
if (ConstantInt *CLHS = dyn_cast<ConstantInt>(Op0)) {
|
|
|
|
// We know that the top bits of C-X are clear if X contains less bits
|
|
|
|
// than C (i.e. no wrap-around can happen). For example, 20-X is
|
|
|
|
// positive if we can prove that X is >= 0 and < 16.
|
|
|
|
if (!CLHS->getValue().isNegative()) {
|
|
|
|
unsigned BitWidth = KnownZero.getBitWidth();
|
|
|
|
unsigned NLZ = (CLHS->getValue()+1).countLeadingZeros();
|
|
|
|
// NLZ can't be BitWidth with no sign bit
|
|
|
|
APInt MaskV = APInt::getHighBitsSet(BitWidth, NLZ+1);
|
|
|
|
computeKnownBits(Op1, KnownZero2, KnownOne2, TD, Depth+1, Q);
|
|
|
|
|
|
|
|
// If all of the MaskV bits are known to be zero, then we know the
|
|
|
|
// output top bits are zero, because we now know that the output is
|
|
|
|
// from [0-C].
|
|
|
|
if ((KnownZero2 & MaskV) == MaskV) {
|
|
|
|
unsigned NLZ2 = CLHS->getValue().countLeadingZeros();
|
|
|
|
// Top bits known zero.
|
|
|
|
KnownZero = APInt::getHighBitsSet(BitWidth, NLZ2);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-04-04 20:51:34 +08:00
|
|
|
unsigned BitWidth = KnownZero.getBitWidth();
|
2012-03-09 17:23:50 +08:00
|
|
|
|
2014-08-22 08:40:43 +08:00
|
|
|
// If an initial sequence of bits in the result is not needed, the
|
|
|
|
// corresponding bits in the operands are not needed.
|
2012-03-09 17:23:50 +08:00
|
|
|
APInt LHSKnownZero(BitWidth, 0), LHSKnownOne(BitWidth, 0);
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(Op0, LHSKnownZero, LHSKnownOne, TD, Depth+1, Q);
|
|
|
|
computeKnownBits(Op1, KnownZero2, KnownOne2, TD, Depth+1, Q);
|
2012-03-09 17:23:50 +08:00
|
|
|
|
2014-08-22 08:40:43 +08:00
|
|
|
// Carry in a 1 for a subtract, rather than a 0.
|
|
|
|
APInt CarryIn(BitWidth, 0);
|
|
|
|
if (!Add) {
|
|
|
|
// Sum = LHS + ~RHS + 1
|
|
|
|
std::swap(KnownZero2, KnownOne2);
|
|
|
|
CarryIn.setBit(0);
|
2012-03-09 17:23:50 +08:00
|
|
|
}
|
|
|
|
|
2014-08-22 08:40:43 +08:00
|
|
|
APInt PossibleSumZero = ~LHSKnownZero + ~KnownZero2 + CarryIn;
|
|
|
|
APInt PossibleSumOne = LHSKnownOne + KnownOne2 + CarryIn;
|
|
|
|
|
|
|
|
// Compute known bits of the carry.
|
|
|
|
APInt CarryKnownZero = ~(PossibleSumZero ^ LHSKnownZero ^ KnownZero2);
|
|
|
|
APInt CarryKnownOne = PossibleSumOne ^ LHSKnownOne ^ KnownOne2;
|
|
|
|
|
|
|
|
// Compute set of known bits (where all three relevant bits are known).
|
|
|
|
APInt LHSKnown = LHSKnownZero | LHSKnownOne;
|
|
|
|
APInt RHSKnown = KnownZero2 | KnownOne2;
|
|
|
|
APInt CarryKnown = CarryKnownZero | CarryKnownOne;
|
|
|
|
APInt Known = LHSKnown & RHSKnown & CarryKnown;
|
|
|
|
|
|
|
|
assert((PossibleSumZero & Known) == (PossibleSumOne & Known) &&
|
|
|
|
"known bits of sum differ");
|
|
|
|
|
|
|
|
// Compute known bits of the result.
|
|
|
|
KnownZero = ~PossibleSumOne & Known;
|
|
|
|
KnownOne = PossibleSumOne & Known;
|
|
|
|
|
2012-03-09 17:23:50 +08:00
|
|
|
// Are we still trying to solve for the sign bit?
|
2014-08-22 08:40:43 +08:00
|
|
|
if (!Known.isNegative()) {
|
2012-03-09 17:23:50 +08:00
|
|
|
if (NSW) {
|
2014-08-22 08:40:43 +08:00
|
|
|
// Adding two non-negative numbers, or subtracting a negative number from
|
|
|
|
// a non-negative one, can't wrap into negative.
|
|
|
|
if (LHSKnownZero.isNegative() && KnownZero2.isNegative())
|
|
|
|
KnownZero |= APInt::getSignBit(BitWidth);
|
|
|
|
// Adding two negative numbers, or subtracting a non-negative number from
|
|
|
|
// a negative one, can't wrap into non-negative.
|
|
|
|
else if (LHSKnownOne.isNegative() && KnownOne2.isNegative())
|
|
|
|
KnownOne |= APInt::getSignBit(BitWidth);
|
2012-03-09 17:23:50 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-05-15 05:14:37 +08:00
|
|
|
static void computeKnownBitsMul(Value *Op0, Value *Op1, bool NSW,
|
|
|
|
APInt &KnownZero, APInt &KnownOne,
|
|
|
|
APInt &KnownZero2, APInt &KnownOne2,
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
const DataLayout *TD, unsigned Depth,
|
|
|
|
const Query &Q) {
|
2012-04-04 20:51:34 +08:00
|
|
|
unsigned BitWidth = KnownZero.getBitWidth();
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(Op1, KnownZero, KnownOne, TD, Depth+1, Q);
|
|
|
|
computeKnownBits(Op0, KnownZero2, KnownOne2, TD, Depth+1, Q);
|
2012-03-19 07:28:48 +08:00
|
|
|
|
|
|
|
bool isKnownNegative = false;
|
|
|
|
bool isKnownNonNegative = false;
|
|
|
|
// If the multiplication is known not to overflow, compute the sign bit.
|
2012-04-04 20:51:34 +08:00
|
|
|
if (NSW) {
|
2012-03-19 07:28:48 +08:00
|
|
|
if (Op0 == Op1) {
|
|
|
|
// The product of a number with itself is non-negative.
|
|
|
|
isKnownNonNegative = true;
|
|
|
|
} else {
|
|
|
|
bool isKnownNonNegativeOp1 = KnownZero.isNegative();
|
|
|
|
bool isKnownNonNegativeOp0 = KnownZero2.isNegative();
|
|
|
|
bool isKnownNegativeOp1 = KnownOne.isNegative();
|
|
|
|
bool isKnownNegativeOp0 = KnownOne2.isNegative();
|
|
|
|
// The product of two numbers with the same sign is non-negative.
|
|
|
|
isKnownNonNegative = (isKnownNegativeOp1 && isKnownNegativeOp0) ||
|
|
|
|
(isKnownNonNegativeOp1 && isKnownNonNegativeOp0);
|
|
|
|
// The product of a negative number and a non-negative number is either
|
|
|
|
// negative or zero.
|
|
|
|
if (!isKnownNonNegative)
|
|
|
|
isKnownNegative = (isKnownNegativeOp1 && isKnownNonNegativeOp0 &&
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
isKnownNonZero(Op0, TD, Depth, Q)) ||
|
2012-03-19 07:28:48 +08:00
|
|
|
(isKnownNegativeOp0 && isKnownNonNegativeOp1 &&
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
isKnownNonZero(Op1, TD, Depth, Q));
|
2012-03-19 07:28:48 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// If low bits are zero in either operand, output low known-0 bits.
|
|
|
|
// Also compute a conserative estimate for high known-0 bits.
|
|
|
|
// More trickiness is possible, but this is sufficient for the
|
|
|
|
// interesting case of alignment computation.
|
|
|
|
KnownOne.clearAllBits();
|
|
|
|
unsigned TrailZ = KnownZero.countTrailingOnes() +
|
|
|
|
KnownZero2.countTrailingOnes();
|
|
|
|
unsigned LeadZ = std::max(KnownZero.countLeadingOnes() +
|
|
|
|
KnownZero2.countLeadingOnes(),
|
|
|
|
BitWidth) - BitWidth;
|
|
|
|
|
|
|
|
TrailZ = std::min(TrailZ, BitWidth);
|
|
|
|
LeadZ = std::min(LeadZ, BitWidth);
|
|
|
|
KnownZero = APInt::getLowBitsSet(BitWidth, TrailZ) |
|
|
|
|
APInt::getHighBitsSet(BitWidth, LeadZ);
|
|
|
|
|
|
|
|
// Only make use of no-wrap flags if we failed to compute the sign bit
|
|
|
|
// directly. This matters if the multiplication always overflows, in
|
|
|
|
// which case we prefer to follow the result of the direct computation,
|
|
|
|
// though as the program is invoking undefined behaviour we can choose
|
|
|
|
// whatever we like here.
|
|
|
|
if (isKnownNonNegative && !KnownOne.isNegative())
|
|
|
|
KnownZero.setBit(BitWidth - 1);
|
|
|
|
else if (isKnownNegative && !KnownZero.isNegative())
|
|
|
|
KnownOne.setBit(BitWidth - 1);
|
|
|
|
}
|
|
|
|
|
2014-06-20 00:50:16 +08:00
|
|
|
void llvm::computeKnownBitsFromRangeMetadata(const MDNode &Ranges,
|
|
|
|
APInt &KnownZero) {
|
2012-04-04 20:51:34 +08:00
|
|
|
unsigned BitWidth = KnownZero.getBitWidth();
|
2012-03-30 23:52:11 +08:00
|
|
|
unsigned NumRanges = Ranges.getNumOperands() / 2;
|
|
|
|
assert(NumRanges >= 1);
|
|
|
|
|
|
|
|
// Use the high end of the ranges to find leading zeros.
|
|
|
|
unsigned MinLeadingZeros = BitWidth;
|
|
|
|
for (unsigned i = 0; i < NumRanges; ++i) {
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
ConstantInt *Lower =
|
|
|
|
mdconst::extract<ConstantInt>(Ranges.getOperand(2 * i + 0));
|
|
|
|
ConstantInt *Upper =
|
|
|
|
mdconst::extract<ConstantInt>(Ranges.getOperand(2 * i + 1));
|
2012-03-30 23:52:11 +08:00
|
|
|
ConstantRange Range(Lower->getValue(), Upper->getValue());
|
|
|
|
if (Range.isWrappedSet())
|
|
|
|
MinLeadingZeros = 0; // -1 has no zeros
|
|
|
|
unsigned LeadingZeros = (Upper->getValue() - 1).countLeadingZeros();
|
|
|
|
MinLeadingZeros = std::min(LeadingZeros, MinLeadingZeros);
|
|
|
|
}
|
|
|
|
|
2012-04-04 20:51:34 +08:00
|
|
|
KnownZero = APInt::getHighBitsSet(BitWidth, MinLeadingZeros);
|
2012-03-30 23:52:11 +08:00
|
|
|
}
|
2014-05-15 20:12:55 +08:00
|
|
|
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
static bool isEphemeralValueOf(Instruction *I, const Value *E) {
|
|
|
|
SmallVector<const Value *, 16> WorkSet(1, I);
|
|
|
|
SmallPtrSet<const Value *, 32> Visited;
|
|
|
|
SmallPtrSet<const Value *, 16> EphValues;
|
|
|
|
|
|
|
|
while (!WorkSet.empty()) {
|
|
|
|
const Value *V = WorkSet.pop_back_val();
|
2014-11-19 15:49:26 +08:00
|
|
|
if (!Visited.insert(V).second)
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
// If all uses of this value are ephemeral, then so is this value.
|
|
|
|
bool FoundNEUse = false;
|
|
|
|
for (const User *I : V->users())
|
|
|
|
if (!EphValues.count(I)) {
|
|
|
|
FoundNEUse = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!FoundNEUse) {
|
|
|
|
if (V == E)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
EphValues.insert(V);
|
|
|
|
if (const User *U = dyn_cast<User>(V))
|
|
|
|
for (User::const_op_iterator J = U->op_begin(), JE = U->op_end();
|
|
|
|
J != JE; ++J) {
|
|
|
|
if (isSafeToSpeculativelyExecute(*J))
|
|
|
|
WorkSet.push_back(*J);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Is this an intrinsic that cannot be speculated but also cannot trap?
|
|
|
|
static bool isAssumeLikeIntrinsic(const Instruction *I) {
|
|
|
|
if (const CallInst *CI = dyn_cast<CallInst>(I))
|
|
|
|
if (Function *F = CI->getCalledFunction())
|
|
|
|
switch (F->getIntrinsicID()) {
|
|
|
|
default: break;
|
|
|
|
// FIXME: This list is repeated from NoTTI::getIntrinsicCost.
|
|
|
|
case Intrinsic::assume:
|
|
|
|
case Intrinsic::dbg_declare:
|
|
|
|
case Intrinsic::dbg_value:
|
|
|
|
case Intrinsic::invariant_start:
|
|
|
|
case Intrinsic::invariant_end:
|
|
|
|
case Intrinsic::lifetime_start:
|
|
|
|
case Intrinsic::lifetime_end:
|
|
|
|
case Intrinsic::objectsize:
|
|
|
|
case Intrinsic::ptr_annotation:
|
|
|
|
case Intrinsic::var_annotation:
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool isValidAssumeForContext(Value *V, const Query &Q,
|
|
|
|
const DataLayout *DL) {
|
|
|
|
Instruction *Inv = cast<Instruction>(V);
|
|
|
|
|
|
|
|
// There are two restrictions on the use of an assume:
|
|
|
|
// 1. The assume must dominate the context (or the control flow must
|
|
|
|
// reach the assume whenever it reaches the context).
|
|
|
|
// 2. The context must not be in the assume's set of ephemeral values
|
|
|
|
// (otherwise we will use the assume to prove that the condition
|
|
|
|
// feeding the assume is trivially true, thus causing the removal of
|
|
|
|
// the assume).
|
|
|
|
|
|
|
|
if (Q.DT) {
|
|
|
|
if (Q.DT->dominates(Inv, Q.CxtI)) {
|
|
|
|
return true;
|
|
|
|
} else if (Inv->getParent() == Q.CxtI->getParent()) {
|
|
|
|
// The context comes first, but they're both in the same block. Make sure
|
|
|
|
// there is nothing in between that might interrupt the control flow.
|
|
|
|
for (BasicBlock::const_iterator I =
|
|
|
|
std::next(BasicBlock::const_iterator(Q.CxtI)),
|
|
|
|
IE(Inv); I != IE; ++I)
|
|
|
|
if (!isSafeToSpeculativelyExecute(I, DL) &&
|
|
|
|
!isAssumeLikeIntrinsic(I))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return !isEphemeralValueOf(Inv, Q.CxtI);
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// When we don't have a DT, we do a limited search...
|
|
|
|
if (Inv->getParent() == Q.CxtI->getParent()->getSinglePredecessor()) {
|
|
|
|
return true;
|
|
|
|
} else if (Inv->getParent() == Q.CxtI->getParent()) {
|
|
|
|
// Search forward from the assume until we reach the context (or the end
|
|
|
|
// of the block); the common case is that the assume will come first.
|
|
|
|
for (BasicBlock::iterator I = std::next(BasicBlock::iterator(Inv)),
|
|
|
|
IE = Inv->getParent()->end(); I != IE; ++I)
|
|
|
|
if (I == Q.CxtI)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// The context must come first...
|
|
|
|
for (BasicBlock::const_iterator I =
|
|
|
|
std::next(BasicBlock::const_iterator(Q.CxtI)),
|
|
|
|
IE(Inv); I != IE; ++I)
|
|
|
|
if (!isSafeToSpeculativelyExecute(I, DL) &&
|
|
|
|
!isAssumeLikeIntrinsic(I))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return !isEphemeralValueOf(Inv, Q.CxtI);
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool llvm::isValidAssumeForContext(const Instruction *I,
|
|
|
|
const Instruction *CxtI,
|
|
|
|
const DataLayout *DL,
|
|
|
|
const DominatorTree *DT) {
|
|
|
|
return ::isValidAssumeForContext(const_cast<Instruction*>(I),
|
|
|
|
Query(nullptr, CxtI, DT), DL);
|
|
|
|
}
|
|
|
|
|
|
|
|
template<typename LHS, typename RHS>
|
|
|
|
inline match_combine_or<CmpClass_match<LHS, RHS, ICmpInst, ICmpInst::Predicate>,
|
|
|
|
CmpClass_match<RHS, LHS, ICmpInst, ICmpInst::Predicate>>
|
|
|
|
m_c_ICmp(ICmpInst::Predicate &Pred, const LHS &L, const RHS &R) {
|
|
|
|
return m_CombineOr(m_ICmp(Pred, L, R), m_ICmp(Pred, R, L));
|
|
|
|
}
|
|
|
|
|
|
|
|
template<typename LHS, typename RHS>
|
|
|
|
inline match_combine_or<BinaryOp_match<LHS, RHS, Instruction::And>,
|
|
|
|
BinaryOp_match<RHS, LHS, Instruction::And>>
|
|
|
|
m_c_And(const LHS &L, const RHS &R) {
|
|
|
|
return m_CombineOr(m_And(L, R), m_And(R, L));
|
|
|
|
}
|
|
|
|
|
Add additional patterns for @llvm.assume in ValueTracking
This builds on r217342, which added the infrastructure to compute known bits
using assumptions (@llvm.assume calls). That original commit added only a few
patterns (to catch common cases related to determining pointer alignment); this
change adds several other patterns for simple cases.
r217342 contained that, for assume(v & b = a), bits in the mask
that are known to be one, we can propagate known bits from the a to v. It also
had a known-bits transfer for assume(a = b). This patch adds:
assume(~(v & b) = a) : For those bits in the mask that are known to be one, we
can propagate inverted known bits from the a to v.
assume(v | b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v.
assume(~(v | b) = a): For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v.
assume(v ^ b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v. For those bits in
b that are known to be one, we can propagate inverted
known bits from the a to v.
assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v. For those
bits in b that are known to be one, we can propagate
known bits from the a to v.
assume(v << c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v << c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >> c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v >> c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >=_s c) where c is non-negative: The sign bit of v is zero
assume(v >_s c) where c is at least -1: The sign bit of v is zero
assume(v <=_s c) where c is negative: The sign bit of v is one
assume(v <_s c) where c is non-positive: The sign bit of v is one
assume(v <=_u c): Transfer the known high zero bits
assume(v <_u c): Transfer the known high zero bits (if c is know to be a power
of 2, transfer one more)
A small addition to InstCombine was necessary for some of the test cases. The
problem is that when InstCombine was simplifying and, or, etc. it would fail to
check the 'do I know all of the bits' condition before checking less specific
conditions and would not fully constant-fold the result. I'm not sure how to
trigger this aside from using assumptions, so I've just included the change
here.
llvm-svn: 217343
2014-09-08 03:21:07 +08:00
|
|
|
template<typename LHS, typename RHS>
|
|
|
|
inline match_combine_or<BinaryOp_match<LHS, RHS, Instruction::Or>,
|
|
|
|
BinaryOp_match<RHS, LHS, Instruction::Or>>
|
|
|
|
m_c_Or(const LHS &L, const RHS &R) {
|
|
|
|
return m_CombineOr(m_Or(L, R), m_Or(R, L));
|
|
|
|
}
|
|
|
|
|
|
|
|
template<typename LHS, typename RHS>
|
|
|
|
inline match_combine_or<BinaryOp_match<LHS, RHS, Instruction::Xor>,
|
|
|
|
BinaryOp_match<RHS, LHS, Instruction::Xor>>
|
|
|
|
m_c_Xor(const LHS &L, const RHS &R) {
|
|
|
|
return m_CombineOr(m_Xor(L, R), m_Xor(R, L));
|
|
|
|
}
|
|
|
|
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
static void computeKnownBitsFromAssume(Value *V, APInt &KnownZero,
|
|
|
|
APInt &KnownOne,
|
|
|
|
const DataLayout *DL,
|
|
|
|
unsigned Depth, const Query &Q) {
|
|
|
|
// Use of assumptions is context-sensitive. If we don't have a context, we
|
|
|
|
// cannot use them!
|
2015-01-04 20:03:27 +08:00
|
|
|
if (!Q.AC || !Q.CxtI)
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
unsigned BitWidth = KnownZero.getBitWidth();
|
|
|
|
|
2015-01-04 20:03:27 +08:00
|
|
|
for (auto &AssumeVH : Q.AC->assumptions()) {
|
|
|
|
if (!AssumeVH)
|
|
|
|
continue;
|
|
|
|
CallInst *I = cast<CallInst>(AssumeVH);
|
2015-01-05 07:13:57 +08:00
|
|
|
assert(I->getParent()->getParent() == Q.CxtI->getParent()->getParent() &&
|
2015-01-04 20:03:27 +08:00
|
|
|
"Got assumption for the wrong function!");
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
if (Q.ExclInvs.count(I))
|
|
|
|
continue;
|
|
|
|
|
2014-11-25 07:44:28 +08:00
|
|
|
// Warning: This loop can end up being somewhat performance sensetive.
|
|
|
|
// We're running this loop for once for each value queried resulting in a
|
|
|
|
// runtime of ~O(#assumes * #values).
|
|
|
|
|
|
|
|
assert(isa<IntrinsicInst>(I) &&
|
|
|
|
dyn_cast<IntrinsicInst>(I)->getIntrinsicID() == Intrinsic::assume &&
|
|
|
|
"must be an assume intrinsic");
|
|
|
|
|
|
|
|
Value *Arg = I->getArgOperand(0);
|
|
|
|
|
|
|
|
if (Arg == V &&
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
isValidAssumeForContext(I, Q, DL)) {
|
|
|
|
assert(BitWidth == 1 && "assume operand is not i1?");
|
|
|
|
KnownZero.clearAllBits();
|
|
|
|
KnownOne.setAllBits();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-12-13 07:59:29 +08:00
|
|
|
// The remaining tests are all recursive, so bail out if we hit the limit.
|
|
|
|
if (Depth == MaxDepth)
|
|
|
|
continue;
|
|
|
|
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
Value *A, *B;
|
|
|
|
auto m_V = m_CombineOr(m_Specific(V),
|
|
|
|
m_CombineOr(m_PtrToInt(m_Specific(V)),
|
|
|
|
m_BitCast(m_Specific(V))));
|
|
|
|
|
|
|
|
CmpInst::Predicate Pred;
|
Add additional patterns for @llvm.assume in ValueTracking
This builds on r217342, which added the infrastructure to compute known bits
using assumptions (@llvm.assume calls). That original commit added only a few
patterns (to catch common cases related to determining pointer alignment); this
change adds several other patterns for simple cases.
r217342 contained that, for assume(v & b = a), bits in the mask
that are known to be one, we can propagate known bits from the a to v. It also
had a known-bits transfer for assume(a = b). This patch adds:
assume(~(v & b) = a) : For those bits in the mask that are known to be one, we
can propagate inverted known bits from the a to v.
assume(v | b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v.
assume(~(v | b) = a): For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v.
assume(v ^ b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v. For those bits in
b that are known to be one, we can propagate inverted
known bits from the a to v.
assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v. For those
bits in b that are known to be one, we can propagate
known bits from the a to v.
assume(v << c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v << c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >> c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v >> c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >=_s c) where c is non-negative: The sign bit of v is zero
assume(v >_s c) where c is at least -1: The sign bit of v is zero
assume(v <=_s c) where c is negative: The sign bit of v is one
assume(v <_s c) where c is non-positive: The sign bit of v is one
assume(v <=_u c): Transfer the known high zero bits
assume(v <_u c): Transfer the known high zero bits (if c is know to be a power
of 2, transfer one more)
A small addition to InstCombine was necessary for some of the test cases. The
problem is that when InstCombine was simplifying and, or, etc. it would fail to
check the 'do I know all of the bits' condition before checking less specific
conditions and would not fully constant-fold the result. I'm not sure how to
trigger this aside from using assumptions, so I've just included the change
here.
llvm-svn: 217343
2014-09-08 03:21:07 +08:00
|
|
|
ConstantInt *C;
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
// assume(v = a)
|
2014-11-25 07:44:28 +08:00
|
|
|
if (match(Arg, m_c_ICmp(Pred, m_V, m_Value(A))) &&
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
Pred == ICmpInst::ICMP_EQ && isValidAssumeForContext(I, Q, DL)) {
|
|
|
|
APInt RHSKnownZero(BitWidth, 0), RHSKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(A, RHSKnownZero, RHSKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
KnownZero |= RHSKnownZero;
|
|
|
|
KnownOne |= RHSKnownOne;
|
|
|
|
// assume(v & b = a)
|
2014-11-25 07:44:28 +08:00
|
|
|
} else if (match(Arg, m_c_ICmp(Pred, m_c_And(m_V, m_Value(B)),
|
|
|
|
m_Value(A))) &&
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
Pred == ICmpInst::ICMP_EQ && isValidAssumeForContext(I, Q, DL)) {
|
|
|
|
APInt RHSKnownZero(BitWidth, 0), RHSKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(A, RHSKnownZero, RHSKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
APInt MaskKnownZero(BitWidth, 0), MaskKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(B, MaskKnownZero, MaskKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
|
|
|
|
// For those bits in the mask that are known to be one, we can propagate
|
|
|
|
// known bits from the RHS to V.
|
|
|
|
KnownZero |= RHSKnownZero & MaskKnownOne;
|
|
|
|
KnownOne |= RHSKnownOne & MaskKnownOne;
|
Add additional patterns for @llvm.assume in ValueTracking
This builds on r217342, which added the infrastructure to compute known bits
using assumptions (@llvm.assume calls). That original commit added only a few
patterns (to catch common cases related to determining pointer alignment); this
change adds several other patterns for simple cases.
r217342 contained that, for assume(v & b = a), bits in the mask
that are known to be one, we can propagate known bits from the a to v. It also
had a known-bits transfer for assume(a = b). This patch adds:
assume(~(v & b) = a) : For those bits in the mask that are known to be one, we
can propagate inverted known bits from the a to v.
assume(v | b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v.
assume(~(v | b) = a): For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v.
assume(v ^ b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v. For those bits in
b that are known to be one, we can propagate inverted
known bits from the a to v.
assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v. For those
bits in b that are known to be one, we can propagate
known bits from the a to v.
assume(v << c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v << c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >> c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v >> c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >=_s c) where c is non-negative: The sign bit of v is zero
assume(v >_s c) where c is at least -1: The sign bit of v is zero
assume(v <=_s c) where c is negative: The sign bit of v is one
assume(v <_s c) where c is non-positive: The sign bit of v is one
assume(v <=_u c): Transfer the known high zero bits
assume(v <_u c): Transfer the known high zero bits (if c is know to be a power
of 2, transfer one more)
A small addition to InstCombine was necessary for some of the test cases. The
problem is that when InstCombine was simplifying and, or, etc. it would fail to
check the 'do I know all of the bits' condition before checking less specific
conditions and would not fully constant-fold the result. I'm not sure how to
trigger this aside from using assumptions, so I've just included the change
here.
llvm-svn: 217343
2014-09-08 03:21:07 +08:00
|
|
|
// assume(~(v & b) = a)
|
2014-11-25 07:44:28 +08:00
|
|
|
} else if (match(Arg, m_c_ICmp(Pred, m_Not(m_c_And(m_V, m_Value(B))),
|
|
|
|
m_Value(A))) &&
|
Add additional patterns for @llvm.assume in ValueTracking
This builds on r217342, which added the infrastructure to compute known bits
using assumptions (@llvm.assume calls). That original commit added only a few
patterns (to catch common cases related to determining pointer alignment); this
change adds several other patterns for simple cases.
r217342 contained that, for assume(v & b = a), bits in the mask
that are known to be one, we can propagate known bits from the a to v. It also
had a known-bits transfer for assume(a = b). This patch adds:
assume(~(v & b) = a) : For those bits in the mask that are known to be one, we
can propagate inverted known bits from the a to v.
assume(v | b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v.
assume(~(v | b) = a): For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v.
assume(v ^ b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v. For those bits in
b that are known to be one, we can propagate inverted
known bits from the a to v.
assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v. For those
bits in b that are known to be one, we can propagate
known bits from the a to v.
assume(v << c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v << c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >> c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v >> c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >=_s c) where c is non-negative: The sign bit of v is zero
assume(v >_s c) where c is at least -1: The sign bit of v is zero
assume(v <=_s c) where c is negative: The sign bit of v is one
assume(v <_s c) where c is non-positive: The sign bit of v is one
assume(v <=_u c): Transfer the known high zero bits
assume(v <_u c): Transfer the known high zero bits (if c is know to be a power
of 2, transfer one more)
A small addition to InstCombine was necessary for some of the test cases. The
problem is that when InstCombine was simplifying and, or, etc. it would fail to
check the 'do I know all of the bits' condition before checking less specific
conditions and would not fully constant-fold the result. I'm not sure how to
trigger this aside from using assumptions, so I've just included the change
here.
llvm-svn: 217343
2014-09-08 03:21:07 +08:00
|
|
|
Pred == ICmpInst::ICMP_EQ && isValidAssumeForContext(I, Q, DL)) {
|
|
|
|
APInt RHSKnownZero(BitWidth, 0), RHSKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(A, RHSKnownZero, RHSKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
APInt MaskKnownZero(BitWidth, 0), MaskKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(B, MaskKnownZero, MaskKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
|
|
|
|
// For those bits in the mask that are known to be one, we can propagate
|
|
|
|
// inverted known bits from the RHS to V.
|
|
|
|
KnownZero |= RHSKnownOne & MaskKnownOne;
|
|
|
|
KnownOne |= RHSKnownZero & MaskKnownOne;
|
|
|
|
// assume(v | b = a)
|
2014-11-25 07:44:28 +08:00
|
|
|
} else if (match(Arg, m_c_ICmp(Pred, m_c_Or(m_V, m_Value(B)),
|
|
|
|
m_Value(A))) &&
|
Add additional patterns for @llvm.assume in ValueTracking
This builds on r217342, which added the infrastructure to compute known bits
using assumptions (@llvm.assume calls). That original commit added only a few
patterns (to catch common cases related to determining pointer alignment); this
change adds several other patterns for simple cases.
r217342 contained that, for assume(v & b = a), bits in the mask
that are known to be one, we can propagate known bits from the a to v. It also
had a known-bits transfer for assume(a = b). This patch adds:
assume(~(v & b) = a) : For those bits in the mask that are known to be one, we
can propagate inverted known bits from the a to v.
assume(v | b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v.
assume(~(v | b) = a): For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v.
assume(v ^ b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v. For those bits in
b that are known to be one, we can propagate inverted
known bits from the a to v.
assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v. For those
bits in b that are known to be one, we can propagate
known bits from the a to v.
assume(v << c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v << c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >> c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v >> c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >=_s c) where c is non-negative: The sign bit of v is zero
assume(v >_s c) where c is at least -1: The sign bit of v is zero
assume(v <=_s c) where c is negative: The sign bit of v is one
assume(v <_s c) where c is non-positive: The sign bit of v is one
assume(v <=_u c): Transfer the known high zero bits
assume(v <_u c): Transfer the known high zero bits (if c is know to be a power
of 2, transfer one more)
A small addition to InstCombine was necessary for some of the test cases. The
problem is that when InstCombine was simplifying and, or, etc. it would fail to
check the 'do I know all of the bits' condition before checking less specific
conditions and would not fully constant-fold the result. I'm not sure how to
trigger this aside from using assumptions, so I've just included the change
here.
llvm-svn: 217343
2014-09-08 03:21:07 +08:00
|
|
|
Pred == ICmpInst::ICMP_EQ && isValidAssumeForContext(I, Q, DL)) {
|
|
|
|
APInt RHSKnownZero(BitWidth, 0), RHSKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(A, RHSKnownZero, RHSKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
APInt BKnownZero(BitWidth, 0), BKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(B, BKnownZero, BKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
|
|
|
|
// For those bits in B that are known to be zero, we can propagate known
|
|
|
|
// bits from the RHS to V.
|
|
|
|
KnownZero |= RHSKnownZero & BKnownZero;
|
|
|
|
KnownOne |= RHSKnownOne & BKnownZero;
|
|
|
|
// assume(~(v | b) = a)
|
2014-11-25 07:44:28 +08:00
|
|
|
} else if (match(Arg, m_c_ICmp(Pred, m_Not(m_c_Or(m_V, m_Value(B))),
|
|
|
|
m_Value(A))) &&
|
Add additional patterns for @llvm.assume in ValueTracking
This builds on r217342, which added the infrastructure to compute known bits
using assumptions (@llvm.assume calls). That original commit added only a few
patterns (to catch common cases related to determining pointer alignment); this
change adds several other patterns for simple cases.
r217342 contained that, for assume(v & b = a), bits in the mask
that are known to be one, we can propagate known bits from the a to v. It also
had a known-bits transfer for assume(a = b). This patch adds:
assume(~(v & b) = a) : For those bits in the mask that are known to be one, we
can propagate inverted known bits from the a to v.
assume(v | b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v.
assume(~(v | b) = a): For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v.
assume(v ^ b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v. For those bits in
b that are known to be one, we can propagate inverted
known bits from the a to v.
assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v. For those
bits in b that are known to be one, we can propagate
known bits from the a to v.
assume(v << c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v << c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >> c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v >> c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >=_s c) where c is non-negative: The sign bit of v is zero
assume(v >_s c) where c is at least -1: The sign bit of v is zero
assume(v <=_s c) where c is negative: The sign bit of v is one
assume(v <_s c) where c is non-positive: The sign bit of v is one
assume(v <=_u c): Transfer the known high zero bits
assume(v <_u c): Transfer the known high zero bits (if c is know to be a power
of 2, transfer one more)
A small addition to InstCombine was necessary for some of the test cases. The
problem is that when InstCombine was simplifying and, or, etc. it would fail to
check the 'do I know all of the bits' condition before checking less specific
conditions and would not fully constant-fold the result. I'm not sure how to
trigger this aside from using assumptions, so I've just included the change
here.
llvm-svn: 217343
2014-09-08 03:21:07 +08:00
|
|
|
Pred == ICmpInst::ICMP_EQ && isValidAssumeForContext(I, Q, DL)) {
|
|
|
|
APInt RHSKnownZero(BitWidth, 0), RHSKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(A, RHSKnownZero, RHSKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
APInt BKnownZero(BitWidth, 0), BKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(B, BKnownZero, BKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
|
|
|
|
// For those bits in B that are known to be zero, we can propagate
|
|
|
|
// inverted known bits from the RHS to V.
|
|
|
|
KnownZero |= RHSKnownOne & BKnownZero;
|
|
|
|
KnownOne |= RHSKnownZero & BKnownZero;
|
|
|
|
// assume(v ^ b = a)
|
2014-11-25 07:44:28 +08:00
|
|
|
} else if (match(Arg, m_c_ICmp(Pred, m_c_Xor(m_V, m_Value(B)),
|
|
|
|
m_Value(A))) &&
|
Add additional patterns for @llvm.assume in ValueTracking
This builds on r217342, which added the infrastructure to compute known bits
using assumptions (@llvm.assume calls). That original commit added only a few
patterns (to catch common cases related to determining pointer alignment); this
change adds several other patterns for simple cases.
r217342 contained that, for assume(v & b = a), bits in the mask
that are known to be one, we can propagate known bits from the a to v. It also
had a known-bits transfer for assume(a = b). This patch adds:
assume(~(v & b) = a) : For those bits in the mask that are known to be one, we
can propagate inverted known bits from the a to v.
assume(v | b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v.
assume(~(v | b) = a): For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v.
assume(v ^ b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v. For those bits in
b that are known to be one, we can propagate inverted
known bits from the a to v.
assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v. For those
bits in b that are known to be one, we can propagate
known bits from the a to v.
assume(v << c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v << c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >> c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v >> c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >=_s c) where c is non-negative: The sign bit of v is zero
assume(v >_s c) where c is at least -1: The sign bit of v is zero
assume(v <=_s c) where c is negative: The sign bit of v is one
assume(v <_s c) where c is non-positive: The sign bit of v is one
assume(v <=_u c): Transfer the known high zero bits
assume(v <_u c): Transfer the known high zero bits (if c is know to be a power
of 2, transfer one more)
A small addition to InstCombine was necessary for some of the test cases. The
problem is that when InstCombine was simplifying and, or, etc. it would fail to
check the 'do I know all of the bits' condition before checking less specific
conditions and would not fully constant-fold the result. I'm not sure how to
trigger this aside from using assumptions, so I've just included the change
here.
llvm-svn: 217343
2014-09-08 03:21:07 +08:00
|
|
|
Pred == ICmpInst::ICMP_EQ && isValidAssumeForContext(I, Q, DL)) {
|
|
|
|
APInt RHSKnownZero(BitWidth, 0), RHSKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(A, RHSKnownZero, RHSKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
APInt BKnownZero(BitWidth, 0), BKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(B, BKnownZero, BKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
|
|
|
|
// For those bits in B that are known to be zero, we can propagate known
|
|
|
|
// bits from the RHS to V. For those bits in B that are known to be one,
|
|
|
|
// we can propagate inverted known bits from the RHS to V.
|
|
|
|
KnownZero |= RHSKnownZero & BKnownZero;
|
|
|
|
KnownOne |= RHSKnownOne & BKnownZero;
|
|
|
|
KnownZero |= RHSKnownOne & BKnownOne;
|
|
|
|
KnownOne |= RHSKnownZero & BKnownOne;
|
|
|
|
// assume(~(v ^ b) = a)
|
2014-11-25 07:44:28 +08:00
|
|
|
} else if (match(Arg, m_c_ICmp(Pred, m_Not(m_c_Xor(m_V, m_Value(B))),
|
|
|
|
m_Value(A))) &&
|
Add additional patterns for @llvm.assume in ValueTracking
This builds on r217342, which added the infrastructure to compute known bits
using assumptions (@llvm.assume calls). That original commit added only a few
patterns (to catch common cases related to determining pointer alignment); this
change adds several other patterns for simple cases.
r217342 contained that, for assume(v & b = a), bits in the mask
that are known to be one, we can propagate known bits from the a to v. It also
had a known-bits transfer for assume(a = b). This patch adds:
assume(~(v & b) = a) : For those bits in the mask that are known to be one, we
can propagate inverted known bits from the a to v.
assume(v | b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v.
assume(~(v | b) = a): For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v.
assume(v ^ b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v. For those bits in
b that are known to be one, we can propagate inverted
known bits from the a to v.
assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v. For those
bits in b that are known to be one, we can propagate
known bits from the a to v.
assume(v << c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v << c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >> c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v >> c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >=_s c) where c is non-negative: The sign bit of v is zero
assume(v >_s c) where c is at least -1: The sign bit of v is zero
assume(v <=_s c) where c is negative: The sign bit of v is one
assume(v <_s c) where c is non-positive: The sign bit of v is one
assume(v <=_u c): Transfer the known high zero bits
assume(v <_u c): Transfer the known high zero bits (if c is know to be a power
of 2, transfer one more)
A small addition to InstCombine was necessary for some of the test cases. The
problem is that when InstCombine was simplifying and, or, etc. it would fail to
check the 'do I know all of the bits' condition before checking less specific
conditions and would not fully constant-fold the result. I'm not sure how to
trigger this aside from using assumptions, so I've just included the change
here.
llvm-svn: 217343
2014-09-08 03:21:07 +08:00
|
|
|
Pred == ICmpInst::ICMP_EQ && isValidAssumeForContext(I, Q, DL)) {
|
|
|
|
APInt RHSKnownZero(BitWidth, 0), RHSKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(A, RHSKnownZero, RHSKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
APInt BKnownZero(BitWidth, 0), BKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(B, BKnownZero, BKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
|
|
|
|
// For those bits in B that are known to be zero, we can propagate
|
|
|
|
// inverted known bits from the RHS to V. For those bits in B that are
|
|
|
|
// known to be one, we can propagate known bits from the RHS to V.
|
|
|
|
KnownZero |= RHSKnownOne & BKnownZero;
|
|
|
|
KnownOne |= RHSKnownZero & BKnownZero;
|
|
|
|
KnownZero |= RHSKnownZero & BKnownOne;
|
|
|
|
KnownOne |= RHSKnownOne & BKnownOne;
|
|
|
|
// assume(v << c = a)
|
2014-11-25 07:44:28 +08:00
|
|
|
} else if (match(Arg, m_c_ICmp(Pred, m_Shl(m_V, m_ConstantInt(C)),
|
|
|
|
m_Value(A))) &&
|
Add additional patterns for @llvm.assume in ValueTracking
This builds on r217342, which added the infrastructure to compute known bits
using assumptions (@llvm.assume calls). That original commit added only a few
patterns (to catch common cases related to determining pointer alignment); this
change adds several other patterns for simple cases.
r217342 contained that, for assume(v & b = a), bits in the mask
that are known to be one, we can propagate known bits from the a to v. It also
had a known-bits transfer for assume(a = b). This patch adds:
assume(~(v & b) = a) : For those bits in the mask that are known to be one, we
can propagate inverted known bits from the a to v.
assume(v | b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v.
assume(~(v | b) = a): For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v.
assume(v ^ b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v. For those bits in
b that are known to be one, we can propagate inverted
known bits from the a to v.
assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v. For those
bits in b that are known to be one, we can propagate
known bits from the a to v.
assume(v << c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v << c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >> c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v >> c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >=_s c) where c is non-negative: The sign bit of v is zero
assume(v >_s c) where c is at least -1: The sign bit of v is zero
assume(v <=_s c) where c is negative: The sign bit of v is one
assume(v <_s c) where c is non-positive: The sign bit of v is one
assume(v <=_u c): Transfer the known high zero bits
assume(v <_u c): Transfer the known high zero bits (if c is know to be a power
of 2, transfer one more)
A small addition to InstCombine was necessary for some of the test cases. The
problem is that when InstCombine was simplifying and, or, etc. it would fail to
check the 'do I know all of the bits' condition before checking less specific
conditions and would not fully constant-fold the result. I'm not sure how to
trigger this aside from using assumptions, so I've just included the change
here.
llvm-svn: 217343
2014-09-08 03:21:07 +08:00
|
|
|
Pred == ICmpInst::ICMP_EQ && isValidAssumeForContext(I, Q, DL)) {
|
|
|
|
APInt RHSKnownZero(BitWidth, 0), RHSKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(A, RHSKnownZero, RHSKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
// For those bits in RHS that are known, we can propagate them to known
|
|
|
|
// bits in V shifted to the right by C.
|
|
|
|
KnownZero |= RHSKnownZero.lshr(C->getZExtValue());
|
|
|
|
KnownOne |= RHSKnownOne.lshr(C->getZExtValue());
|
|
|
|
// assume(~(v << c) = a)
|
2014-11-25 07:44:28 +08:00
|
|
|
} else if (match(Arg, m_c_ICmp(Pred, m_Not(m_Shl(m_V, m_ConstantInt(C))),
|
|
|
|
m_Value(A))) &&
|
Add additional patterns for @llvm.assume in ValueTracking
This builds on r217342, which added the infrastructure to compute known bits
using assumptions (@llvm.assume calls). That original commit added only a few
patterns (to catch common cases related to determining pointer alignment); this
change adds several other patterns for simple cases.
r217342 contained that, for assume(v & b = a), bits in the mask
that are known to be one, we can propagate known bits from the a to v. It also
had a known-bits transfer for assume(a = b). This patch adds:
assume(~(v & b) = a) : For those bits in the mask that are known to be one, we
can propagate inverted known bits from the a to v.
assume(v | b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v.
assume(~(v | b) = a): For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v.
assume(v ^ b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v. For those bits in
b that are known to be one, we can propagate inverted
known bits from the a to v.
assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v. For those
bits in b that are known to be one, we can propagate
known bits from the a to v.
assume(v << c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v << c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >> c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v >> c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >=_s c) where c is non-negative: The sign bit of v is zero
assume(v >_s c) where c is at least -1: The sign bit of v is zero
assume(v <=_s c) where c is negative: The sign bit of v is one
assume(v <_s c) where c is non-positive: The sign bit of v is one
assume(v <=_u c): Transfer the known high zero bits
assume(v <_u c): Transfer the known high zero bits (if c is know to be a power
of 2, transfer one more)
A small addition to InstCombine was necessary for some of the test cases. The
problem is that when InstCombine was simplifying and, or, etc. it would fail to
check the 'do I know all of the bits' condition before checking less specific
conditions and would not fully constant-fold the result. I'm not sure how to
trigger this aside from using assumptions, so I've just included the change
here.
llvm-svn: 217343
2014-09-08 03:21:07 +08:00
|
|
|
Pred == ICmpInst::ICMP_EQ && isValidAssumeForContext(I, Q, DL)) {
|
|
|
|
APInt RHSKnownZero(BitWidth, 0), RHSKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(A, RHSKnownZero, RHSKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
// For those bits in RHS that are known, we can propagate them inverted
|
|
|
|
// to known bits in V shifted to the right by C.
|
|
|
|
KnownZero |= RHSKnownOne.lshr(C->getZExtValue());
|
|
|
|
KnownOne |= RHSKnownZero.lshr(C->getZExtValue());
|
|
|
|
// assume(v >> c = a)
|
2014-11-25 07:44:28 +08:00
|
|
|
} else if (match(Arg,
|
|
|
|
m_c_ICmp(Pred, m_CombineOr(m_LShr(m_V, m_ConstantInt(C)),
|
Add additional patterns for @llvm.assume in ValueTracking
This builds on r217342, which added the infrastructure to compute known bits
using assumptions (@llvm.assume calls). That original commit added only a few
patterns (to catch common cases related to determining pointer alignment); this
change adds several other patterns for simple cases.
r217342 contained that, for assume(v & b = a), bits in the mask
that are known to be one, we can propagate known bits from the a to v. It also
had a known-bits transfer for assume(a = b). This patch adds:
assume(~(v & b) = a) : For those bits in the mask that are known to be one, we
can propagate inverted known bits from the a to v.
assume(v | b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v.
assume(~(v | b) = a): For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v.
assume(v ^ b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v. For those bits in
b that are known to be one, we can propagate inverted
known bits from the a to v.
assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v. For those
bits in b that are known to be one, we can propagate
known bits from the a to v.
assume(v << c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v << c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >> c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v >> c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >=_s c) where c is non-negative: The sign bit of v is zero
assume(v >_s c) where c is at least -1: The sign bit of v is zero
assume(v <=_s c) where c is negative: The sign bit of v is one
assume(v <_s c) where c is non-positive: The sign bit of v is one
assume(v <=_u c): Transfer the known high zero bits
assume(v <_u c): Transfer the known high zero bits (if c is know to be a power
of 2, transfer one more)
A small addition to InstCombine was necessary for some of the test cases. The
problem is that when InstCombine was simplifying and, or, etc. it would fail to
check the 'do I know all of the bits' condition before checking less specific
conditions and would not fully constant-fold the result. I'm not sure how to
trigger this aside from using assumptions, so I've just included the change
here.
llvm-svn: 217343
2014-09-08 03:21:07 +08:00
|
|
|
m_AShr(m_V,
|
|
|
|
m_ConstantInt(C))),
|
2014-11-25 07:44:28 +08:00
|
|
|
m_Value(A))) &&
|
Add additional patterns for @llvm.assume in ValueTracking
This builds on r217342, which added the infrastructure to compute known bits
using assumptions (@llvm.assume calls). That original commit added only a few
patterns (to catch common cases related to determining pointer alignment); this
change adds several other patterns for simple cases.
r217342 contained that, for assume(v & b = a), bits in the mask
that are known to be one, we can propagate known bits from the a to v. It also
had a known-bits transfer for assume(a = b). This patch adds:
assume(~(v & b) = a) : For those bits in the mask that are known to be one, we
can propagate inverted known bits from the a to v.
assume(v | b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v.
assume(~(v | b) = a): For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v.
assume(v ^ b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v. For those bits in
b that are known to be one, we can propagate inverted
known bits from the a to v.
assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v. For those
bits in b that are known to be one, we can propagate
known bits from the a to v.
assume(v << c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v << c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >> c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v >> c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >=_s c) where c is non-negative: The sign bit of v is zero
assume(v >_s c) where c is at least -1: The sign bit of v is zero
assume(v <=_s c) where c is negative: The sign bit of v is one
assume(v <_s c) where c is non-positive: The sign bit of v is one
assume(v <=_u c): Transfer the known high zero bits
assume(v <_u c): Transfer the known high zero bits (if c is know to be a power
of 2, transfer one more)
A small addition to InstCombine was necessary for some of the test cases. The
problem is that when InstCombine was simplifying and, or, etc. it would fail to
check the 'do I know all of the bits' condition before checking less specific
conditions and would not fully constant-fold the result. I'm not sure how to
trigger this aside from using assumptions, so I've just included the change
here.
llvm-svn: 217343
2014-09-08 03:21:07 +08:00
|
|
|
Pred == ICmpInst::ICMP_EQ && isValidAssumeForContext(I, Q, DL)) {
|
|
|
|
APInt RHSKnownZero(BitWidth, 0), RHSKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(A, RHSKnownZero, RHSKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
// For those bits in RHS that are known, we can propagate them to known
|
|
|
|
// bits in V shifted to the right by C.
|
|
|
|
KnownZero |= RHSKnownZero << C->getZExtValue();
|
|
|
|
KnownOne |= RHSKnownOne << C->getZExtValue();
|
|
|
|
// assume(~(v >> c) = a)
|
2014-11-25 07:44:28 +08:00
|
|
|
} else if (match(Arg, m_c_ICmp(Pred, m_Not(m_CombineOr(
|
Add additional patterns for @llvm.assume in ValueTracking
This builds on r217342, which added the infrastructure to compute known bits
using assumptions (@llvm.assume calls). That original commit added only a few
patterns (to catch common cases related to determining pointer alignment); this
change adds several other patterns for simple cases.
r217342 contained that, for assume(v & b = a), bits in the mask
that are known to be one, we can propagate known bits from the a to v. It also
had a known-bits transfer for assume(a = b). This patch adds:
assume(~(v & b) = a) : For those bits in the mask that are known to be one, we
can propagate inverted known bits from the a to v.
assume(v | b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v.
assume(~(v | b) = a): For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v.
assume(v ^ b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v. For those bits in
b that are known to be one, we can propagate inverted
known bits from the a to v.
assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v. For those
bits in b that are known to be one, we can propagate
known bits from the a to v.
assume(v << c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v << c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >> c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v >> c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >=_s c) where c is non-negative: The sign bit of v is zero
assume(v >_s c) where c is at least -1: The sign bit of v is zero
assume(v <=_s c) where c is negative: The sign bit of v is one
assume(v <_s c) where c is non-positive: The sign bit of v is one
assume(v <=_u c): Transfer the known high zero bits
assume(v <_u c): Transfer the known high zero bits (if c is know to be a power
of 2, transfer one more)
A small addition to InstCombine was necessary for some of the test cases. The
problem is that when InstCombine was simplifying and, or, etc. it would fail to
check the 'do I know all of the bits' condition before checking less specific
conditions and would not fully constant-fold the result. I'm not sure how to
trigger this aside from using assumptions, so I've just included the change
here.
llvm-svn: 217343
2014-09-08 03:21:07 +08:00
|
|
|
m_LShr(m_V, m_ConstantInt(C)),
|
|
|
|
m_AShr(m_V, m_ConstantInt(C)))),
|
2014-11-25 07:44:28 +08:00
|
|
|
m_Value(A))) &&
|
Add additional patterns for @llvm.assume in ValueTracking
This builds on r217342, which added the infrastructure to compute known bits
using assumptions (@llvm.assume calls). That original commit added only a few
patterns (to catch common cases related to determining pointer alignment); this
change adds several other patterns for simple cases.
r217342 contained that, for assume(v & b = a), bits in the mask
that are known to be one, we can propagate known bits from the a to v. It also
had a known-bits transfer for assume(a = b). This patch adds:
assume(~(v & b) = a) : For those bits in the mask that are known to be one, we
can propagate inverted known bits from the a to v.
assume(v | b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v.
assume(~(v | b) = a): For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v.
assume(v ^ b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v. For those bits in
b that are known to be one, we can propagate inverted
known bits from the a to v.
assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v. For those
bits in b that are known to be one, we can propagate
known bits from the a to v.
assume(v << c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v << c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >> c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v >> c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >=_s c) where c is non-negative: The sign bit of v is zero
assume(v >_s c) where c is at least -1: The sign bit of v is zero
assume(v <=_s c) where c is negative: The sign bit of v is one
assume(v <_s c) where c is non-positive: The sign bit of v is one
assume(v <=_u c): Transfer the known high zero bits
assume(v <_u c): Transfer the known high zero bits (if c is know to be a power
of 2, transfer one more)
A small addition to InstCombine was necessary for some of the test cases. The
problem is that when InstCombine was simplifying and, or, etc. it would fail to
check the 'do I know all of the bits' condition before checking less specific
conditions and would not fully constant-fold the result. I'm not sure how to
trigger this aside from using assumptions, so I've just included the change
here.
llvm-svn: 217343
2014-09-08 03:21:07 +08:00
|
|
|
Pred == ICmpInst::ICMP_EQ && isValidAssumeForContext(I, Q, DL)) {
|
|
|
|
APInt RHSKnownZero(BitWidth, 0), RHSKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(A, RHSKnownZero, RHSKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
// For those bits in RHS that are known, we can propagate them inverted
|
|
|
|
// to known bits in V shifted to the right by C.
|
|
|
|
KnownZero |= RHSKnownOne << C->getZExtValue();
|
|
|
|
KnownOne |= RHSKnownZero << C->getZExtValue();
|
|
|
|
// assume(v >=_s c) where c is non-negative
|
2014-11-25 07:44:28 +08:00
|
|
|
} else if (match(Arg, m_ICmp(Pred, m_V, m_Value(A))) &&
|
Add additional patterns for @llvm.assume in ValueTracking
This builds on r217342, which added the infrastructure to compute known bits
using assumptions (@llvm.assume calls). That original commit added only a few
patterns (to catch common cases related to determining pointer alignment); this
change adds several other patterns for simple cases.
r217342 contained that, for assume(v & b = a), bits in the mask
that are known to be one, we can propagate known bits from the a to v. It also
had a known-bits transfer for assume(a = b). This patch adds:
assume(~(v & b) = a) : For those bits in the mask that are known to be one, we
can propagate inverted known bits from the a to v.
assume(v | b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v.
assume(~(v | b) = a): For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v.
assume(v ^ b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v. For those bits in
b that are known to be one, we can propagate inverted
known bits from the a to v.
assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v. For those
bits in b that are known to be one, we can propagate
known bits from the a to v.
assume(v << c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v << c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >> c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v >> c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >=_s c) where c is non-negative: The sign bit of v is zero
assume(v >_s c) where c is at least -1: The sign bit of v is zero
assume(v <=_s c) where c is negative: The sign bit of v is one
assume(v <_s c) where c is non-positive: The sign bit of v is one
assume(v <=_u c): Transfer the known high zero bits
assume(v <_u c): Transfer the known high zero bits (if c is know to be a power
of 2, transfer one more)
A small addition to InstCombine was necessary for some of the test cases. The
problem is that when InstCombine was simplifying and, or, etc. it would fail to
check the 'do I know all of the bits' condition before checking less specific
conditions and would not fully constant-fold the result. I'm not sure how to
trigger this aside from using assumptions, so I've just included the change
here.
llvm-svn: 217343
2014-09-08 03:21:07 +08:00
|
|
|
Pred == ICmpInst::ICMP_SGE &&
|
|
|
|
isValidAssumeForContext(I, Q, DL)) {
|
|
|
|
APInt RHSKnownZero(BitWidth, 0), RHSKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(A, RHSKnownZero, RHSKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
|
|
|
|
if (RHSKnownZero.isNegative()) {
|
|
|
|
// We know that the sign bit is zero.
|
|
|
|
KnownZero |= APInt::getSignBit(BitWidth);
|
|
|
|
}
|
|
|
|
// assume(v >_s c) where c is at least -1.
|
2014-11-25 07:44:28 +08:00
|
|
|
} else if (match(Arg, m_ICmp(Pred, m_V, m_Value(A))) &&
|
Add additional patterns for @llvm.assume in ValueTracking
This builds on r217342, which added the infrastructure to compute known bits
using assumptions (@llvm.assume calls). That original commit added only a few
patterns (to catch common cases related to determining pointer alignment); this
change adds several other patterns for simple cases.
r217342 contained that, for assume(v & b = a), bits in the mask
that are known to be one, we can propagate known bits from the a to v. It also
had a known-bits transfer for assume(a = b). This patch adds:
assume(~(v & b) = a) : For those bits in the mask that are known to be one, we
can propagate inverted known bits from the a to v.
assume(v | b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v.
assume(~(v | b) = a): For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v.
assume(v ^ b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v. For those bits in
b that are known to be one, we can propagate inverted
known bits from the a to v.
assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v. For those
bits in b that are known to be one, we can propagate
known bits from the a to v.
assume(v << c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v << c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >> c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v >> c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >=_s c) where c is non-negative: The sign bit of v is zero
assume(v >_s c) where c is at least -1: The sign bit of v is zero
assume(v <=_s c) where c is negative: The sign bit of v is one
assume(v <_s c) where c is non-positive: The sign bit of v is one
assume(v <=_u c): Transfer the known high zero bits
assume(v <_u c): Transfer the known high zero bits (if c is know to be a power
of 2, transfer one more)
A small addition to InstCombine was necessary for some of the test cases. The
problem is that when InstCombine was simplifying and, or, etc. it would fail to
check the 'do I know all of the bits' condition before checking less specific
conditions and would not fully constant-fold the result. I'm not sure how to
trigger this aside from using assumptions, so I've just included the change
here.
llvm-svn: 217343
2014-09-08 03:21:07 +08:00
|
|
|
Pred == ICmpInst::ICMP_SGT &&
|
|
|
|
isValidAssumeForContext(I, Q, DL)) {
|
|
|
|
APInt RHSKnownZero(BitWidth, 0), RHSKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(A, RHSKnownZero, RHSKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
|
|
|
|
if (RHSKnownOne.isAllOnesValue() || RHSKnownZero.isNegative()) {
|
|
|
|
// We know that the sign bit is zero.
|
|
|
|
KnownZero |= APInt::getSignBit(BitWidth);
|
|
|
|
}
|
|
|
|
// assume(v <=_s c) where c is negative
|
2014-11-25 07:44:28 +08:00
|
|
|
} else if (match(Arg, m_ICmp(Pred, m_V, m_Value(A))) &&
|
Add additional patterns for @llvm.assume in ValueTracking
This builds on r217342, which added the infrastructure to compute known bits
using assumptions (@llvm.assume calls). That original commit added only a few
patterns (to catch common cases related to determining pointer alignment); this
change adds several other patterns for simple cases.
r217342 contained that, for assume(v & b = a), bits in the mask
that are known to be one, we can propagate known bits from the a to v. It also
had a known-bits transfer for assume(a = b). This patch adds:
assume(~(v & b) = a) : For those bits in the mask that are known to be one, we
can propagate inverted known bits from the a to v.
assume(v | b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v.
assume(~(v | b) = a): For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v.
assume(v ^ b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v. For those bits in
b that are known to be one, we can propagate inverted
known bits from the a to v.
assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v. For those
bits in b that are known to be one, we can propagate
known bits from the a to v.
assume(v << c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v << c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >> c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v >> c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >=_s c) where c is non-negative: The sign bit of v is zero
assume(v >_s c) where c is at least -1: The sign bit of v is zero
assume(v <=_s c) where c is negative: The sign bit of v is one
assume(v <_s c) where c is non-positive: The sign bit of v is one
assume(v <=_u c): Transfer the known high zero bits
assume(v <_u c): Transfer the known high zero bits (if c is know to be a power
of 2, transfer one more)
A small addition to InstCombine was necessary for some of the test cases. The
problem is that when InstCombine was simplifying and, or, etc. it would fail to
check the 'do I know all of the bits' condition before checking less specific
conditions and would not fully constant-fold the result. I'm not sure how to
trigger this aside from using assumptions, so I've just included the change
here.
llvm-svn: 217343
2014-09-08 03:21:07 +08:00
|
|
|
Pred == ICmpInst::ICMP_SLE &&
|
|
|
|
isValidAssumeForContext(I, Q, DL)) {
|
|
|
|
APInt RHSKnownZero(BitWidth, 0), RHSKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(A, RHSKnownZero, RHSKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
|
|
|
|
if (RHSKnownOne.isNegative()) {
|
|
|
|
// We know that the sign bit is one.
|
|
|
|
KnownOne |= APInt::getSignBit(BitWidth);
|
|
|
|
}
|
|
|
|
// assume(v <_s c) where c is non-positive
|
2014-11-25 07:44:28 +08:00
|
|
|
} else if (match(Arg, m_ICmp(Pred, m_V, m_Value(A))) &&
|
Add additional patterns for @llvm.assume in ValueTracking
This builds on r217342, which added the infrastructure to compute known bits
using assumptions (@llvm.assume calls). That original commit added only a few
patterns (to catch common cases related to determining pointer alignment); this
change adds several other patterns for simple cases.
r217342 contained that, for assume(v & b = a), bits in the mask
that are known to be one, we can propagate known bits from the a to v. It also
had a known-bits transfer for assume(a = b). This patch adds:
assume(~(v & b) = a) : For those bits in the mask that are known to be one, we
can propagate inverted known bits from the a to v.
assume(v | b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v.
assume(~(v | b) = a): For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v.
assume(v ^ b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v. For those bits in
b that are known to be one, we can propagate inverted
known bits from the a to v.
assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v. For those
bits in b that are known to be one, we can propagate
known bits from the a to v.
assume(v << c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v << c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >> c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v >> c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >=_s c) where c is non-negative: The sign bit of v is zero
assume(v >_s c) where c is at least -1: The sign bit of v is zero
assume(v <=_s c) where c is negative: The sign bit of v is one
assume(v <_s c) where c is non-positive: The sign bit of v is one
assume(v <=_u c): Transfer the known high zero bits
assume(v <_u c): Transfer the known high zero bits (if c is know to be a power
of 2, transfer one more)
A small addition to InstCombine was necessary for some of the test cases. The
problem is that when InstCombine was simplifying and, or, etc. it would fail to
check the 'do I know all of the bits' condition before checking less specific
conditions and would not fully constant-fold the result. I'm not sure how to
trigger this aside from using assumptions, so I've just included the change
here.
llvm-svn: 217343
2014-09-08 03:21:07 +08:00
|
|
|
Pred == ICmpInst::ICMP_SLT &&
|
|
|
|
isValidAssumeForContext(I, Q, DL)) {
|
|
|
|
APInt RHSKnownZero(BitWidth, 0), RHSKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(A, RHSKnownZero, RHSKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
|
|
|
|
if (RHSKnownZero.isAllOnesValue() || RHSKnownOne.isNegative()) {
|
|
|
|
// We know that the sign bit is one.
|
|
|
|
KnownOne |= APInt::getSignBit(BitWidth);
|
|
|
|
}
|
|
|
|
// assume(v <=_u c)
|
2014-11-25 07:44:28 +08:00
|
|
|
} else if (match(Arg, m_ICmp(Pred, m_V, m_Value(A))) &&
|
Add additional patterns for @llvm.assume in ValueTracking
This builds on r217342, which added the infrastructure to compute known bits
using assumptions (@llvm.assume calls). That original commit added only a few
patterns (to catch common cases related to determining pointer alignment); this
change adds several other patterns for simple cases.
r217342 contained that, for assume(v & b = a), bits in the mask
that are known to be one, we can propagate known bits from the a to v. It also
had a known-bits transfer for assume(a = b). This patch adds:
assume(~(v & b) = a) : For those bits in the mask that are known to be one, we
can propagate inverted known bits from the a to v.
assume(v | b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v.
assume(~(v | b) = a): For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v.
assume(v ^ b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v. For those bits in
b that are known to be one, we can propagate inverted
known bits from the a to v.
assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v. For those
bits in b that are known to be one, we can propagate
known bits from the a to v.
assume(v << c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v << c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >> c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v >> c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >=_s c) where c is non-negative: The sign bit of v is zero
assume(v >_s c) where c is at least -1: The sign bit of v is zero
assume(v <=_s c) where c is negative: The sign bit of v is one
assume(v <_s c) where c is non-positive: The sign bit of v is one
assume(v <=_u c): Transfer the known high zero bits
assume(v <_u c): Transfer the known high zero bits (if c is know to be a power
of 2, transfer one more)
A small addition to InstCombine was necessary for some of the test cases. The
problem is that when InstCombine was simplifying and, or, etc. it would fail to
check the 'do I know all of the bits' condition before checking less specific
conditions and would not fully constant-fold the result. I'm not sure how to
trigger this aside from using assumptions, so I've just included the change
here.
llvm-svn: 217343
2014-09-08 03:21:07 +08:00
|
|
|
Pred == ICmpInst::ICMP_ULE &&
|
|
|
|
isValidAssumeForContext(I, Q, DL)) {
|
|
|
|
APInt RHSKnownZero(BitWidth, 0), RHSKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(A, RHSKnownZero, RHSKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
|
|
|
|
// Whatever high bits in c are zero are known to be zero.
|
|
|
|
KnownZero |=
|
|
|
|
APInt::getHighBitsSet(BitWidth, RHSKnownZero.countLeadingOnes());
|
|
|
|
// assume(v <_u c)
|
2014-11-25 07:44:28 +08:00
|
|
|
} else if (match(Arg, m_ICmp(Pred, m_V, m_Value(A))) &&
|
Add additional patterns for @llvm.assume in ValueTracking
This builds on r217342, which added the infrastructure to compute known bits
using assumptions (@llvm.assume calls). That original commit added only a few
patterns (to catch common cases related to determining pointer alignment); this
change adds several other patterns for simple cases.
r217342 contained that, for assume(v & b = a), bits in the mask
that are known to be one, we can propagate known bits from the a to v. It also
had a known-bits transfer for assume(a = b). This patch adds:
assume(~(v & b) = a) : For those bits in the mask that are known to be one, we
can propagate inverted known bits from the a to v.
assume(v | b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v.
assume(~(v | b) = a): For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v.
assume(v ^ b = a) : For those bits in b that are known to be zero, we can
propagate known bits from the a to v. For those bits in
b that are known to be one, we can propagate inverted
known bits from the a to v.
assume(~(v ^ b) = a) : For those bits in b that are known to be zero, we can
propagate inverted known bits from the a to v. For those
bits in b that are known to be one, we can propagate
known bits from the a to v.
assume(v << c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v << c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >> c = a) : For those bits in a that are known, we can propagate them
to known bits in v shifted to the right by c.
assume(~(v >> c) = a) : For those bits in a that are known, we can propagate
them inverted to known bits in v shifted to the right by c.
assume(v >=_s c) where c is non-negative: The sign bit of v is zero
assume(v >_s c) where c is at least -1: The sign bit of v is zero
assume(v <=_s c) where c is negative: The sign bit of v is one
assume(v <_s c) where c is non-positive: The sign bit of v is one
assume(v <=_u c): Transfer the known high zero bits
assume(v <_u c): Transfer the known high zero bits (if c is know to be a power
of 2, transfer one more)
A small addition to InstCombine was necessary for some of the test cases. The
problem is that when InstCombine was simplifying and, or, etc. it would fail to
check the 'do I know all of the bits' condition before checking less specific
conditions and would not fully constant-fold the result. I'm not sure how to
trigger this aside from using assumptions, so I've just included the change
here.
llvm-svn: 217343
2014-09-08 03:21:07 +08:00
|
|
|
Pred == ICmpInst::ICMP_ULT &&
|
|
|
|
isValidAssumeForContext(I, Q, DL)) {
|
|
|
|
APInt RHSKnownZero(BitWidth, 0), RHSKnownOne(BitWidth, 0);
|
|
|
|
computeKnownBits(A, RHSKnownZero, RHSKnownOne, DL, Depth+1, Query(Q, I));
|
|
|
|
|
|
|
|
// Whatever high bits in c are zero are known to be zero (if c is a power
|
|
|
|
// of 2, then one more).
|
|
|
|
if (isKnownToBeAPowerOfTwo(A, false, Depth+1, Query(Q, I)))
|
|
|
|
KnownZero |=
|
|
|
|
APInt::getHighBitsSet(BitWidth, RHSKnownZero.countLeadingOnes()+1);
|
|
|
|
else
|
|
|
|
KnownZero |=
|
|
|
|
APInt::getHighBitsSet(BitWidth, RHSKnownZero.countLeadingOnes());
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-05-15 05:14:37 +08:00
|
|
|
/// Determine which bits of V are known to be either zero or one and return
|
|
|
|
/// them in the KnownZero/KnownOne bit sets.
|
2012-04-04 20:51:34 +08:00
|
|
|
///
|
2008-06-02 09:18:21 +08:00
|
|
|
/// NOTE: we cannot consider 'undef' to be "IsZero" here. The problem is that
|
|
|
|
/// we cannot optimize based on the assumption that it is zero without changing
|
|
|
|
/// it to be an explicit zero. If we don't change it to zero, other code could
|
|
|
|
/// optimized based on the contradictory assumption that it is non-zero.
|
|
|
|
/// Because instcombine aggressively folds operations with undef args anyway,
|
|
|
|
/// this won't lose us code quality.
|
2009-09-08 08:06:16 +08:00
|
|
|
///
|
|
|
|
/// This function is defined on values with integer type, values with pointer
|
|
|
|
/// type (but only if TD is non-null), and vectors of integers. In the case
|
2012-04-04 20:51:34 +08:00
|
|
|
/// where V is a vector, known zero, and known one values are the
|
2009-09-08 08:06:16 +08:00
|
|
|
/// same width as the vector element, and the bit is set only if it is true
|
|
|
|
/// for all of the elements in the vector.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
void computeKnownBits(Value *V, APInt &KnownZero, APInt &KnownOne,
|
|
|
|
const DataLayout *TD, unsigned Depth,
|
|
|
|
const Query &Q) {
|
2008-06-02 09:18:21 +08:00
|
|
|
assert(V && "No Value?");
|
2009-05-21 10:28:33 +08:00
|
|
|
assert(Depth <= MaxDepth && "Limit Search Depth");
|
2012-04-04 20:51:34 +08:00
|
|
|
unsigned BitWidth = KnownZero.getBitWidth();
|
|
|
|
|
2011-12-05 14:29:09 +08:00
|
|
|
assert((V->getType()->isIntOrIntVectorTy() ||
|
|
|
|
V->getType()->getScalarType()->isPointerTy()) &&
|
|
|
|
"Not integer or pointer type!");
|
2009-06-16 06:12:54 +08:00
|
|
|
assert((!TD ||
|
|
|
|
TD->getTypeSizeInBits(V->getType()->getScalarType()) == BitWidth) &&
|
2010-02-16 00:12:20 +08:00
|
|
|
(!V->getType()->isIntOrIntVectorTy() ||
|
2009-06-16 06:12:54 +08:00
|
|
|
V->getType()->getScalarSizeInBits() == BitWidth) &&
|
2011-12-05 14:29:09 +08:00
|
|
|
KnownZero.getBitWidth() == BitWidth &&
|
2008-06-02 09:18:21 +08:00
|
|
|
KnownOne.getBitWidth() == BitWidth &&
|
2014-05-14 16:00:07 +08:00
|
|
|
"V, KnownOne and KnownZero should have same BitWidth");
|
2008-06-02 09:18:21 +08:00
|
|
|
|
|
|
|
if (ConstantInt *CI = dyn_cast<ConstantInt>(V)) {
|
|
|
|
// We know all of the bits for a constant!
|
2012-04-04 20:51:34 +08:00
|
|
|
KnownOne = CI->getValue();
|
|
|
|
KnownZero = ~KnownOne;
|
2008-06-02 09:18:21 +08:00
|
|
|
return;
|
|
|
|
}
|
2009-06-16 06:12:54 +08:00
|
|
|
// Null and aggregate-zero are all-zeros.
|
|
|
|
if (isa<ConstantPointerNull>(V) ||
|
|
|
|
isa<ConstantAggregateZero>(V)) {
|
2010-12-01 16:53:58 +08:00
|
|
|
KnownOne.clearAllBits();
|
2012-04-04 20:51:34 +08:00
|
|
|
KnownZero = APInt::getAllOnesValue(BitWidth);
|
2008-06-02 09:18:21 +08:00
|
|
|
return;
|
|
|
|
}
|
2009-06-16 06:12:54 +08:00
|
|
|
// Handle a constant vector by taking the intersection of the known bits of
|
2012-02-07 05:56:39 +08:00
|
|
|
// each element. There is no real need to handle ConstantVector here, because
|
|
|
|
// we don't handle undef in any particularly useful way.
|
2012-01-24 15:54:10 +08:00
|
|
|
if (ConstantDataSequential *CDS = dyn_cast<ConstantDataSequential>(V)) {
|
|
|
|
// We know that CDS must be a vector of integers. Take the intersection of
|
|
|
|
// each element.
|
|
|
|
KnownZero.setAllBits(); KnownOne.setAllBits();
|
|
|
|
APInt Elt(KnownZero.getBitWidth(), 0);
|
2012-01-25 09:27:20 +08:00
|
|
|
for (unsigned i = 0, e = CDS->getNumElements(); i != e; ++i) {
|
2012-01-24 15:54:10 +08:00
|
|
|
Elt = CDS->getElementAsInteger(i);
|
|
|
|
KnownZero &= ~Elt;
|
2012-12-23 03:15:35 +08:00
|
|
|
KnownOne &= Elt;
|
2012-01-24 15:54:10 +08:00
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
// The address of an aligned GlobalValue has trailing zeros.
|
2014-12-23 19:33:41 +08:00
|
|
|
if (auto *GO = dyn_cast<GlobalObject>(V)) {
|
|
|
|
unsigned Align = GO->getAlignment();
|
2012-03-07 10:27:53 +08:00
|
|
|
if (Align == 0 && TD) {
|
2014-12-23 19:33:41 +08:00
|
|
|
if (auto *GVar = dyn_cast<GlobalVariable>(GO)) {
|
2011-11-29 06:48:22 +08:00
|
|
|
Type *ObjectType = GVar->getType()->getElementType();
|
2012-03-07 10:27:53 +08:00
|
|
|
if (ObjectType->isSized()) {
|
|
|
|
// If the object is defined in the current Module, we'll be giving
|
|
|
|
// it the preferred alignment. Otherwise, we have to assume that it
|
|
|
|
// may only have the minimum ABI alignment.
|
|
|
|
if (!GVar->isDeclaration() && !GVar->isWeakForLinker())
|
|
|
|
Align = TD->getPreferredAlignment(GVar);
|
|
|
|
else
|
|
|
|
Align = TD->getABITypeAlignment(ObjectType);
|
|
|
|
}
|
2011-11-29 06:48:22 +08:00
|
|
|
}
|
2009-08-11 23:50:03 +08:00
|
|
|
}
|
2008-06-02 09:18:21 +08:00
|
|
|
if (Align > 0)
|
2012-04-04 20:51:34 +08:00
|
|
|
KnownZero = APInt::getLowBitsSet(BitWidth,
|
2013-05-25 06:23:49 +08:00
|
|
|
countTrailingZeros(Align));
|
2008-06-02 09:18:21 +08:00
|
|
|
else
|
2010-12-01 16:53:58 +08:00
|
|
|
KnownZero.clearAllBits();
|
|
|
|
KnownOne.clearAllBits();
|
2008-06-02 09:18:21 +08:00
|
|
|
return;
|
|
|
|
}
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2011-05-23 08:03:39 +08:00
|
|
|
if (Argument *A = dyn_cast<Argument>(V)) {
|
2014-07-23 00:58:55 +08:00
|
|
|
unsigned Align = A->getType()->isPointerTy() ? A->getParamAlignment() : 0;
|
2012-10-04 21:36:31 +08:00
|
|
|
|
2014-07-23 00:58:55 +08:00
|
|
|
if (!Align && TD && A->hasStructRetAttr()) {
|
2012-10-04 21:36:31 +08:00
|
|
|
// An sret parameter has at least the ABI alignment of the return type.
|
|
|
|
Type *EltTy = cast<PointerType>(A->getType())->getElementType();
|
|
|
|
if (EltTy->isSized())
|
|
|
|
Align = TD->getABITypeAlignment(EltTy);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Align)
|
2013-05-25 06:23:49 +08:00
|
|
|
KnownZero = APInt::getLowBitsSet(BitWidth, countTrailingZeros(Align));
|
2015-01-03 10:33:25 +08:00
|
|
|
else
|
|
|
|
KnownZero.clearAllBits();
|
|
|
|
KnownOne.clearAllBits();
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
|
|
|
|
// Don't give up yet... there might be an assumption that provides more
|
|
|
|
// information...
|
|
|
|
computeKnownBitsFromAssume(V, KnownZero, KnownOne, TD, Depth, Q);
|
2011-05-23 08:03:39 +08:00
|
|
|
return;
|
|
|
|
}
|
2008-06-02 09:18:21 +08:00
|
|
|
|
2011-05-23 08:03:39 +08:00
|
|
|
// Start out not knowing anything.
|
|
|
|
KnownZero.clearAllBits(); KnownOne.clearAllBits();
|
2008-06-02 09:18:21 +08:00
|
|
|
|
2014-12-23 19:33:41 +08:00
|
|
|
// Limit search depth.
|
|
|
|
// All recursive calls that increase depth must come after this.
|
2012-04-04 20:51:34 +08:00
|
|
|
if (Depth == MaxDepth)
|
2014-12-23 19:33:41 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
// A weak GlobalAlias is totally unknown. A non-weak GlobalAlias has
|
|
|
|
// the bits of its aliasee.
|
|
|
|
if (GlobalAlias *GA = dyn_cast<GlobalAlias>(V)) {
|
|
|
|
if (!GA->mayBeOverridden())
|
|
|
|
computeKnownBits(GA->getAliasee(), KnownZero, KnownOne, TD, Depth + 1, Q);
|
|
|
|
return;
|
|
|
|
}
|
2008-06-02 09:18:21 +08:00
|
|
|
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
// Check whether a nearby assume intrinsic can determine some known bits.
|
|
|
|
computeKnownBitsFromAssume(V, KnownZero, KnownOne, TD, Depth, Q);
|
|
|
|
|
2009-07-18 04:47:02 +08:00
|
|
|
Operator *I = dyn_cast<Operator>(V);
|
2008-06-02 09:18:21 +08:00
|
|
|
if (!I) return;
|
|
|
|
|
|
|
|
APInt KnownZero2(KnownZero), KnownOne2(KnownOne);
|
2009-07-18 04:47:02 +08:00
|
|
|
switch (I->getOpcode()) {
|
2008-06-02 09:18:21 +08:00
|
|
|
default: break;
|
2012-03-30 23:52:11 +08:00
|
|
|
case Instruction::Load:
|
2014-11-12 05:30:22 +08:00
|
|
|
if (MDNode *MD = cast<LoadInst>(I)->getMetadata(LLVMContext::MD_range))
|
2014-06-20 00:50:16 +08:00
|
|
|
computeKnownBitsFromRangeMetadata(*MD, KnownZero);
|
2014-05-15 20:12:55 +08:00
|
|
|
break;
|
2008-06-02 09:18:21 +08:00
|
|
|
case Instruction::And: {
|
|
|
|
// If either the LHS or the RHS are Zero, the result is zero.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(I->getOperand(1), KnownZero, KnownOne, TD, Depth+1, Q);
|
|
|
|
computeKnownBits(I->getOperand(0), KnownZero2, KnownOne2, TD, Depth+1, Q);
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
// Output known-1 bits are only known if set in both the LHS & RHS.
|
|
|
|
KnownOne &= KnownOne2;
|
|
|
|
// Output known-0 are known to be clear if zero in either the LHS | RHS.
|
|
|
|
KnownZero |= KnownZero2;
|
2014-05-15 20:12:55 +08:00
|
|
|
break;
|
2008-06-02 09:18:21 +08:00
|
|
|
}
|
|
|
|
case Instruction::Or: {
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(I->getOperand(1), KnownZero, KnownOne, TD, Depth+1, Q);
|
|
|
|
computeKnownBits(I->getOperand(0), KnownZero2, KnownOne2, TD, Depth+1, Q);
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
// Output known-0 bits are only known if clear in both the LHS & RHS.
|
|
|
|
KnownZero &= KnownZero2;
|
|
|
|
// Output known-1 are known to be set if set in either the LHS | RHS.
|
|
|
|
KnownOne |= KnownOne2;
|
2014-05-15 20:12:55 +08:00
|
|
|
break;
|
2008-06-02 09:18:21 +08:00
|
|
|
}
|
|
|
|
case Instruction::Xor: {
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(I->getOperand(1), KnownZero, KnownOne, TD, Depth+1, Q);
|
|
|
|
computeKnownBits(I->getOperand(0), KnownZero2, KnownOne2, TD, Depth+1, Q);
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
// Output known-0 bits are known if clear or set in both the LHS & RHS.
|
|
|
|
APInt KnownZeroOut = (KnownZero & KnownZero2) | (KnownOne & KnownOne2);
|
|
|
|
// Output known-1 are known to be set if set in only one of the LHS, RHS.
|
|
|
|
KnownOne = (KnownZero & KnownOne2) | (KnownOne & KnownZero2);
|
|
|
|
KnownZero = KnownZeroOut;
|
2014-05-15 20:12:55 +08:00
|
|
|
break;
|
2008-06-02 09:18:21 +08:00
|
|
|
}
|
|
|
|
case Instruction::Mul: {
|
2012-03-19 07:28:48 +08:00
|
|
|
bool NSW = cast<OverflowingBinaryOperator>(I)->hasNoSignedWrap();
|
2014-05-15 05:14:37 +08:00
|
|
|
computeKnownBitsMul(I->getOperand(0), I->getOperand(1), NSW,
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
KnownZero, KnownOne, KnownZero2, KnownOne2, TD,
|
|
|
|
Depth, Q);
|
2012-03-19 07:28:48 +08:00
|
|
|
break;
|
2008-06-02 09:18:21 +08:00
|
|
|
}
|
|
|
|
case Instruction::UDiv: {
|
|
|
|
// For the purposes of computing leading zeros we can conservatively
|
|
|
|
// treat a udiv as a logical right shift by the power of 2 known to
|
|
|
|
// be less than the denominator.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(I->getOperand(0), KnownZero2, KnownOne2, TD, Depth+1, Q);
|
2008-06-02 09:18:21 +08:00
|
|
|
unsigned LeadZ = KnownZero2.countLeadingOnes();
|
|
|
|
|
2010-12-01 16:53:58 +08:00
|
|
|
KnownOne2.clearAllBits();
|
|
|
|
KnownZero2.clearAllBits();
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(I->getOperand(1), KnownZero2, KnownOne2, TD, Depth+1, Q);
|
2008-06-02 09:18:21 +08:00
|
|
|
unsigned RHSUnknownLeadingOnes = KnownOne2.countLeadingZeros();
|
|
|
|
if (RHSUnknownLeadingOnes != BitWidth)
|
|
|
|
LeadZ = std::min(BitWidth,
|
|
|
|
LeadZ + BitWidth - RHSUnknownLeadingOnes - 1);
|
|
|
|
|
2012-04-04 20:51:34 +08:00
|
|
|
KnownZero = APInt::getHighBitsSet(BitWidth, LeadZ);
|
2014-05-15 20:12:55 +08:00
|
|
|
break;
|
2008-06-02 09:18:21 +08:00
|
|
|
}
|
|
|
|
case Instruction::Select:
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(I->getOperand(2), KnownZero, KnownOne, TD, Depth+1, Q);
|
|
|
|
computeKnownBits(I->getOperand(1), KnownZero2, KnownOne2, TD, Depth+1, Q);
|
2008-06-02 09:18:21 +08:00
|
|
|
|
|
|
|
// Only known if known in both the LHS and RHS.
|
|
|
|
KnownOne &= KnownOne2;
|
|
|
|
KnownZero &= KnownZero2;
|
2014-05-15 20:12:55 +08:00
|
|
|
break;
|
2008-06-02 09:18:21 +08:00
|
|
|
case Instruction::FPTrunc:
|
|
|
|
case Instruction::FPExt:
|
|
|
|
case Instruction::FPToUI:
|
|
|
|
case Instruction::FPToSI:
|
|
|
|
case Instruction::SIToFP:
|
|
|
|
case Instruction::UIToFP:
|
2014-05-15 20:12:55 +08:00
|
|
|
break; // Can't work with floating point.
|
2008-06-02 09:18:21 +08:00
|
|
|
case Instruction::PtrToInt:
|
|
|
|
case Instruction::IntToPtr:
|
2014-07-15 09:55:03 +08:00
|
|
|
case Instruction::AddrSpaceCast: // Pointers could be different sizes.
|
2008-06-02 09:18:21 +08:00
|
|
|
// We can't handle these if we don't know the pointer size.
|
2014-05-15 20:12:55 +08:00
|
|
|
if (!TD) break;
|
2008-06-02 09:18:21 +08:00
|
|
|
// FALL THROUGH and handle them the same as zext/trunc.
|
|
|
|
case Instruction::ZExt:
|
|
|
|
case Instruction::Trunc: {
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *SrcTy = I->getOperand(0)->getType();
|
2012-10-27 01:17:05 +08:00
|
|
|
|
2009-09-08 08:13:52 +08:00
|
|
|
unsigned SrcBitWidth;
|
2008-06-02 09:18:21 +08:00
|
|
|
// Note that we handle pointer operands here because of inttoptr/ptrtoint
|
|
|
|
// which fall through here.
|
2012-12-20 04:47:04 +08:00
|
|
|
if(TD) {
|
|
|
|
SrcBitWidth = TD->getTypeSizeInBits(SrcTy->getScalarType());
|
|
|
|
} else {
|
|
|
|
SrcBitWidth = SrcTy->getScalarSizeInBits();
|
2014-05-15 20:12:55 +08:00
|
|
|
if (!SrcBitWidth) break;
|
2012-12-20 04:47:04 +08:00
|
|
|
}
|
2012-10-27 01:17:05 +08:00
|
|
|
|
|
|
|
assert(SrcBitWidth && "SrcBitWidth can't be zero");
|
2010-12-07 16:25:19 +08:00
|
|
|
KnownZero = KnownZero.zextOrTrunc(SrcBitWidth);
|
|
|
|
KnownOne = KnownOne.zextOrTrunc(SrcBitWidth);
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(I->getOperand(0), KnownZero, KnownOne, TD, Depth+1, Q);
|
2010-12-07 16:25:19 +08:00
|
|
|
KnownZero = KnownZero.zextOrTrunc(BitWidth);
|
|
|
|
KnownOne = KnownOne.zextOrTrunc(BitWidth);
|
2008-06-02 09:18:21 +08:00
|
|
|
// Any top bits are known to be zero.
|
|
|
|
if (BitWidth > SrcBitWidth)
|
|
|
|
KnownZero |= APInt::getHighBitsSet(BitWidth, BitWidth - SrcBitWidth);
|
2014-05-15 20:12:55 +08:00
|
|
|
break;
|
2008-06-02 09:18:21 +08:00
|
|
|
}
|
|
|
|
case Instruction::BitCast: {
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *SrcTy = I->getOperand(0)->getType();
|
2010-02-16 19:11:14 +08:00
|
|
|
if ((SrcTy->isIntegerTy() || SrcTy->isPointerTy()) &&
|
2009-07-03 00:04:08 +08:00
|
|
|
// TODO: For now, not handling conversions like:
|
|
|
|
// (bitcast i64 %x to <2 x i32>)
|
2010-02-16 19:11:14 +08:00
|
|
|
!I->getType()->isVectorTy()) {
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(I->getOperand(0), KnownZero, KnownOne, TD, Depth+1, Q);
|
2014-05-15 20:12:55 +08:00
|
|
|
break;
|
2008-06-02 09:18:21 +08:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case Instruction::SExt: {
|
|
|
|
// Compute the bits in the result that are not present in the input.
|
2009-09-08 08:13:52 +08:00
|
|
|
unsigned SrcBitWidth = I->getOperand(0)->getType()->getScalarSizeInBits();
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2010-12-07 16:25:19 +08:00
|
|
|
KnownZero = KnownZero.trunc(SrcBitWidth);
|
|
|
|
KnownOne = KnownOne.trunc(SrcBitWidth);
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(I->getOperand(0), KnownZero, KnownOne, TD, Depth+1, Q);
|
2010-12-07 16:25:19 +08:00
|
|
|
KnownZero = KnownZero.zext(BitWidth);
|
|
|
|
KnownOne = KnownOne.zext(BitWidth);
|
2008-06-02 09:18:21 +08:00
|
|
|
|
|
|
|
// If the sign bit of the input is known set or clear, then we know the
|
|
|
|
// top bits of the result.
|
|
|
|
if (KnownZero[SrcBitWidth-1]) // Input sign bit known zero
|
|
|
|
KnownZero |= APInt::getHighBitsSet(BitWidth, BitWidth - SrcBitWidth);
|
|
|
|
else if (KnownOne[SrcBitWidth-1]) // Input sign bit known set
|
|
|
|
KnownOne |= APInt::getHighBitsSet(BitWidth, BitWidth - SrcBitWidth);
|
2014-05-15 20:12:55 +08:00
|
|
|
break;
|
2008-06-02 09:18:21 +08:00
|
|
|
}
|
|
|
|
case Instruction::Shl:
|
2012-09-27 18:14:43 +08:00
|
|
|
// (shl X, C1) & C2 == 0 iff (X & C2 >>u C1) == 0
|
2008-06-02 09:18:21 +08:00
|
|
|
if (ConstantInt *SA = dyn_cast<ConstantInt>(I->getOperand(1))) {
|
|
|
|
uint64_t ShiftAmt = SA->getLimitedValue(BitWidth);
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(I->getOperand(0), KnownZero, KnownOne, TD, Depth+1, Q);
|
2008-06-02 09:18:21 +08:00
|
|
|
KnownZero <<= ShiftAmt;
|
|
|
|
KnownOne <<= ShiftAmt;
|
|
|
|
KnownZero |= APInt::getLowBitsSet(BitWidth, ShiftAmt); // low bits known 0
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case Instruction::LShr:
|
2012-09-27 18:14:43 +08:00
|
|
|
// (ushr X, C1) & C2 == 0 iff (-1 >> C1) & C2 == 0
|
2008-06-02 09:18:21 +08:00
|
|
|
if (ConstantInt *SA = dyn_cast<ConstantInt>(I->getOperand(1))) {
|
|
|
|
// Compute the new bits that are at the top now.
|
|
|
|
uint64_t ShiftAmt = SA->getLimitedValue(BitWidth);
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
// Unsigned shift right.
|
2014-11-06 02:00:07 +08:00
|
|
|
computeKnownBits(I->getOperand(0), KnownZero, KnownOne, TD, Depth+1, Q);
|
2008-06-02 09:18:21 +08:00
|
|
|
KnownZero = APIntOps::lshr(KnownZero, ShiftAmt);
|
|
|
|
KnownOne = APIntOps::lshr(KnownOne, ShiftAmt);
|
|
|
|
// high bits known zero.
|
|
|
|
KnownZero |= APInt::getHighBitsSet(BitWidth, ShiftAmt);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case Instruction::AShr:
|
2012-09-27 18:14:43 +08:00
|
|
|
// (ashr X, C1) & C2 == 0 iff (-1 >> C1) & C2 == 0
|
2008-06-02 09:18:21 +08:00
|
|
|
if (ConstantInt *SA = dyn_cast<ConstantInt>(I->getOperand(1))) {
|
|
|
|
// Compute the new bits that are at the top now.
|
2011-01-05 02:19:15 +08:00
|
|
|
uint64_t ShiftAmt = SA->getLimitedValue(BitWidth-1);
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
// Signed shift right.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(I->getOperand(0), KnownZero, KnownOne, TD, Depth+1, Q);
|
2008-06-02 09:18:21 +08:00
|
|
|
KnownZero = APIntOps::lshr(KnownZero, ShiftAmt);
|
|
|
|
KnownOne = APIntOps::lshr(KnownOne, ShiftAmt);
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
APInt HighBits(APInt::getHighBitsSet(BitWidth, ShiftAmt));
|
|
|
|
if (KnownZero[BitWidth-ShiftAmt-1]) // New bits are known zero.
|
|
|
|
KnownZero |= HighBits;
|
|
|
|
else if (KnownOne[BitWidth-ShiftAmt-1]) // New bits are known one.
|
|
|
|
KnownOne |= HighBits;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case Instruction::Sub: {
|
2012-03-09 17:23:50 +08:00
|
|
|
bool NSW = cast<OverflowingBinaryOperator>(I)->hasNoSignedWrap();
|
2014-05-15 05:14:37 +08:00
|
|
|
computeKnownBitsAddSub(false, I->getOperand(0), I->getOperand(1), NSW,
|
2012-04-04 20:51:34 +08:00
|
|
|
KnownZero, KnownOne, KnownZero2, KnownOne2, TD,
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
Depth, Q);
|
2012-03-09 17:23:50 +08:00
|
|
|
break;
|
2008-06-02 09:18:21 +08:00
|
|
|
}
|
|
|
|
case Instruction::Add: {
|
2012-03-09 17:23:50 +08:00
|
|
|
bool NSW = cast<OverflowingBinaryOperator>(I)->hasNoSignedWrap();
|
2014-05-15 05:14:37 +08:00
|
|
|
computeKnownBitsAddSub(true, I->getOperand(0), I->getOperand(1), NSW,
|
2012-04-04 20:51:34 +08:00
|
|
|
KnownZero, KnownOne, KnownZero2, KnownOne2, TD,
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
Depth, Q);
|
2012-03-09 17:23:50 +08:00
|
|
|
break;
|
2008-06-02 09:18:21 +08:00
|
|
|
}
|
|
|
|
case Instruction::SRem:
|
|
|
|
if (ConstantInt *Rem = dyn_cast<ConstantInt>(I->getOperand(1))) {
|
2010-01-29 14:18:37 +08:00
|
|
|
APInt RA = Rem->getValue().abs();
|
|
|
|
if (RA.isPowerOf2()) {
|
|
|
|
APInt LowBits = RA - 1;
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(I->getOperand(0), KnownZero2, KnownOne2, TD,
|
|
|
|
Depth+1, Q);
|
2008-06-02 09:18:21 +08:00
|
|
|
|
2010-01-29 14:18:37 +08:00
|
|
|
// The low bits of the first operand are unchanged by the srem.
|
|
|
|
KnownZero = KnownZero2 & LowBits;
|
|
|
|
KnownOne = KnownOne2 & LowBits;
|
|
|
|
|
|
|
|
// If the first operand is non-negative or has all low bits zero, then
|
|
|
|
// the upper bits are all zero.
|
2008-06-02 09:18:21 +08:00
|
|
|
if (KnownZero2[BitWidth-1] || ((KnownZero2 & LowBits) == LowBits))
|
2010-01-29 14:18:37 +08:00
|
|
|
KnownZero |= ~LowBits;
|
2008-06-02 09:18:21 +08:00
|
|
|
|
2010-01-29 14:18:37 +08:00
|
|
|
// If the first operand is negative and not all low bits are zero, then
|
|
|
|
// the upper bits are all one.
|
|
|
|
if (KnownOne2[BitWidth-1] && ((KnownOne2 & LowBits) != 0))
|
|
|
|
KnownOne |= ~LowBits;
|
|
|
|
|
2012-12-23 03:15:35 +08:00
|
|
|
assert((KnownZero & KnownOne) == 0 && "Bits known to be one AND zero?");
|
2008-06-02 09:18:21 +08:00
|
|
|
}
|
|
|
|
}
|
2011-03-07 09:50:10 +08:00
|
|
|
|
|
|
|
// The sign bit is the LHS's sign bit, except when the result of the
|
|
|
|
// remainder is zero.
|
2012-04-04 20:51:34 +08:00
|
|
|
if (KnownZero.isNonNegative()) {
|
2011-03-07 09:50:10 +08:00
|
|
|
APInt LHSKnownZero(BitWidth, 0), LHSKnownOne(BitWidth, 0);
|
2014-05-15 05:14:37 +08:00
|
|
|
computeKnownBits(I->getOperand(0), LHSKnownZero, LHSKnownOne, TD,
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
Depth+1, Q);
|
2011-03-07 09:50:10 +08:00
|
|
|
// If it's known zero, our sign bit is also zero.
|
|
|
|
if (LHSKnownZero.isNegative())
|
2012-04-30 19:56:58 +08:00
|
|
|
KnownZero.setBit(BitWidth - 1);
|
2011-03-07 09:50:10 +08:00
|
|
|
}
|
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
break;
|
|
|
|
case Instruction::URem: {
|
|
|
|
if (ConstantInt *Rem = dyn_cast<ConstantInt>(I->getOperand(1))) {
|
|
|
|
APInt RA = Rem->getValue();
|
|
|
|
if (RA.isPowerOf2()) {
|
|
|
|
APInt LowBits = (RA - 1);
|
2014-05-15 05:14:37 +08:00
|
|
|
computeKnownBits(I->getOperand(0), KnownZero, KnownOne, TD,
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
Depth+1, Q);
|
2012-04-04 20:51:34 +08:00
|
|
|
KnownZero |= ~LowBits;
|
|
|
|
KnownOne &= LowBits;
|
2008-06-02 09:18:21 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Since the result is less than or equal to either operand, any leading
|
|
|
|
// zero bits in either operand must also exist in the result.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(I->getOperand(0), KnownZero, KnownOne, TD, Depth+1, Q);
|
|
|
|
computeKnownBits(I->getOperand(1), KnownZero2, KnownOne2, TD, Depth+1, Q);
|
2008-06-02 09:18:21 +08:00
|
|
|
|
2009-01-21 02:22:57 +08:00
|
|
|
unsigned Leaders = std::max(KnownZero.countLeadingOnes(),
|
2008-06-02 09:18:21 +08:00
|
|
|
KnownZero2.countLeadingOnes());
|
2010-12-01 16:53:58 +08:00
|
|
|
KnownOne.clearAllBits();
|
2012-04-04 20:51:34 +08:00
|
|
|
KnownZero = APInt::getHighBitsSet(BitWidth, Leaders);
|
2008-06-02 09:18:21 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2009-10-17 09:18:07 +08:00
|
|
|
case Instruction::Alloca: {
|
2009-10-24 05:09:37 +08:00
|
|
|
AllocaInst *AI = cast<AllocaInst>(V);
|
2008-06-02 09:18:21 +08:00
|
|
|
unsigned Align = AI->getAlignment();
|
2009-10-17 09:18:07 +08:00
|
|
|
if (Align == 0 && TD)
|
|
|
|
Align = TD->getABITypeAlignment(AI->getType()->getElementType());
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
if (Align > 0)
|
2013-05-25 06:23:49 +08:00
|
|
|
KnownZero = APInt::getLowBitsSet(BitWidth, countTrailingZeros(Align));
|
2008-06-02 09:18:21 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case Instruction::GetElementPtr: {
|
|
|
|
// Analyze all of the subscripts of this getelementptr instruction
|
|
|
|
// to determine if we can prove known low zero bits.
|
|
|
|
APInt LocalKnownZero(BitWidth, 0), LocalKnownOne(BitWidth, 0);
|
2014-05-15 05:14:37 +08:00
|
|
|
computeKnownBits(I->getOperand(0), LocalKnownZero, LocalKnownOne, TD,
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
Depth+1, Q);
|
2008-06-02 09:18:21 +08:00
|
|
|
unsigned TrailZ = LocalKnownZero.countTrailingOnes();
|
|
|
|
|
|
|
|
gep_type_iterator GTI = gep_type_begin(I);
|
|
|
|
for (unsigned i = 1, e = I->getNumOperands(); i != e; ++i, ++GTI) {
|
|
|
|
Value *Index = I->getOperand(i);
|
2011-07-18 12:54:35 +08:00
|
|
|
if (StructType *STy = dyn_cast<StructType>(*GTI)) {
|
2008-06-02 09:18:21 +08:00
|
|
|
// Handle struct member offset arithmetic.
|
2014-05-15 20:12:55 +08:00
|
|
|
if (!TD) {
|
|
|
|
TrailZ = 0;
|
|
|
|
break;
|
|
|
|
}
|
2013-08-20 05:43:16 +08:00
|
|
|
|
|
|
|
// Handle case when index is vector zeroinitializer
|
|
|
|
Constant *CIndex = cast<Constant>(Index);
|
|
|
|
if (CIndex->isZeroValue())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (CIndex->getType()->isVectorTy())
|
|
|
|
Index = CIndex->getSplatValue();
|
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
unsigned Idx = cast<ConstantInt>(Index)->getZExtValue();
|
2013-08-20 05:43:16 +08:00
|
|
|
const StructLayout *SL = TD->getStructLayout(STy);
|
2008-06-02 09:18:21 +08:00
|
|
|
uint64_t Offset = SL->getElementOffset(Idx);
|
2013-05-25 06:23:49 +08:00
|
|
|
TrailZ = std::min<unsigned>(TrailZ,
|
|
|
|
countTrailingZeros(Offset));
|
2008-06-02 09:18:21 +08:00
|
|
|
} else {
|
|
|
|
// Handle array index arithmetic.
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *IndexedTy = GTI.getIndexedType();
|
2014-05-15 20:12:55 +08:00
|
|
|
if (!IndexedTy->isSized()) {
|
|
|
|
TrailZ = 0;
|
|
|
|
break;
|
|
|
|
}
|
2009-06-16 06:12:54 +08:00
|
|
|
unsigned GEPOpiBits = Index->getType()->getScalarSizeInBits();
|
2009-05-09 15:06:46 +08:00
|
|
|
uint64_t TypeSize = TD ? TD->getTypeAllocSize(IndexedTy) : 1;
|
2008-06-02 09:18:21 +08:00
|
|
|
LocalKnownZero = LocalKnownOne = APInt(GEPOpiBits, 0);
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(Index, LocalKnownZero, LocalKnownOne, TD, Depth+1, Q);
|
2008-06-02 09:18:21 +08:00
|
|
|
TrailZ = std::min(TrailZ,
|
2013-05-25 06:23:49 +08:00
|
|
|
unsigned(countTrailingZeros(TypeSize) +
|
2009-01-21 02:22:57 +08:00
|
|
|
LocalKnownZero.countTrailingOnes()));
|
2008-06-02 09:18:21 +08:00
|
|
|
}
|
|
|
|
}
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2012-04-04 20:51:34 +08:00
|
|
|
KnownZero = APInt::getLowBitsSet(BitWidth, TrailZ);
|
2008-06-02 09:18:21 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case Instruction::PHI: {
|
|
|
|
PHINode *P = cast<PHINode>(I);
|
|
|
|
// Handle the case of a simple two-predecessor recurrence PHI.
|
|
|
|
// There's a lot more that could theoretically be done here, but
|
|
|
|
// this is sufficient to catch some interesting cases.
|
|
|
|
if (P->getNumIncomingValues() == 2) {
|
|
|
|
for (unsigned i = 0; i != 2; ++i) {
|
|
|
|
Value *L = P->getIncomingValue(i);
|
|
|
|
Value *R = P->getIncomingValue(!i);
|
2009-07-18 04:47:02 +08:00
|
|
|
Operator *LU = dyn_cast<Operator>(L);
|
2008-06-02 09:18:21 +08:00
|
|
|
if (!LU)
|
|
|
|
continue;
|
2009-07-18 04:47:02 +08:00
|
|
|
unsigned Opcode = LU->getOpcode();
|
2008-06-02 09:18:21 +08:00
|
|
|
// Check for operations that have the property that if
|
|
|
|
// both their operands have low zero bits, the result
|
|
|
|
// will have low zero bits.
|
|
|
|
if (Opcode == Instruction::Add ||
|
|
|
|
Opcode == Instruction::Sub ||
|
|
|
|
Opcode == Instruction::And ||
|
|
|
|
Opcode == Instruction::Or ||
|
|
|
|
Opcode == Instruction::Mul) {
|
|
|
|
Value *LL = LU->getOperand(0);
|
|
|
|
Value *LR = LU->getOperand(1);
|
|
|
|
// Find a recurrence.
|
|
|
|
if (LL == I)
|
|
|
|
L = LR;
|
|
|
|
else if (LR == I)
|
|
|
|
L = LL;
|
|
|
|
else
|
|
|
|
break;
|
|
|
|
// Ok, we have a PHI of the form L op= R. Check for low
|
|
|
|
// zero bits.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(R, KnownZero2, KnownOne2, TD, Depth+1, Q);
|
2008-10-28 07:24:03 +08:00
|
|
|
|
|
|
|
// We need to take the minimum number of known bits
|
|
|
|
APInt KnownZero3(KnownZero), KnownOne3(KnownOne);
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(L, KnownZero3, KnownOne3, TD, Depth+1, Q);
|
2008-10-28 07:24:03 +08:00
|
|
|
|
2012-04-04 20:51:34 +08:00
|
|
|
KnownZero = APInt::getLowBitsSet(BitWidth,
|
2008-10-28 07:24:03 +08:00
|
|
|
std::min(KnownZero2.countTrailingOnes(),
|
|
|
|
KnownZero3.countTrailingOnes()));
|
2008-06-02 09:18:21 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2009-05-21 10:28:33 +08:00
|
|
|
|
2011-02-11 07:54:10 +08:00
|
|
|
// Unreachable blocks may have zero-operand PHI nodes.
|
|
|
|
if (P->getNumIncomingValues() == 0)
|
2014-05-15 20:12:55 +08:00
|
|
|
break;
|
2011-02-11 07:54:10 +08:00
|
|
|
|
2009-05-21 10:28:33 +08:00
|
|
|
// Otherwise take the unions of the known bit sets of the operands,
|
|
|
|
// taking conservative care to avoid excessive recursion.
|
|
|
|
if (Depth < MaxDepth - 1 && !KnownZero && !KnownOne) {
|
2011-03-08 20:39:03 +08:00
|
|
|
// Skip if every incoming value references to ourself.
|
2012-07-04 05:15:40 +08:00
|
|
|
if (dyn_cast_or_null<UndefValue>(P->hasConstantValue()))
|
2011-03-08 20:39:03 +08:00
|
|
|
break;
|
|
|
|
|
2012-04-04 20:51:34 +08:00
|
|
|
KnownZero = APInt::getAllOnesValue(BitWidth);
|
|
|
|
KnownOne = APInt::getAllOnesValue(BitWidth);
|
2009-05-21 10:28:33 +08:00
|
|
|
for (unsigned i = 0, e = P->getNumIncomingValues(); i != e; ++i) {
|
|
|
|
// Skip direct self references.
|
|
|
|
if (P->getIncomingValue(i) == P) continue;
|
|
|
|
|
|
|
|
KnownZero2 = APInt(BitWidth, 0);
|
|
|
|
KnownOne2 = APInt(BitWidth, 0);
|
|
|
|
// Recurse, but cap the recursion to one level, because we don't
|
|
|
|
// want to waste time spinning around in loops.
|
2014-05-15 05:14:37 +08:00
|
|
|
computeKnownBits(P->getIncomingValue(i), KnownZero2, KnownOne2, TD,
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
MaxDepth-1, Q);
|
2009-05-21 10:28:33 +08:00
|
|
|
KnownZero &= KnownZero2;
|
|
|
|
KnownOne &= KnownOne2;
|
|
|
|
// If all bits have been ruled out, there's no need to check
|
|
|
|
// more operands.
|
|
|
|
if (!KnownZero && !KnownOne)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2008-06-02 09:18:21 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case Instruction::Call:
|
2014-06-20 00:50:16 +08:00
|
|
|
case Instruction::Invoke:
|
2014-11-12 05:30:22 +08:00
|
|
|
if (MDNode *MD = cast<Instruction>(I)->getMetadata(LLVMContext::MD_range))
|
2014-06-20 00:50:16 +08:00
|
|
|
computeKnownBitsFromRangeMetadata(*MD, KnownZero);
|
|
|
|
// If a range metadata is attached to this IntrinsicInst, intersect the
|
|
|
|
// explicit range specified by the metadata and the implicit range of
|
|
|
|
// the intrinsic.
|
2008-06-02 09:18:21 +08:00
|
|
|
if (IntrinsicInst *II = dyn_cast<IntrinsicInst>(I)) {
|
|
|
|
switch (II->getIntrinsicID()) {
|
|
|
|
default: break;
|
|
|
|
case Intrinsic::ctlz:
|
|
|
|
case Intrinsic::cttz: {
|
2011-12-25 01:31:46 +08:00
|
|
|
unsigned LowBits = Log2_32(BitWidth)+1;
|
|
|
|
// If this call is undefined for 0, the result will be less than 2^n.
|
|
|
|
if (II->getArgOperand(1) == ConstantInt::getTrue(II->getContext()))
|
|
|
|
LowBits -= 1;
|
2014-06-20 00:50:16 +08:00
|
|
|
KnownZero |= APInt::getHighBitsSet(BitWidth, BitWidth - LowBits);
|
2011-12-25 01:31:46 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case Intrinsic::ctpop: {
|
2008-06-02 09:18:21 +08:00
|
|
|
unsigned LowBits = Log2_32(BitWidth)+1;
|
2014-06-20 00:50:16 +08:00
|
|
|
KnownZero |= APInt::getHighBitsSet(BitWidth, BitWidth - LowBits);
|
2008-06-02 09:18:21 +08:00
|
|
|
break;
|
|
|
|
}
|
2011-05-27 07:13:19 +08:00
|
|
|
case Intrinsic::x86_sse42_crc32_64_64:
|
2014-06-20 00:50:16 +08:00
|
|
|
KnownZero |= APInt::getHighBitsSet(64, 32);
|
2011-05-23 02:25:30 +08:00
|
|
|
break;
|
2008-06-02 09:18:21 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
2012-03-09 17:23:50 +08:00
|
|
|
case Instruction::ExtractValue:
|
|
|
|
if (IntrinsicInst *II = dyn_cast<IntrinsicInst>(I->getOperand(0))) {
|
|
|
|
ExtractValueInst *EVI = cast<ExtractValueInst>(I);
|
|
|
|
if (EVI->getNumIndices() != 1) break;
|
|
|
|
if (EVI->getIndices()[0] == 0) {
|
|
|
|
switch (II->getIntrinsicID()) {
|
|
|
|
default: break;
|
|
|
|
case Intrinsic::uadd_with_overflow:
|
|
|
|
case Intrinsic::sadd_with_overflow:
|
2014-05-15 05:14:37 +08:00
|
|
|
computeKnownBitsAddSub(true, II->getArgOperand(0),
|
|
|
|
II->getArgOperand(1), false, KnownZero,
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
KnownOne, KnownZero2, KnownOne2, TD, Depth, Q);
|
2012-03-09 17:23:50 +08:00
|
|
|
break;
|
|
|
|
case Intrinsic::usub_with_overflow:
|
|
|
|
case Intrinsic::ssub_with_overflow:
|
2014-05-15 05:14:37 +08:00
|
|
|
computeKnownBitsAddSub(false, II->getArgOperand(0),
|
|
|
|
II->getArgOperand(1), false, KnownZero,
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
KnownOne, KnownZero2, KnownOne2, TD, Depth, Q);
|
2012-03-09 17:23:50 +08:00
|
|
|
break;
|
2012-03-19 07:28:48 +08:00
|
|
|
case Intrinsic::umul_with_overflow:
|
|
|
|
case Intrinsic::smul_with_overflow:
|
2014-05-15 05:14:37 +08:00
|
|
|
computeKnownBitsMul(II->getArgOperand(0), II->getArgOperand(1),
|
|
|
|
false, KnownZero, KnownOne,
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
KnownZero2, KnownOne2, TD, Depth, Q);
|
2012-03-19 07:28:48 +08:00
|
|
|
break;
|
2012-03-09 17:23:50 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2008-06-02 09:18:21 +08:00
|
|
|
}
|
2014-05-15 20:12:55 +08:00
|
|
|
|
|
|
|
assert((KnownZero & KnownOne) == 0 && "Bits known to be one AND zero?");
|
2008-06-02 09:18:21 +08:00
|
|
|
}
|
|
|
|
|
2014-11-05 00:27:42 +08:00
|
|
|
/// Determine whether the sign bit is known to be zero or one.
|
|
|
|
/// Convenience wrapper around computeKnownBits.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
void ComputeSignBit(Value *V, bool &KnownZero, bool &KnownOne,
|
|
|
|
const DataLayout *TD, unsigned Depth,
|
|
|
|
const Query &Q) {
|
2011-01-25 17:38:29 +08:00
|
|
|
unsigned BitWidth = getBitWidth(V->getType(), TD);
|
|
|
|
if (!BitWidth) {
|
|
|
|
KnownZero = false;
|
|
|
|
KnownOne = false;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
APInt ZeroBits(BitWidth, 0);
|
|
|
|
APInt OneBits(BitWidth, 0);
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(V, ZeroBits, OneBits, TD, Depth, Q);
|
2011-01-25 17:38:29 +08:00
|
|
|
KnownOne = OneBits[BitWidth - 1];
|
|
|
|
KnownZero = ZeroBits[BitWidth - 1];
|
|
|
|
}
|
|
|
|
|
2014-11-05 00:27:42 +08:00
|
|
|
/// Return true if the given value is known to have exactly one
|
2011-01-25 17:38:29 +08:00
|
|
|
/// bit set when defined. For vectors return true if every element is known to
|
2014-11-05 00:27:42 +08:00
|
|
|
/// be a power of two when defined. Supports values with integer or pointer
|
2011-01-25 17:38:29 +08:00
|
|
|
/// types and vectors of integers.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
bool isKnownToBeAPowerOfTwo(Value *V, bool OrZero, unsigned Depth,
|
|
|
|
const Query &Q) {
|
2011-10-27 04:55:21 +08:00
|
|
|
if (Constant *C = dyn_cast<Constant>(V)) {
|
|
|
|
if (C->isNullValue())
|
|
|
|
return OrZero;
|
|
|
|
if (ConstantInt *CI = dyn_cast<ConstantInt>(C))
|
|
|
|
return CI->getValue().isPowerOf2();
|
|
|
|
// TODO: Handle vector constants.
|
|
|
|
}
|
2011-01-25 17:38:29 +08:00
|
|
|
|
|
|
|
// 1 << X is clearly a power of two if the one is not shifted off the end. If
|
|
|
|
// it is shifted off the end then the result is undefined.
|
|
|
|
if (match(V, m_Shl(m_One(), m_Value())))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// (signbit) >>l X is clearly a power of two if the one is not shifted off the
|
|
|
|
// bottom. If it is shifted off the bottom then the result is undefined.
|
2011-02-01 16:50:33 +08:00
|
|
|
if (match(V, m_LShr(m_SignBit(), m_Value())))
|
2011-01-25 17:38:29 +08:00
|
|
|
return true;
|
|
|
|
|
|
|
|
// The remaining tests are all recursive, so bail out if we hit the limit.
|
|
|
|
if (Depth++ == MaxDepth)
|
|
|
|
return false;
|
|
|
|
|
2014-04-15 12:59:12 +08:00
|
|
|
Value *X = nullptr, *Y = nullptr;
|
2011-10-29 02:30:05 +08:00
|
|
|
// A shift of a power of two is a power of two or zero.
|
|
|
|
if (OrZero && (match(V, m_Shl(m_Value(X), m_Value())) ||
|
|
|
|
match(V, m_Shr(m_Value(X), m_Value()))))
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
return isKnownToBeAPowerOfTwo(X, /*OrZero*/true, Depth, Q);
|
2011-10-29 02:30:05 +08:00
|
|
|
|
2011-01-25 17:38:29 +08:00
|
|
|
if (ZExtInst *ZI = dyn_cast<ZExtInst>(V))
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
return isKnownToBeAPowerOfTwo(ZI->getOperand(0), OrZero, Depth, Q);
|
2011-01-25 17:38:29 +08:00
|
|
|
|
|
|
|
if (SelectInst *SI = dyn_cast<SelectInst>(V))
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
return
|
|
|
|
isKnownToBeAPowerOfTwo(SI->getTrueValue(), OrZero, Depth, Q) &&
|
|
|
|
isKnownToBeAPowerOfTwo(SI->getFalseValue(), OrZero, Depth, Q);
|
2011-10-27 04:55:21 +08:00
|
|
|
|
|
|
|
if (OrZero && match(V, m_And(m_Value(X), m_Value(Y)))) {
|
|
|
|
// A power of two and'd with anything is a power of two or zero.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
if (isKnownToBeAPowerOfTwo(X, /*OrZero*/true, Depth, Q) ||
|
|
|
|
isKnownToBeAPowerOfTwo(Y, /*OrZero*/true, Depth, Q))
|
2011-10-27 04:55:21 +08:00
|
|
|
return true;
|
|
|
|
// X & (-X) is always a power of two or zero.
|
|
|
|
if (match(X, m_Neg(m_Specific(Y))) || match(Y, m_Neg(m_Specific(X))))
|
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
2011-01-25 17:38:29 +08:00
|
|
|
|
2013-07-31 05:01:36 +08:00
|
|
|
// Adding a power-of-two or zero to the same power-of-two or zero yields
|
|
|
|
// either the original power-of-two, a larger power-of-two or zero.
|
|
|
|
if (match(V, m_Add(m_Value(X), m_Value(Y)))) {
|
|
|
|
OverflowingBinaryOperator *VOBO = cast<OverflowingBinaryOperator>(V);
|
|
|
|
if (OrZero || VOBO->hasNoUnsignedWrap() || VOBO->hasNoSignedWrap()) {
|
|
|
|
if (match(X, m_And(m_Specific(Y), m_Value())) ||
|
|
|
|
match(X, m_And(m_Value(), m_Specific(Y))))
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
if (isKnownToBeAPowerOfTwo(Y, OrZero, Depth, Q))
|
2013-07-31 05:01:36 +08:00
|
|
|
return true;
|
|
|
|
if (match(Y, m_And(m_Specific(X), m_Value())) ||
|
|
|
|
match(Y, m_And(m_Value(), m_Specific(X))))
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
if (isKnownToBeAPowerOfTwo(X, OrZero, Depth, Q))
|
2013-07-31 05:01:36 +08:00
|
|
|
return true;
|
|
|
|
|
|
|
|
unsigned BitWidth = V->getType()->getScalarSizeInBits();
|
|
|
|
APInt LHSZeroBits(BitWidth, 0), LHSOneBits(BitWidth, 0);
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(X, LHSZeroBits, LHSOneBits, nullptr, Depth, Q);
|
2013-07-31 05:01:36 +08:00
|
|
|
|
|
|
|
APInt RHSZeroBits(BitWidth, 0), RHSOneBits(BitWidth, 0);
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(Y, RHSZeroBits, RHSOneBits, nullptr, Depth, Q);
|
2013-07-31 05:01:36 +08:00
|
|
|
// If i8 V is a power of two or zero:
|
|
|
|
// ZeroBits: 1 1 1 0 1 1 1 1
|
|
|
|
// ~ZeroBits: 0 0 0 1 0 0 0 0
|
|
|
|
if ((~(LHSZeroBits & RHSZeroBits)).isPowerOf2())
|
|
|
|
// If OrZero isn't set, we cannot give back a zero result.
|
|
|
|
// Make sure either the LHS or RHS has a bit set.
|
|
|
|
if (OrZero || RHSOneBits.getBoolValue() || LHSOneBits.getBoolValue())
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
2013-05-19 03:30:37 +08:00
|
|
|
|
2011-02-28 16:02:21 +08:00
|
|
|
// An exact divide or right shift can only shift off zero bits, so the result
|
2011-03-22 05:40:32 +08:00
|
|
|
// is a power of two only if the first operand is a power of two and not
|
|
|
|
// copying a sign bit (sdiv int_min, 2).
|
2012-01-02 01:55:30 +08:00
|
|
|
if (match(V, m_Exact(m_LShr(m_Value(), m_Value()))) ||
|
|
|
|
match(V, m_Exact(m_UDiv(m_Value(), m_Value())))) {
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
return isKnownToBeAPowerOfTwo(cast<Operator>(V)->getOperand(0), OrZero,
|
|
|
|
Depth, Q);
|
2011-02-28 16:02:21 +08:00
|
|
|
}
|
|
|
|
|
2011-01-25 17:38:29 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2012-12-07 10:08:58 +08:00
|
|
|
/// \brief Test whether a GEP's result is known to be non-null.
|
|
|
|
///
|
|
|
|
/// Uses properties inherent in a GEP to try to determine whether it is known
|
|
|
|
/// to be non-null.
|
|
|
|
///
|
|
|
|
/// Currently this routine does not support vector GEPs.
|
|
|
|
static bool isGEPKnownNonNull(GEPOperator *GEP, const DataLayout *DL,
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
unsigned Depth, const Query &Q) {
|
2012-12-07 10:08:58 +08:00
|
|
|
if (!GEP->isInBounds() || GEP->getPointerAddressSpace() != 0)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// FIXME: Support vector-GEPs.
|
|
|
|
assert(GEP->getType()->isPointerTy() && "We only support plain pointer GEP");
|
|
|
|
|
|
|
|
// If the base pointer is non-null, we cannot walk to a null address with an
|
|
|
|
// inbounds GEP in address space zero.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
if (isKnownNonZero(GEP->getPointerOperand(), DL, Depth, Q))
|
2012-12-07 10:08:58 +08:00
|
|
|
return true;
|
|
|
|
|
|
|
|
// Past this, if we don't have DataLayout, we can't do much.
|
|
|
|
if (!DL)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Walk the GEP operands and see if any operand introduces a non-zero offset.
|
|
|
|
// If so, then the GEP cannot produce a null pointer, as doing so would
|
|
|
|
// inherently violate the inbounds contract within address space zero.
|
|
|
|
for (gep_type_iterator GTI = gep_type_begin(GEP), GTE = gep_type_end(GEP);
|
|
|
|
GTI != GTE; ++GTI) {
|
|
|
|
// Struct types are easy -- they must always be indexed by a constant.
|
|
|
|
if (StructType *STy = dyn_cast<StructType>(*GTI)) {
|
|
|
|
ConstantInt *OpC = cast<ConstantInt>(GTI.getOperand());
|
|
|
|
unsigned ElementIdx = OpC->getZExtValue();
|
|
|
|
const StructLayout *SL = DL->getStructLayout(STy);
|
|
|
|
uint64_t ElementOffset = SL->getElementOffset(ElementIdx);
|
|
|
|
if (ElementOffset > 0)
|
|
|
|
return true;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we have a zero-sized type, the index doesn't matter. Keep looping.
|
|
|
|
if (DL->getTypeAllocSize(GTI.getIndexedType()) == 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Fast path the constant operand case both for efficiency and so we don't
|
|
|
|
// increment Depth when just zipping down an all-constant GEP.
|
|
|
|
if (ConstantInt *OpC = dyn_cast<ConstantInt>(GTI.getOperand())) {
|
|
|
|
if (!OpC->isZero())
|
|
|
|
return true;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// We post-increment Depth here because while isKnownNonZero increments it
|
|
|
|
// as well, when we pop back up that increment won't persist. We don't want
|
|
|
|
// to recurse 10k times just because we have 10k GEP operands. We don't
|
|
|
|
// bail completely out because we want to handle constant GEPs regardless
|
|
|
|
// of depth.
|
|
|
|
if (Depth++ >= MaxDepth)
|
|
|
|
continue;
|
|
|
|
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
if (isKnownNonZero(GTI.getOperand(), DL, Depth, Q))
|
2012-12-07 10:08:58 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-10-31 04:25:19 +08:00
|
|
|
/// Does the 'Range' metadata (which must be a valid MD_range operand list)
|
|
|
|
/// ensure that the value it's attached to is never Value? 'RangeType' is
|
|
|
|
/// is the type of the value described by the range.
|
|
|
|
static bool rangeMetadataExcludesValue(MDNode* Ranges,
|
|
|
|
const APInt& Value) {
|
|
|
|
const unsigned NumRanges = Ranges->getNumOperands() / 2;
|
|
|
|
assert(NumRanges >= 1);
|
|
|
|
for (unsigned i = 0; i < NumRanges; ++i) {
|
IR: Split Metadata from Value
Split `Metadata` away from the `Value` class hierarchy, as part of
PR21532. Assembly and bitcode changes are in the wings, but this is the
bulk of the change for the IR C++ API.
I have a follow-up patch prepared for `clang`. If this breaks other
sub-projects, I apologize in advance :(. Help me compile it on Darwin
I'll try to fix it. FWIW, the errors should be easy to fix, so it may
be simpler to just fix it yourself.
This breaks the build for all metadata-related code that's out-of-tree.
Rest assured the transition is mechanical and the compiler should catch
almost all of the problems.
Here's a quick guide for updating your code:
- `Metadata` is the root of a class hierarchy with three main classes:
`MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from
the `Value` class hierarchy. It is typeless -- i.e., instances do
*not* have a `Type`.
- `MDNode`'s operands are all `Metadata *` (instead of `Value *`).
- `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be
replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively.
If you're referring solely to resolved `MDNode`s -- post graph
construction -- just use `MDNode*`.
- `MDNode` (and the rest of `Metadata`) have only limited support for
`replaceAllUsesWith()`.
As long as an `MDNode` is pointing at a forward declaration -- the
result of `MDNode::getTemporary()` -- it maintains a side map of its
uses and can RAUW itself. Once the forward declarations are fully
resolved RAUW support is dropped on the ground. This means that
uniquing collisions on changing operands cause nodes to become
"distinct". (This already happened fairly commonly, whenever an
operand went to null.)
If you're constructing complex (non self-reference) `MDNode` cycles,
you need to call `MDNode::resolveCycles()` on each node (or on a
top-level node that somehow references all of the nodes). Also,
don't do that. Metadata cycles (and the RAUW machinery needed to
construct them) are expensive.
- An `MDNode` can only refer to a `Constant` through a bridge called
`ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`).
As a side effect, accessing an operand of an `MDNode` that is known
to be, e.g., `ConstantInt`, takes three steps: first, cast from
`Metadata` to `ConstantAsMetadata`; second, extract the `Constant`;
third, cast down to `ConstantInt`.
The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have
metadata schema owners transition away from using `Constant`s when
the type isn't important (and they don't care about referring to
`GlobalValue`s).
In the meantime, I've added transitional API to the `mdconst`
namespace that matches semantics with the old code, in order to
avoid adding the error-prone three-step equivalent to every call
site. If your old code was:
MDNode *N = foo();
bar(isa <ConstantInt>(N->getOperand(0)));
baz(cast <ConstantInt>(N->getOperand(1)));
bak(cast_or_null <ConstantInt>(N->getOperand(2)));
bat(dyn_cast <ConstantInt>(N->getOperand(3)));
bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4)));
you can trivially match its semantics with:
MDNode *N = foo();
bar(mdconst::hasa <ConstantInt>(N->getOperand(0)));
baz(mdconst::extract <ConstantInt>(N->getOperand(1)));
bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2)));
bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3)));
bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4)));
and when you transition your metadata schema to `MDInt`:
MDNode *N = foo();
bar(isa <MDInt>(N->getOperand(0)));
baz(cast <MDInt>(N->getOperand(1)));
bak(cast_or_null <MDInt>(N->getOperand(2)));
bat(dyn_cast <MDInt>(N->getOperand(3)));
bay(dyn_cast_or_null<MDInt>(N->getOperand(4)));
- A `CallInst` -- specifically, intrinsic instructions -- can refer to
metadata through a bridge called `MetadataAsValue`. This is a
subclass of `Value` where `getType()->isMetadataTy()`.
`MetadataAsValue` is the *only* class that can legally refer to a
`LocalAsMetadata`, which is a bridged form of non-`Constant` values
like `Argument` and `Instruction`. It can also refer to any other
`Metadata` subclass.
(I'll break all your testcases in a follow-up commit, when I propagate
this change to assembly.)
llvm-svn: 223802
2014-12-10 02:38:53 +08:00
|
|
|
ConstantInt *Lower =
|
|
|
|
mdconst::extract<ConstantInt>(Ranges->getOperand(2 * i + 0));
|
|
|
|
ConstantInt *Upper =
|
|
|
|
mdconst::extract<ConstantInt>(Ranges->getOperand(2 * i + 1));
|
2014-10-31 04:25:19 +08:00
|
|
|
ConstantRange Range(Lower->getValue(), Upper->getValue());
|
|
|
|
if (Range.contains(Value))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-11-05 00:27:42 +08:00
|
|
|
/// Return true if the given value is known to be non-zero when defined.
|
|
|
|
/// For vectors return true if every element is known to be non-zero when
|
|
|
|
/// defined. Supports values with integer or pointer type and vectors of
|
|
|
|
/// integers.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
bool isKnownNonZero(Value *V, const DataLayout *TD, unsigned Depth,
|
|
|
|
const Query &Q) {
|
2011-01-25 17:38:29 +08:00
|
|
|
if (Constant *C = dyn_cast<Constant>(V)) {
|
|
|
|
if (C->isNullValue())
|
|
|
|
return false;
|
|
|
|
if (isa<ConstantInt>(C))
|
|
|
|
// Must be non-zero due to null test above.
|
|
|
|
return true;
|
|
|
|
// TODO: Handle vectors
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-10-31 04:25:19 +08:00
|
|
|
if (Instruction* I = dyn_cast<Instruction>(V)) {
|
2014-11-12 05:30:22 +08:00
|
|
|
if (MDNode *Ranges = I->getMetadata(LLVMContext::MD_range)) {
|
2014-10-31 04:25:19 +08:00
|
|
|
// If the possible ranges don't contain zero, then the value is
|
|
|
|
// definitely non-zero.
|
|
|
|
if (IntegerType* Ty = dyn_cast<IntegerType>(V->getType())) {
|
|
|
|
const APInt ZeroValue(Ty->getBitWidth(), 0);
|
|
|
|
if (rangeMetadataExcludesValue(Ranges, ZeroValue))
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-01-25 17:38:29 +08:00
|
|
|
// The remaining tests are all recursive, so bail out if we hit the limit.
|
2011-10-28 03:16:21 +08:00
|
|
|
if (Depth++ >= MaxDepth)
|
2011-01-25 17:38:29 +08:00
|
|
|
return false;
|
|
|
|
|
2012-12-07 10:08:58 +08:00
|
|
|
// Check for pointer simplifications.
|
|
|
|
if (V->getType()->isPointerTy()) {
|
2013-03-19 05:23:25 +08:00
|
|
|
if (isKnownNonNull(V))
|
|
|
|
return true;
|
2012-12-07 10:08:58 +08:00
|
|
|
if (GEPOperator *GEP = dyn_cast<GEPOperator>(V))
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
if (isGEPKnownNonNull(GEP, TD, Depth, Q))
|
2012-12-07 10:08:58 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2012-12-15 04:43:49 +08:00
|
|
|
unsigned BitWidth = getBitWidth(V->getType()->getScalarType(), TD);
|
2011-01-25 17:38:29 +08:00
|
|
|
|
|
|
|
// X | Y != 0 if X != 0 or Y != 0.
|
2014-04-15 12:59:12 +08:00
|
|
|
Value *X = nullptr, *Y = nullptr;
|
2011-01-25 17:38:29 +08:00
|
|
|
if (match(V, m_Or(m_Value(X), m_Value(Y))))
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
return isKnownNonZero(X, TD, Depth, Q) ||
|
|
|
|
isKnownNonZero(Y, TD, Depth, Q);
|
2011-01-25 17:38:29 +08:00
|
|
|
|
|
|
|
// ext X != 0 if X != 0.
|
|
|
|
if (isa<SExtInst>(V) || isa<ZExtInst>(V))
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
return isKnownNonZero(cast<Instruction>(V)->getOperand(0), TD, Depth, Q);
|
2011-01-25 17:38:29 +08:00
|
|
|
|
2011-01-29 21:27:00 +08:00
|
|
|
// shl X, Y != 0 if X is odd. Note that the value of the shift is undefined
|
2011-01-25 17:38:29 +08:00
|
|
|
// if the lowest bit is shifted off the end.
|
|
|
|
if (BitWidth && match(V, m_Shl(m_Value(X), m_Value(Y)))) {
|
2011-02-28 16:02:21 +08:00
|
|
|
// shl nuw can't remove any non-zero bits.
|
2011-10-28 03:16:21 +08:00
|
|
|
OverflowingBinaryOperator *BO = cast<OverflowingBinaryOperator>(V);
|
2011-02-28 16:02:21 +08:00
|
|
|
if (BO->hasNoUnsignedWrap())
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
return isKnownNonZero(X, TD, Depth, Q);
|
2011-02-28 16:02:21 +08:00
|
|
|
|
2011-01-25 17:38:29 +08:00
|
|
|
APInt KnownZero(BitWidth, 0);
|
|
|
|
APInt KnownOne(BitWidth, 0);
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(X, KnownZero, KnownOne, TD, Depth, Q);
|
2011-01-25 17:38:29 +08:00
|
|
|
if (KnownOne[0])
|
|
|
|
return true;
|
|
|
|
}
|
2011-01-29 21:27:00 +08:00
|
|
|
// shr X, Y != 0 if X is negative. Note that the value of the shift is not
|
2011-01-25 17:38:29 +08:00
|
|
|
// defined if the sign bit is shifted off the end.
|
|
|
|
else if (match(V, m_Shr(m_Value(X), m_Value(Y)))) {
|
2011-02-28 16:02:21 +08:00
|
|
|
// shr exact can only shift out zero bits.
|
2011-10-28 03:16:21 +08:00
|
|
|
PossiblyExactOperator *BO = cast<PossiblyExactOperator>(V);
|
2011-02-28 16:02:21 +08:00
|
|
|
if (BO->isExact())
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
return isKnownNonZero(X, TD, Depth, Q);
|
2011-02-28 16:02:21 +08:00
|
|
|
|
2011-01-25 17:38:29 +08:00
|
|
|
bool XKnownNonNegative, XKnownNegative;
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
ComputeSignBit(X, XKnownNonNegative, XKnownNegative, TD, Depth, Q);
|
2011-01-25 17:38:29 +08:00
|
|
|
if (XKnownNegative)
|
|
|
|
return true;
|
|
|
|
}
|
2011-02-28 16:02:21 +08:00
|
|
|
// div exact can only produce a zero if the dividend is zero.
|
2012-01-02 01:55:30 +08:00
|
|
|
else if (match(V, m_Exact(m_IDiv(m_Value(X), m_Value())))) {
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
return isKnownNonZero(X, TD, Depth, Q);
|
2011-02-28 16:02:21 +08:00
|
|
|
}
|
2011-01-25 17:38:29 +08:00
|
|
|
// X + Y.
|
|
|
|
else if (match(V, m_Add(m_Value(X), m_Value(Y)))) {
|
|
|
|
bool XKnownNonNegative, XKnownNegative;
|
|
|
|
bool YKnownNonNegative, YKnownNegative;
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
ComputeSignBit(X, XKnownNonNegative, XKnownNegative, TD, Depth, Q);
|
|
|
|
ComputeSignBit(Y, YKnownNonNegative, YKnownNegative, TD, Depth, Q);
|
2011-01-25 17:38:29 +08:00
|
|
|
|
|
|
|
// If X and Y are both non-negative (as signed values) then their sum is not
|
2011-01-25 23:14:15 +08:00
|
|
|
// zero unless both X and Y are zero.
|
2011-01-25 17:38:29 +08:00
|
|
|
if (XKnownNonNegative && YKnownNonNegative)
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
if (isKnownNonZero(X, TD, Depth, Q) ||
|
|
|
|
isKnownNonZero(Y, TD, Depth, Q))
|
2011-01-25 23:14:15 +08:00
|
|
|
return true;
|
2011-01-25 17:38:29 +08:00
|
|
|
|
|
|
|
// If X and Y are both negative (as signed values) then their sum is not
|
|
|
|
// zero unless both X and Y equal INT_MIN.
|
|
|
|
if (BitWidth && XKnownNegative && YKnownNegative) {
|
|
|
|
APInt KnownZero(BitWidth, 0);
|
|
|
|
APInt KnownOne(BitWidth, 0);
|
|
|
|
APInt Mask = APInt::getSignedMaxValue(BitWidth);
|
|
|
|
// The sign bit of X is set. If some other bit is set then X is not equal
|
|
|
|
// to INT_MIN.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(X, KnownZero, KnownOne, TD, Depth, Q);
|
2011-01-25 17:38:29 +08:00
|
|
|
if ((KnownOne & Mask) != 0)
|
|
|
|
return true;
|
|
|
|
// The sign bit of Y is set. If some other bit is set then Y is not equal
|
|
|
|
// to INT_MIN.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(Y, KnownZero, KnownOne, TD, Depth, Q);
|
2011-01-25 17:38:29 +08:00
|
|
|
if ((KnownOne & Mask) != 0)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// The sum of a non-negative number and a power of two is not zero.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
if (XKnownNonNegative &&
|
|
|
|
isKnownToBeAPowerOfTwo(Y, /*OrZero*/false, Depth, Q))
|
2011-01-25 17:38:29 +08:00
|
|
|
return true;
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
if (YKnownNonNegative &&
|
|
|
|
isKnownToBeAPowerOfTwo(X, /*OrZero*/false, Depth, Q))
|
2011-01-25 17:38:29 +08:00
|
|
|
return true;
|
|
|
|
}
|
2011-10-28 03:16:21 +08:00
|
|
|
// X * Y.
|
|
|
|
else if (match(V, m_Mul(m_Value(X), m_Value(Y)))) {
|
|
|
|
OverflowingBinaryOperator *BO = cast<OverflowingBinaryOperator>(V);
|
|
|
|
// If X and Y are non-zero then so is X * Y as long as the multiplication
|
|
|
|
// does not overflow.
|
|
|
|
if ((BO->hasNoSignedWrap() || BO->hasNoUnsignedWrap()) &&
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
isKnownNonZero(X, TD, Depth, Q) &&
|
|
|
|
isKnownNonZero(Y, TD, Depth, Q))
|
2011-10-28 03:16:21 +08:00
|
|
|
return true;
|
|
|
|
}
|
2011-01-25 17:38:29 +08:00
|
|
|
// (C ? X : Y) != 0 if X != 0 and Y != 0.
|
|
|
|
else if (SelectInst *SI = dyn_cast<SelectInst>(V)) {
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
if (isKnownNonZero(SI->getTrueValue(), TD, Depth, Q) &&
|
|
|
|
isKnownNonZero(SI->getFalseValue(), TD, Depth, Q))
|
2011-01-25 17:38:29 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!BitWidth) return false;
|
|
|
|
APInt KnownZero(BitWidth, 0);
|
|
|
|
APInt KnownOne(BitWidth, 0);
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(V, KnownZero, KnownOne, TD, Depth, Q);
|
2011-01-25 17:38:29 +08:00
|
|
|
return KnownOne != 0;
|
|
|
|
}
|
|
|
|
|
2014-11-05 00:27:42 +08:00
|
|
|
/// Return true if 'V & Mask' is known to be zero. We use this predicate to
|
|
|
|
/// simplify operations downstream. Mask is known to be zero for bits that V
|
|
|
|
/// cannot have.
|
2009-09-08 08:06:16 +08:00
|
|
|
///
|
|
|
|
/// This function is defined on values with integer type, values with pointer
|
|
|
|
/// type (but only if TD is non-null), and vectors of integers. In the case
|
|
|
|
/// where V is a vector, the mask, known zero, and known one values are the
|
|
|
|
/// same width as the vector element, and the bit is set only if it is true
|
|
|
|
/// for all of the elements in the vector.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
bool MaskedValueIsZero(Value *V, const APInt &Mask,
|
|
|
|
const DataLayout *TD, unsigned Depth,
|
|
|
|
const Query &Q) {
|
2008-06-02 09:18:21 +08:00
|
|
|
APInt KnownZero(Mask.getBitWidth(), 0), KnownOne(Mask.getBitWidth(), 0);
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(V, KnownZero, KnownOne, TD, Depth, Q);
|
2008-06-02 09:18:21 +08:00
|
|
|
return (KnownZero & Mask) == Mask;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-05 00:27:42 +08:00
|
|
|
/// Return the number of times the sign bit of the register is replicated into
|
|
|
|
/// the other bits. We know that at least 1 bit is always equal to the sign bit
|
|
|
|
/// (itself), but other cases can give us information. For example, immediately
|
|
|
|
/// after an "ashr X, 2", we know that the top 3 bits are all equal to each
|
|
|
|
/// other, so we return 3.
|
2008-06-02 09:18:21 +08:00
|
|
|
///
|
|
|
|
/// 'Op' must have a scalar integer type.
|
|
|
|
///
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
unsigned ComputeNumSignBits(Value *V, const DataLayout *TD,
|
|
|
|
unsigned Depth, const Query &Q) {
|
2010-02-16 00:12:20 +08:00
|
|
|
assert((TD || V->getType()->isIntOrIntVectorTy()) &&
|
2012-10-09 00:38:25 +08:00
|
|
|
"ComputeNumSignBits requires a DataLayout object to operate "
|
2009-06-23 06:02:32 +08:00
|
|
|
"on non-integer values!");
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *Ty = V->getType();
|
2009-06-23 06:02:32 +08:00
|
|
|
unsigned TyBits = TD ? TD->getTypeSizeInBits(V->getType()->getScalarType()) :
|
|
|
|
Ty->getScalarSizeInBits();
|
2008-06-02 09:18:21 +08:00
|
|
|
unsigned Tmp, Tmp2;
|
|
|
|
unsigned FirstAnswer = 1;
|
|
|
|
|
2014-05-15 05:14:37 +08:00
|
|
|
// Note that ConstantInt is handled by the general computeKnownBits case
|
2008-06-03 02:39:07 +08:00
|
|
|
// below.
|
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
if (Depth == 6)
|
|
|
|
return 1; // Limit search depth.
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2009-07-18 04:47:02 +08:00
|
|
|
Operator *U = dyn_cast<Operator>(V);
|
|
|
|
switch (Operator::getOpcode(V)) {
|
2008-06-02 09:18:21 +08:00
|
|
|
default: break;
|
|
|
|
case Instruction::SExt:
|
2009-12-02 12:59:58 +08:00
|
|
|
Tmp = TyBits - U->getOperand(0)->getType()->getScalarSizeInBits();
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
return ComputeNumSignBits(U->getOperand(0), TD, Depth+1, Q) + Tmp;
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2012-01-27 05:37:55 +08:00
|
|
|
case Instruction::AShr: {
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
Tmp = ComputeNumSignBits(U->getOperand(0), TD, Depth+1, Q);
|
2012-01-27 05:37:55 +08:00
|
|
|
// ashr X, C -> adds C sign bits. Vectors too.
|
|
|
|
const APInt *ShAmt;
|
|
|
|
if (match(U->getOperand(1), m_APInt(ShAmt))) {
|
|
|
|
Tmp += ShAmt->getZExtValue();
|
2008-06-02 09:18:21 +08:00
|
|
|
if (Tmp > TyBits) Tmp = TyBits;
|
|
|
|
}
|
|
|
|
return Tmp;
|
2012-01-27 05:37:55 +08:00
|
|
|
}
|
|
|
|
case Instruction::Shl: {
|
|
|
|
const APInt *ShAmt;
|
|
|
|
if (match(U->getOperand(1), m_APInt(ShAmt))) {
|
2008-06-02 09:18:21 +08:00
|
|
|
// shl destroys sign bits.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
Tmp = ComputeNumSignBits(U->getOperand(0), TD, Depth+1, Q);
|
2012-01-27 05:37:55 +08:00
|
|
|
Tmp2 = ShAmt->getZExtValue();
|
|
|
|
if (Tmp2 >= TyBits || // Bad shift.
|
|
|
|
Tmp2 >= Tmp) break; // Shifted all sign bits out.
|
|
|
|
return Tmp - Tmp2;
|
2008-06-02 09:18:21 +08:00
|
|
|
}
|
|
|
|
break;
|
2012-01-27 05:37:55 +08:00
|
|
|
}
|
2008-06-02 09:18:21 +08:00
|
|
|
case Instruction::And:
|
|
|
|
case Instruction::Or:
|
|
|
|
case Instruction::Xor: // NOT is handled here.
|
|
|
|
// Logical binary ops preserve the number of sign bits at the worst.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
Tmp = ComputeNumSignBits(U->getOperand(0), TD, Depth+1, Q);
|
2008-06-02 09:18:21 +08:00
|
|
|
if (Tmp != 1) {
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
Tmp2 = ComputeNumSignBits(U->getOperand(1), TD, Depth+1, Q);
|
2008-06-02 09:18:21 +08:00
|
|
|
FirstAnswer = std::min(Tmp, Tmp2);
|
|
|
|
// We computed what we know about the sign bits as our first
|
|
|
|
// answer. Now proceed to the generic code that uses
|
2014-05-15 05:14:37 +08:00
|
|
|
// computeKnownBits, and pick whichever answer is better.
|
2008-06-02 09:18:21 +08:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case Instruction::Select:
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
Tmp = ComputeNumSignBits(U->getOperand(1), TD, Depth+1, Q);
|
2008-06-02 09:18:21 +08:00
|
|
|
if (Tmp == 1) return 1; // Early out.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
Tmp2 = ComputeNumSignBits(U->getOperand(2), TD, Depth+1, Q);
|
2008-06-02 09:18:21 +08:00
|
|
|
return std::min(Tmp, Tmp2);
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
case Instruction::Add:
|
|
|
|
// Add can have at most one carry bit. Thus we know that the output
|
|
|
|
// is, at worst, one more bit than the inputs.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
Tmp = ComputeNumSignBits(U->getOperand(0), TD, Depth+1, Q);
|
2008-06-02 09:18:21 +08:00
|
|
|
if (Tmp == 1) return 1; // Early out.
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
// Special case decrementing a value (ADD X, -1):
|
2014-12-26 17:20:17 +08:00
|
|
|
if (const auto *CRHS = dyn_cast<Constant>(U->getOperand(1)))
|
2008-06-02 09:18:21 +08:00
|
|
|
if (CRHS->isAllOnesValue()) {
|
|
|
|
APInt KnownZero(TyBits, 0), KnownOne(TyBits, 0);
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(U->getOperand(0), KnownZero, KnownOne, TD, Depth+1, Q);
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
// If the input is known to be 0 or 1, the output is 0/-1, which is all
|
|
|
|
// sign bits set.
|
2012-04-04 20:51:34 +08:00
|
|
|
if ((KnownZero | APInt(TyBits, 1)).isAllOnesValue())
|
2008-06-02 09:18:21 +08:00
|
|
|
return TyBits;
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
// If we are subtracting one from a positive number, there is no carry
|
|
|
|
// out of the result.
|
|
|
|
if (KnownZero.isNegative())
|
|
|
|
return Tmp;
|
|
|
|
}
|
2012-12-23 03:15:35 +08:00
|
|
|
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
Tmp2 = ComputeNumSignBits(U->getOperand(1), TD, Depth+1, Q);
|
2008-06-02 09:18:21 +08:00
|
|
|
if (Tmp2 == 1) return 1;
|
2010-01-08 07:44:37 +08:00
|
|
|
return std::min(Tmp, Tmp2)-1;
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
case Instruction::Sub:
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
Tmp2 = ComputeNumSignBits(U->getOperand(1), TD, Depth+1, Q);
|
2008-06-02 09:18:21 +08:00
|
|
|
if (Tmp2 == 1) return 1;
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
// Handle NEG.
|
2014-12-26 17:20:17 +08:00
|
|
|
if (const auto *CLHS = dyn_cast<Constant>(U->getOperand(0)))
|
2008-06-02 09:18:21 +08:00
|
|
|
if (CLHS->isNullValue()) {
|
|
|
|
APInt KnownZero(TyBits, 0), KnownOne(TyBits, 0);
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(U->getOperand(1), KnownZero, KnownOne, TD, Depth+1, Q);
|
2008-06-02 09:18:21 +08:00
|
|
|
// If the input is known to be 0 or 1, the output is 0/-1, which is all
|
|
|
|
// sign bits set.
|
2012-04-04 20:51:34 +08:00
|
|
|
if ((KnownZero | APInt(TyBits, 1)).isAllOnesValue())
|
2008-06-02 09:18:21 +08:00
|
|
|
return TyBits;
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
// If the input is known to be positive (the sign bit is known clear),
|
|
|
|
// the output of the NEG has the same number of sign bits as the input.
|
|
|
|
if (KnownZero.isNegative())
|
|
|
|
return Tmp2;
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
// Otherwise, we treat this like a SUB.
|
|
|
|
}
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
// Sub can have at most one carry bit. Thus we know that the output
|
|
|
|
// is, at worst, one more bit than the inputs.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
Tmp = ComputeNumSignBits(U->getOperand(0), TD, Depth+1, Q);
|
2008-06-02 09:18:21 +08:00
|
|
|
if (Tmp == 1) return 1; // Early out.
|
2010-01-08 07:44:37 +08:00
|
|
|
return std::min(Tmp, Tmp2)-1;
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2010-01-08 07:44:37 +08:00
|
|
|
case Instruction::PHI: {
|
|
|
|
PHINode *PN = cast<PHINode>(U);
|
2015-01-04 15:06:53 +08:00
|
|
|
unsigned NumIncomingValues = PN->getNumIncomingValues();
|
2010-01-08 07:44:37 +08:00
|
|
|
// Don't analyze large in-degree PHIs.
|
2015-01-04 15:06:53 +08:00
|
|
|
if (NumIncomingValues > 4) break;
|
|
|
|
// Unreachable blocks may have zero-operand PHI nodes.
|
|
|
|
if (NumIncomingValues == 0) break;
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2010-01-08 07:44:37 +08:00
|
|
|
// Take the minimum of all incoming values. This can't infinitely loop
|
|
|
|
// because of our depth threshold.
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
Tmp = ComputeNumSignBits(PN->getIncomingValue(0), TD, Depth+1, Q);
|
2015-01-04 15:06:53 +08:00
|
|
|
for (unsigned i = 1, e = NumIncomingValues; i != e; ++i) {
|
2010-01-08 07:44:37 +08:00
|
|
|
if (Tmp == 1) return Tmp;
|
|
|
|
Tmp = std::min(Tmp,
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
ComputeNumSignBits(PN->getIncomingValue(i), TD,
|
|
|
|
Depth+1, Q));
|
2010-01-08 07:44:37 +08:00
|
|
|
}
|
|
|
|
return Tmp;
|
|
|
|
}
|
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
case Instruction::Trunc:
|
|
|
|
// FIXME: it's tricky to do anything useful for this, but it is an important
|
|
|
|
// case for targets like X86.
|
|
|
|
break;
|
|
|
|
}
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
// Finally, if we can prove that the top bits of the result are 0's or 1's,
|
|
|
|
// use this information.
|
|
|
|
APInt KnownZero(TyBits, 0), KnownOne(TyBits, 0);
|
2012-04-04 20:51:34 +08:00
|
|
|
APInt Mask;
|
Make use of @llvm.assume in ValueTracking (computeKnownBits, etc.)
This change, which allows @llvm.assume to be used from within computeKnownBits
(and other associated functions in ValueTracking), adds some (optional)
parameters to computeKnownBits and friends. These functions now (optionally)
take a "context" instruction pointer, an AssumptionTracker pointer, and also a
DomTree pointer, and most of the changes are just to pass this new information
when it is easily available from InstSimplify, InstCombine, etc.
As explained below, the significant conceptual change is that known properties
of a value might depend on the control-flow location of the use (because we
care that the @llvm.assume dominates the use because assumptions have
control-flow dependencies). This means that, when we ask if bits are known in a
value, we might get different answers for different uses.
The significant changes are all in ValueTracking. Two main changes: First, as
with the rest of the code, new parameters need to be passed around. To make
this easier, I grouped them into a structure, and I made internal static
versions of the relevant functions that take this structure as a parameter. The
new code does as you might expect, it looks for @llvm.assume calls that make
use of the value we're trying to learn something about (often indirectly),
attempts to pattern match that expression, and uses the result if successful.
By making use of the AssumptionTracker, the process of finding @llvm.assume
calls is not expensive.
Part of the structure being passed around inside ValueTracking is a set of
already-considered @llvm.assume calls. This is to prevent a query using, for
example, the assume(a == b), to recurse on itself. The context and DT params
are used to find applicable assumptions. An assumption needs to dominate the
context instruction, or come after it deterministically. In this latter case we
only handle the specific case where both the assumption and the context
instruction are in the same block, and we need to exclude assumptions from
being used to simplify their own ephemeral values (those which contribute only
to the assumption) because otherwise the assumption would prove its feeding
comparison trivial and would be removed.
This commit adds the plumbing and the logic for a simple masked-bit propagation
(just enough to write a regression test). Future commits add more patterns
(and, correspondingly, more regression tests).
llvm-svn: 217342
2014-09-08 02:57:58 +08:00
|
|
|
computeKnownBits(V, KnownZero, KnownOne, TD, Depth, Q);
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
if (KnownZero.isNegative()) { // sign bit is 0
|
|
|
|
Mask = KnownZero;
|
|
|
|
} else if (KnownOne.isNegative()) { // sign bit is 1;
|
|
|
|
Mask = KnownOne;
|
|
|
|
} else {
|
|
|
|
// Nothing known.
|
|
|
|
return FirstAnswer;
|
|
|
|
}
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:18:21 +08:00
|
|
|
// Okay, we know that the sign bit in Mask is set. Use CLZ to determine
|
|
|
|
// the number of identical bits in the top of the input value.
|
|
|
|
Mask = ~Mask;
|
|
|
|
Mask <<= Mask.getBitWidth()-TyBits;
|
|
|
|
// Return # leading zeros. We use 'min' here in case Val was zero before
|
|
|
|
// shifting. We don't want to return '64' as for an i32 "0".
|
|
|
|
return std::max(FirstAnswer, std::min(TyBits, Mask.countLeadingZeros()));
|
|
|
|
}
|
2008-06-02 09:29:46 +08:00
|
|
|
|
2014-11-05 00:27:42 +08:00
|
|
|
/// This function computes the integer multiple of Base that equals V.
|
|
|
|
/// If successful, it returns true and returns the multiple in
|
|
|
|
/// Multiple. If unsuccessful, it returns false. It looks
|
2009-11-10 16:28:35 +08:00
|
|
|
/// through SExt instructions only if LookThroughSExt is true.
|
|
|
|
bool llvm::ComputeMultiple(Value *V, unsigned Base, Value *&Multiple,
|
2009-11-18 08:58:27 +08:00
|
|
|
bool LookThroughSExt, unsigned Depth) {
|
2009-11-10 16:28:35 +08:00
|
|
|
const unsigned MaxDepth = 6;
|
|
|
|
|
2009-11-18 08:58:27 +08:00
|
|
|
assert(V && "No Value?");
|
2009-11-10 16:28:35 +08:00
|
|
|
assert(Depth <= MaxDepth && "Limit Search Depth");
|
2010-02-16 00:12:20 +08:00
|
|
|
assert(V->getType()->isIntegerTy() && "Not integer or pointer type!");
|
2009-11-10 16:28:35 +08:00
|
|
|
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *T = V->getType();
|
2009-11-10 16:28:35 +08:00
|
|
|
|
2009-11-18 08:58:27 +08:00
|
|
|
ConstantInt *CI = dyn_cast<ConstantInt>(V);
|
2009-11-10 16:28:35 +08:00
|
|
|
|
|
|
|
if (Base == 0)
|
|
|
|
return false;
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2009-11-10 16:28:35 +08:00
|
|
|
if (Base == 1) {
|
|
|
|
Multiple = V;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
ConstantExpr *CO = dyn_cast<ConstantExpr>(V);
|
|
|
|
Constant *BaseVal = ConstantInt::get(T, Base);
|
|
|
|
if (CO && CO == BaseVal) {
|
|
|
|
// Multiple is 1.
|
|
|
|
Multiple = ConstantInt::get(T, 1);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (CI && CI->getZExtValue() % Base == 0) {
|
|
|
|
Multiple = ConstantInt::get(T, CI->getZExtValue() / Base);
|
2012-12-23 03:15:35 +08:00
|
|
|
return true;
|
2009-11-10 16:28:35 +08:00
|
|
|
}
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2009-11-10 16:28:35 +08:00
|
|
|
if (Depth == MaxDepth) return false; // Limit search depth.
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2009-11-10 16:28:35 +08:00
|
|
|
Operator *I = dyn_cast<Operator>(V);
|
|
|
|
if (!I) return false;
|
|
|
|
|
|
|
|
switch (I->getOpcode()) {
|
|
|
|
default: break;
|
2009-11-26 09:50:12 +08:00
|
|
|
case Instruction::SExt:
|
2009-11-10 16:28:35 +08:00
|
|
|
if (!LookThroughSExt) return false;
|
|
|
|
// otherwise fall through to ZExt
|
2009-11-26 09:50:12 +08:00
|
|
|
case Instruction::ZExt:
|
2009-11-18 08:58:27 +08:00
|
|
|
return ComputeMultiple(I->getOperand(0), Base, Multiple,
|
|
|
|
LookThroughSExt, Depth+1);
|
2009-11-10 16:28:35 +08:00
|
|
|
case Instruction::Shl:
|
|
|
|
case Instruction::Mul: {
|
|
|
|
Value *Op0 = I->getOperand(0);
|
|
|
|
Value *Op1 = I->getOperand(1);
|
|
|
|
|
|
|
|
if (I->getOpcode() == Instruction::Shl) {
|
|
|
|
ConstantInt *Op1CI = dyn_cast<ConstantInt>(Op1);
|
|
|
|
if (!Op1CI) return false;
|
|
|
|
// Turn Op0 << Op1 into Op0 * 2^Op1
|
|
|
|
APInt Op1Int = Op1CI->getValue();
|
|
|
|
uint64_t BitToSet = Op1Int.getLimitedValue(Op1Int.getBitWidth() - 1);
|
2010-11-30 17:02:01 +08:00
|
|
|
APInt API(Op1Int.getBitWidth(), 0);
|
2010-12-01 16:53:58 +08:00
|
|
|
API.setBit(BitToSet);
|
2010-11-30 17:02:01 +08:00
|
|
|
Op1 = ConstantInt::get(V->getContext(), API);
|
2009-11-10 16:28:35 +08:00
|
|
|
}
|
|
|
|
|
2014-04-15 12:59:12 +08:00
|
|
|
Value *Mul0 = nullptr;
|
2010-09-06 01:20:46 +08:00
|
|
|
if (ComputeMultiple(Op0, Base, Mul0, LookThroughSExt, Depth+1)) {
|
|
|
|
if (Constant *Op1C = dyn_cast<Constant>(Op1))
|
|
|
|
if (Constant *MulC = dyn_cast<Constant>(Mul0)) {
|
2012-12-23 03:15:35 +08:00
|
|
|
if (Op1C->getType()->getPrimitiveSizeInBits() <
|
2010-09-06 01:20:46 +08:00
|
|
|
MulC->getType()->getPrimitiveSizeInBits())
|
|
|
|
Op1C = ConstantExpr::getZExt(Op1C, MulC->getType());
|
2012-12-23 03:15:35 +08:00
|
|
|
if (Op1C->getType()->getPrimitiveSizeInBits() >
|
2010-09-06 01:20:46 +08:00
|
|
|
MulC->getType()->getPrimitiveSizeInBits())
|
|
|
|
MulC = ConstantExpr::getZExt(MulC, Op1C->getType());
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2010-09-06 01:20:46 +08:00
|
|
|
// V == Base * (Mul0 * Op1), so return (Mul0 * Op1)
|
|
|
|
Multiple = ConstantExpr::getMul(MulC, Op1C);
|
|
|
|
return true;
|
|
|
|
}
|
2009-11-10 16:28:35 +08:00
|
|
|
|
|
|
|
if (ConstantInt *Mul0CI = dyn_cast<ConstantInt>(Mul0))
|
|
|
|
if (Mul0CI->getValue() == 1) {
|
|
|
|
// V == Base * Op1, so return Op1
|
|
|
|
Multiple = Op1;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-04-15 12:59:12 +08:00
|
|
|
Value *Mul1 = nullptr;
|
2010-09-06 01:20:46 +08:00
|
|
|
if (ComputeMultiple(Op1, Base, Mul1, LookThroughSExt, Depth+1)) {
|
|
|
|
if (Constant *Op0C = dyn_cast<Constant>(Op0))
|
|
|
|
if (Constant *MulC = dyn_cast<Constant>(Mul1)) {
|
2012-12-23 03:15:35 +08:00
|
|
|
if (Op0C->getType()->getPrimitiveSizeInBits() <
|
2010-09-06 01:20:46 +08:00
|
|
|
MulC->getType()->getPrimitiveSizeInBits())
|
|
|
|
Op0C = ConstantExpr::getZExt(Op0C, MulC->getType());
|
2012-12-23 03:15:35 +08:00
|
|
|
if (Op0C->getType()->getPrimitiveSizeInBits() >
|
2010-09-06 01:20:46 +08:00
|
|
|
MulC->getType()->getPrimitiveSizeInBits())
|
|
|
|
MulC = ConstantExpr::getZExt(MulC, Op0C->getType());
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2010-09-06 01:20:46 +08:00
|
|
|
// V == Base * (Mul1 * Op0), so return (Mul1 * Op0)
|
|
|
|
Multiple = ConstantExpr::getMul(MulC, Op0C);
|
|
|
|
return true;
|
|
|
|
}
|
2009-11-10 16:28:35 +08:00
|
|
|
|
|
|
|
if (ConstantInt *Mul1CI = dyn_cast<ConstantInt>(Mul1))
|
|
|
|
if (Mul1CI->getValue() == 1) {
|
|
|
|
// V == Base * Op0, so return Op0
|
|
|
|
Multiple = Op0;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// We could not determine if V is a multiple of Base.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-11-05 00:27:42 +08:00
|
|
|
/// Return true if we can prove that the specified FP value is never equal to
|
|
|
|
/// -0.0.
|
2008-06-02 09:29:46 +08:00
|
|
|
///
|
|
|
|
/// NOTE: this function will need to be revisited when we support non-default
|
|
|
|
/// rounding modes!
|
|
|
|
///
|
|
|
|
bool llvm::CannotBeNegativeZero(const Value *V, unsigned Depth) {
|
|
|
|
if (const ConstantFP *CFP = dyn_cast<ConstantFP>(V))
|
|
|
|
return !CFP->getValueAPF().isNegZero();
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:29:46 +08:00
|
|
|
if (Depth == 6)
|
|
|
|
return 1; // Limit search depth.
|
|
|
|
|
2009-07-18 04:47:02 +08:00
|
|
|
const Operator *I = dyn_cast<Operator>(V);
|
2014-04-15 12:59:12 +08:00
|
|
|
if (!I) return false;
|
2012-12-06 08:07:09 +08:00
|
|
|
|
|
|
|
// Check if the nsz fast-math flag is set
|
|
|
|
if (const FPMathOperator *FPO = dyn_cast<FPMathOperator>(I))
|
|
|
|
if (FPO->hasNoSignedZeros())
|
|
|
|
return true;
|
|
|
|
|
2008-06-02 09:29:46 +08:00
|
|
|
// (add x, 0.0) is guaranteed to return +0.0, not -0.0.
|
2013-03-06 08:16:16 +08:00
|
|
|
if (I->getOpcode() == Instruction::FAdd)
|
|
|
|
if (ConstantFP *CFP = dyn_cast<ConstantFP>(I->getOperand(1)))
|
|
|
|
if (CFP->isNullValue())
|
|
|
|
return true;
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:29:46 +08:00
|
|
|
// sitofp and uitofp turn into +0.0 for zero.
|
|
|
|
if (isa<SIToFPInst>(I) || isa<UIToFPInst>(I))
|
|
|
|
return true;
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:29:46 +08:00
|
|
|
if (const IntrinsicInst *II = dyn_cast<IntrinsicInst>(I))
|
|
|
|
// sqrt(-0.0) = -0.0, no other negative results are possible.
|
|
|
|
if (II->getIntrinsicID() == Intrinsic::sqrt)
|
2010-06-24 07:38:07 +08:00
|
|
|
return CannotBeNegativeZero(II->getArgOperand(0), Depth+1);
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:29:46 +08:00
|
|
|
if (const CallInst *CI = dyn_cast<CallInst>(I))
|
|
|
|
if (const Function *F = CI->getCalledFunction()) {
|
|
|
|
if (F->isDeclaration()) {
|
2009-07-26 16:34:35 +08:00
|
|
|
// abs(x) != -0.0
|
|
|
|
if (F->getName() == "abs") return true;
|
2009-09-26 04:54:50 +08:00
|
|
|
// fabs[lf](x) != -0.0
|
|
|
|
if (F->getName() == "fabs") return true;
|
|
|
|
if (F->getName() == "fabsf") return true;
|
|
|
|
if (F->getName() == "fabsl") return true;
|
|
|
|
if (F->getName() == "sqrt" || F->getName() == "sqrtf" ||
|
|
|
|
F->getName() == "sqrtl")
|
2010-06-24 07:38:07 +08:00
|
|
|
return CannotBeNegativeZero(CI->getArgOperand(0), Depth+1);
|
2008-06-02 09:29:46 +08:00
|
|
|
}
|
|
|
|
}
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-02 09:29:46 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-01-28 16:03:58 +08:00
|
|
|
bool llvm::CannotBeOrderedLessThanZero(const Value *V, unsigned Depth) {
|
|
|
|
if (const ConstantFP *CFP = dyn_cast<ConstantFP>(V))
|
|
|
|
return !CFP->getValueAPF().isNegative() || CFP->getValueAPF().isZero();
|
|
|
|
|
|
|
|
if (Depth == 6)
|
|
|
|
return false; // Limit search depth.
|
|
|
|
|
|
|
|
const Operator *I = dyn_cast<Operator>(V);
|
|
|
|
if (!I) return false;
|
|
|
|
|
|
|
|
switch (I->getOpcode()) {
|
|
|
|
default: break;
|
|
|
|
case Instruction::FMul:
|
|
|
|
// x*x is always non-negative or a NaN.
|
|
|
|
if (I->getOperand(0) == I->getOperand(1))
|
|
|
|
return true;
|
|
|
|
// Fall through
|
|
|
|
case Instruction::FAdd:
|
|
|
|
case Instruction::FDiv:
|
|
|
|
case Instruction::FRem:
|
|
|
|
return CannotBeOrderedLessThanZero(I->getOperand(0), Depth+1) &&
|
|
|
|
CannotBeOrderedLessThanZero(I->getOperand(1), Depth+1);
|
|
|
|
case Instruction::FPExt:
|
|
|
|
case Instruction::FPTrunc:
|
|
|
|
// Widening/narrowing never change sign.
|
|
|
|
return CannotBeOrderedLessThanZero(I->getOperand(0), Depth+1);
|
|
|
|
case Instruction::Call:
|
|
|
|
if (const IntrinsicInst *II = dyn_cast<IntrinsicInst>(I))
|
|
|
|
switch (II->getIntrinsicID()) {
|
|
|
|
default: break;
|
|
|
|
case Intrinsic::exp:
|
|
|
|
case Intrinsic::exp2:
|
|
|
|
case Intrinsic::fabs:
|
|
|
|
case Intrinsic::sqrt:
|
|
|
|
return true;
|
|
|
|
case Intrinsic::powi:
|
|
|
|
if (ConstantInt *CI = dyn_cast<ConstantInt>(I->getOperand(1))) {
|
|
|
|
// powi(x,n) is non-negative if n is even.
|
|
|
|
if (CI->getBitWidth() <= 64 && CI->getSExtValue() % 2u == 0)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return CannotBeOrderedLessThanZero(I->getOperand(0), Depth+1);
|
|
|
|
case Intrinsic::fma:
|
|
|
|
case Intrinsic::fmuladd:
|
|
|
|
// x*x+y is non-negative if y is non-negative.
|
|
|
|
return I->getOperand(0) == I->getOperand(1) &&
|
|
|
|
CannotBeOrderedLessThanZero(I->getOperand(2), Depth+1);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-11-05 00:27:42 +08:00
|
|
|
/// If the specified value can be set by repeating the same byte in memory,
|
|
|
|
/// return the i8 value that it is represented with. This is
|
2010-12-27 04:15:01 +08:00
|
|
|
/// true for all i8 values obviously, but is also true for i32 0, i32 -1,
|
|
|
|
/// i16 0xF0F0, double 0.0 etc. If the value can't be handled with a repeated
|
|
|
|
/// byte store (e.g. i16 0x1234), return null.
|
|
|
|
Value *llvm::isBytewiseValue(Value *V) {
|
|
|
|
// All byte-wide stores are splatable, even of arbitrary variables.
|
|
|
|
if (V->getType()->isIntegerTy(8)) return V;
|
2011-02-20 03:35:49 +08:00
|
|
|
|
|
|
|
// Handle 'null' ConstantArrayZero etc.
|
|
|
|
if (Constant *C = dyn_cast<Constant>(V))
|
|
|
|
if (C->isNullValue())
|
|
|
|
return Constant::getNullValue(Type::getInt8Ty(V->getContext()));
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2010-12-27 04:15:01 +08:00
|
|
|
// Constant float and double values can be handled as integer values if the
|
2012-12-23 03:15:35 +08:00
|
|
|
// corresponding integer value is "byteable". An important case is 0.0.
|
2010-12-27 04:15:01 +08:00
|
|
|
if (ConstantFP *CFP = dyn_cast<ConstantFP>(V)) {
|
|
|
|
if (CFP->getType()->isFloatTy())
|
|
|
|
V = ConstantExpr::getBitCast(CFP, Type::getInt32Ty(V->getContext()));
|
|
|
|
if (CFP->getType()->isDoubleTy())
|
|
|
|
V = ConstantExpr::getBitCast(CFP, Type::getInt64Ty(V->getContext()));
|
|
|
|
// Don't handle long double formats, which have strange constraints.
|
|
|
|
}
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2015-02-08 03:29:02 +08:00
|
|
|
// We can handle constant integers that are multiple of 8 bits.
|
2010-12-27 04:15:01 +08:00
|
|
|
if (ConstantInt *CI = dyn_cast<ConstantInt>(V)) {
|
2015-02-08 03:29:02 +08:00
|
|
|
if (CI->getBitWidth() % 8 == 0) {
|
|
|
|
assert(CI->getBitWidth() > 8 && "8 bits should be handled above!");
|
|
|
|
|
|
|
|
// We can check that all bytes of an integer are equal by making use of a
|
|
|
|
// little trick: rotate by 8 and check if it's still the same value.
|
|
|
|
if (CI->getValue() != CI->getValue().rotl(8))
|
|
|
|
return nullptr;
|
|
|
|
return ConstantInt::get(V->getContext(), CI->getValue().trunc(8));
|
2010-12-27 04:15:01 +08:00
|
|
|
}
|
|
|
|
}
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2012-02-05 10:29:43 +08:00
|
|
|
// A ConstantDataArray/Vector is splatable if all its members are equal and
|
|
|
|
// also splatable.
|
|
|
|
if (ConstantDataSequential *CA = dyn_cast<ConstantDataSequential>(V)) {
|
|
|
|
Value *Elt = CA->getElementAsConstant(0);
|
|
|
|
Value *Val = isBytewiseValue(Elt);
|
2010-12-27 04:15:01 +08:00
|
|
|
if (!Val)
|
2014-04-15 12:59:12 +08:00
|
|
|
return nullptr;
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2012-02-05 10:29:43 +08:00
|
|
|
for (unsigned I = 1, E = CA->getNumElements(); I != E; ++I)
|
|
|
|
if (CA->getElementAsConstant(I) != Elt)
|
2014-04-15 12:59:12 +08:00
|
|
|
return nullptr;
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2010-12-27 04:15:01 +08:00
|
|
|
return Val;
|
|
|
|
}
|
2011-12-06 08:19:08 +08:00
|
|
|
|
2010-12-27 04:15:01 +08:00
|
|
|
// Conceptually, we could handle things like:
|
|
|
|
// %a = zext i8 %X to i16
|
|
|
|
// %b = shl i16 %a, 8
|
|
|
|
// %c = or i16 %a, %b
|
|
|
|
// but until there is an example that actually needs this, it doesn't seem
|
|
|
|
// worth worrying about.
|
2014-04-15 12:59:12 +08:00
|
|
|
return nullptr;
|
2010-12-27 04:15:01 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2008-06-16 20:48:21 +08:00
|
|
|
// This is the recursive version of BuildSubAggregate. It takes a few different
|
|
|
|
// arguments. Idxs is the index within the nested struct From that we are
|
|
|
|
// looking at now (which is of type IndexedType). IdxSkip is the number of
|
|
|
|
// indices from Idxs that should be left out when inserting into the resulting
|
|
|
|
// struct. To is the result struct built so far, new insertvalue instructions
|
|
|
|
// build on that.
|
2011-07-18 12:54:35 +08:00
|
|
|
static Value *BuildSubAggregate(Value *From, Value* To, Type *IndexedType,
|
2013-07-12 00:22:38 +08:00
|
|
|
SmallVectorImpl<unsigned> &Idxs,
|
2009-08-07 09:32:21 +08:00
|
|
|
unsigned IdxSkip,
|
|
|
|
Instruction *InsertBefore) {
|
2013-01-14 00:01:15 +08:00
|
|
|
llvm::StructType *STy = dyn_cast<llvm::StructType>(IndexedType);
|
2008-06-16 20:48:21 +08:00
|
|
|
if (STy) {
|
2008-06-16 22:13:46 +08:00
|
|
|
// Save the original To argument so we can modify it
|
|
|
|
Value *OrigTo = To;
|
2008-06-16 20:48:21 +08:00
|
|
|
// General case, the type indexed by Idxs is a struct
|
|
|
|
for (unsigned i = 0, e = STy->getNumElements(); i != e; ++i) {
|
|
|
|
// Process each struct element recursively
|
|
|
|
Idxs.push_back(i);
|
2008-06-16 22:13:46 +08:00
|
|
|
Value *PrevTo = To;
|
2008-06-16 20:57:37 +08:00
|
|
|
To = BuildSubAggregate(From, To, STy->getElementType(i), Idxs, IdxSkip,
|
2009-11-23 11:29:18 +08:00
|
|
|
InsertBefore);
|
2008-06-16 20:48:21 +08:00
|
|
|
Idxs.pop_back();
|
2008-06-16 22:13:46 +08:00
|
|
|
if (!To) {
|
|
|
|
// Couldn't find any inserted value for this index? Cleanup
|
|
|
|
while (PrevTo != OrigTo) {
|
|
|
|
InsertValueInst* Del = cast<InsertValueInst>(PrevTo);
|
|
|
|
PrevTo = Del->getAggregateOperand();
|
|
|
|
Del->eraseFromParent();
|
|
|
|
}
|
|
|
|
// Stop processing elements
|
|
|
|
break;
|
|
|
|
}
|
2008-06-16 20:48:21 +08:00
|
|
|
}
|
2011-04-15 13:18:47 +08:00
|
|
|
// If we successfully found a value for each of our subaggregates
|
2008-06-16 22:13:46 +08:00
|
|
|
if (To)
|
|
|
|
return To;
|
2008-06-16 20:48:21 +08:00
|
|
|
}
|
2008-06-16 22:13:46 +08:00
|
|
|
// Base case, the type indexed by SourceIdxs is not a struct, or not all of
|
|
|
|
// the struct's elements had a value that was inserted directly. In the latter
|
|
|
|
// case, perhaps we can't determine each of the subelements individually, but
|
|
|
|
// we might be able to find the complete struct somewhere.
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-16 22:13:46 +08:00
|
|
|
// Find the value that is at that particular spot
|
2011-07-13 18:26:04 +08:00
|
|
|
Value *V = FindInsertedValue(From, Idxs);
|
2008-06-16 22:13:46 +08:00
|
|
|
|
|
|
|
if (!V)
|
2014-04-15 12:59:12 +08:00
|
|
|
return nullptr;
|
2008-06-16 22:13:46 +08:00
|
|
|
|
|
|
|
// Insert the value in the new (sub) aggregrate
|
2011-07-18 20:00:32 +08:00
|
|
|
return llvm::InsertValueInst::Create(To, V, makeArrayRef(Idxs).slice(IdxSkip),
|
2011-07-13 18:26:04 +08:00
|
|
|
"tmp", InsertBefore);
|
2008-06-16 20:48:21 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// This helper takes a nested struct and extracts a part of it (which is again a
|
|
|
|
// struct) into a new value. For example, given the struct:
|
|
|
|
// { a, { b, { c, d }, e } }
|
|
|
|
// and the indices "1, 1" this returns
|
|
|
|
// { c, d }.
|
|
|
|
//
|
2008-06-16 22:13:46 +08:00
|
|
|
// It does this by inserting an insertvalue for each element in the resulting
|
|
|
|
// struct, as opposed to just inserting a single struct. This will only work if
|
|
|
|
// each of the elements of the substruct are known (ie, inserted into From by an
|
|
|
|
// insertvalue instruction somewhere).
|
2008-06-16 20:48:21 +08:00
|
|
|
//
|
2008-06-16 22:13:46 +08:00
|
|
|
// All inserted insertvalue instructions are inserted before InsertBefore
|
2011-07-13 18:26:04 +08:00
|
|
|
static Value *BuildSubAggregate(Value *From, ArrayRef<unsigned> idx_range,
|
2009-08-07 09:32:21 +08:00
|
|
|
Instruction *InsertBefore) {
|
2008-06-16 21:28:31 +08:00
|
|
|
assert(InsertBefore && "Must have someplace to insert!");
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *IndexedType = ExtractValueInst::getIndexedType(From->getType(),
|
2011-07-13 18:26:04 +08:00
|
|
|
idx_range);
|
2009-07-31 07:03:37 +08:00
|
|
|
Value *To = UndefValue::get(IndexedType);
|
2011-07-13 18:26:04 +08:00
|
|
|
SmallVector<unsigned, 10> Idxs(idx_range.begin(), idx_range.end());
|
2008-06-16 20:48:21 +08:00
|
|
|
unsigned IdxSkip = Idxs.size();
|
|
|
|
|
2009-11-23 11:29:18 +08:00
|
|
|
return BuildSubAggregate(From, To, IndexedType, Idxs, IdxSkip, InsertBefore);
|
2008-06-16 20:48:21 +08:00
|
|
|
}
|
|
|
|
|
2014-11-05 00:27:42 +08:00
|
|
|
/// Given an aggregrate and an sequence of indices, see if
|
2008-06-16 20:57:37 +08:00
|
|
|
/// the scalar value indexed is already around as a register, for example if it
|
|
|
|
/// were inserted directly into the aggregrate.
|
2008-06-16 22:13:46 +08:00
|
|
|
///
|
|
|
|
/// If InsertBefore is not null, this function will duplicate (modified)
|
|
|
|
/// insertvalues when a part of a nested struct is extracted.
|
2011-07-13 18:26:04 +08:00
|
|
|
Value *llvm::FindInsertedValue(Value *V, ArrayRef<unsigned> idx_range,
|
|
|
|
Instruction *InsertBefore) {
|
2008-06-16 20:48:21 +08:00
|
|
|
// Nothing to index? Just return V then (this is useful at the end of our
|
2012-01-24 15:54:10 +08:00
|
|
|
// recursion).
|
2011-07-13 18:26:04 +08:00
|
|
|
if (idx_range.empty())
|
2008-06-16 20:48:21 +08:00
|
|
|
return V;
|
2012-01-24 15:54:10 +08:00
|
|
|
// We have indices, so V should have an indexable type.
|
|
|
|
assert((V->getType()->isStructTy() || V->getType()->isArrayTy()) &&
|
|
|
|
"Not looking at a struct or array?");
|
|
|
|
assert(ExtractValueInst::getIndexedType(V->getType(), idx_range) &&
|
|
|
|
"Invalid indices for type?");
|
2012-01-25 14:48:06 +08:00
|
|
|
|
|
|
|
if (Constant *C = dyn_cast<Constant>(V)) {
|
|
|
|
C = C->getAggregateElement(idx_range[0]);
|
2014-04-15 12:59:12 +08:00
|
|
|
if (!C) return nullptr;
|
2012-01-25 14:48:06 +08:00
|
|
|
return FindInsertedValue(C, idx_range.slice(1), InsertBefore);
|
|
|
|
}
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2012-01-24 15:54:10 +08:00
|
|
|
if (InsertValueInst *I = dyn_cast<InsertValueInst>(V)) {
|
2008-06-16 20:48:21 +08:00
|
|
|
// Loop the indices for the insertvalue instruction in parallel with the
|
|
|
|
// requested indices
|
2011-07-13 18:26:04 +08:00
|
|
|
const unsigned *req_idx = idx_range.begin();
|
2008-06-16 20:57:37 +08:00
|
|
|
for (const unsigned *i = I->idx_begin(), *e = I->idx_end();
|
|
|
|
i != e; ++i, ++req_idx) {
|
2011-07-13 18:26:04 +08:00
|
|
|
if (req_idx == idx_range.end()) {
|
2012-01-24 15:54:10 +08:00
|
|
|
// We can't handle this without inserting insertvalues
|
|
|
|
if (!InsertBefore)
|
2014-04-15 12:59:12 +08:00
|
|
|
return nullptr;
|
2012-01-24 15:54:10 +08:00
|
|
|
|
|
|
|
// The requested index identifies a part of a nested aggregate. Handle
|
|
|
|
// this specially. For example,
|
|
|
|
// %A = insertvalue { i32, {i32, i32 } } undef, i32 10, 1, 0
|
|
|
|
// %B = insertvalue { i32, {i32, i32 } } %A, i32 11, 1, 1
|
|
|
|
// %C = extractvalue {i32, { i32, i32 } } %B, 1
|
|
|
|
// This can be changed into
|
|
|
|
// %A = insertvalue {i32, i32 } undef, i32 10, 0
|
|
|
|
// %C = insertvalue {i32, i32 } %A, i32 11, 1
|
|
|
|
// which allows the unused 0,0 element from the nested struct to be
|
|
|
|
// removed.
|
|
|
|
return BuildSubAggregate(V, makeArrayRef(idx_range.begin(), req_idx),
|
|
|
|
InsertBefore);
|
2008-06-19 16:47:31 +08:00
|
|
|
}
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-16 20:48:21 +08:00
|
|
|
// This insert value inserts something else than what we are looking for.
|
|
|
|
// See if the (aggregrate) value inserted into has the value we are
|
|
|
|
// looking for, then.
|
|
|
|
if (*req_idx != *i)
|
2011-07-13 18:26:04 +08:00
|
|
|
return FindInsertedValue(I->getAggregateOperand(), idx_range,
|
2009-11-23 11:29:18 +08:00
|
|
|
InsertBefore);
|
2008-06-16 20:48:21 +08:00
|
|
|
}
|
|
|
|
// If we end up here, the indices of the insertvalue match with those
|
|
|
|
// requested (though possibly only partially). Now we recursively look at
|
|
|
|
// the inserted value, passing any remaining indices.
|
2011-07-13 18:26:04 +08:00
|
|
|
return FindInsertedValue(I->getInsertedValueOperand(),
|
2011-07-18 20:00:32 +08:00
|
|
|
makeArrayRef(req_idx, idx_range.end()),
|
2009-11-23 11:29:18 +08:00
|
|
|
InsertBefore);
|
2012-01-24 15:54:10 +08:00
|
|
|
}
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2012-01-24 15:54:10 +08:00
|
|
|
if (ExtractValueInst *I = dyn_cast<ExtractValueInst>(V)) {
|
2008-06-16 20:48:21 +08:00
|
|
|
// If we're extracting a value from an aggregrate that was extracted from
|
|
|
|
// something else, we can extract from that something else directly instead.
|
|
|
|
// However, we will need to chain I's indices with the requested indices.
|
2012-12-23 03:15:35 +08:00
|
|
|
|
|
|
|
// Calculate the number of indices required
|
2011-07-13 18:26:04 +08:00
|
|
|
unsigned size = I->getNumIndices() + idx_range.size();
|
2008-06-16 20:48:21 +08:00
|
|
|
// Allocate some space to put the new indices in
|
2008-06-17 16:24:37 +08:00
|
|
|
SmallVector<unsigned, 5> Idxs;
|
|
|
|
Idxs.reserve(size);
|
2008-06-16 20:48:21 +08:00
|
|
|
// Add indices from the extract value instruction
|
2011-07-13 18:26:04 +08:00
|
|
|
Idxs.append(I->idx_begin(), I->idx_end());
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-16 20:48:21 +08:00
|
|
|
// Add requested indices
|
2011-07-13 18:26:04 +08:00
|
|
|
Idxs.append(idx_range.begin(), idx_range.end());
|
2008-06-16 20:48:21 +08:00
|
|
|
|
2012-12-23 03:15:35 +08:00
|
|
|
assert(Idxs.size() == size
|
2008-06-16 20:57:37 +08:00
|
|
|
&& "Number of indices added not correct?");
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2011-07-13 18:26:04 +08:00
|
|
|
return FindInsertedValue(I->getAggregateOperand(), Idxs, InsertBefore);
|
2008-06-16 20:48:21 +08:00
|
|
|
}
|
|
|
|
// Otherwise, we don't know (such as, extracting from a function return value
|
|
|
|
// or load instruction)
|
2014-04-15 12:59:12 +08:00
|
|
|
return nullptr;
|
2008-06-16 20:48:21 +08:00
|
|
|
}
|
2008-06-30 15:31:25 +08:00
|
|
|
|
2014-11-05 00:27:42 +08:00
|
|
|
/// Analyze the specified pointer to see if it can be expressed as a base
|
|
|
|
/// pointer plus a constant offset. Return the base and offset to the caller.
|
2010-12-01 06:25:26 +08:00
|
|
|
Value *llvm::GetPointerBaseWithConstantOffset(Value *Ptr, int64_t &Offset,
|
2013-08-11 01:34:08 +08:00
|
|
|
const DataLayout *DL) {
|
2013-01-31 10:00:45 +08:00
|
|
|
// Without DataLayout, conservatively assume 64-bit offsets, which is
|
|
|
|
// the widest we support.
|
2013-08-11 01:34:08 +08:00
|
|
|
unsigned BitWidth = DL ? DL->getPointerTypeSizeInBits(Ptr->getType()) : 64;
|
2013-01-01 04:48:35 +08:00
|
|
|
APInt ByteOffset(BitWidth, 0);
|
|
|
|
while (1) {
|
|
|
|
if (Ptr->getType()->isVectorTy())
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (GEPOperator *GEP = dyn_cast<GEPOperator>(Ptr)) {
|
2013-08-11 01:34:08 +08:00
|
|
|
if (DL) {
|
|
|
|
APInt GEPOffset(BitWidth, 0);
|
|
|
|
if (!GEP->accumulateConstantOffset(*DL, GEPOffset))
|
|
|
|
break;
|
|
|
|
|
|
|
|
ByteOffset += GEPOffset;
|
|
|
|
}
|
|
|
|
|
2013-01-01 04:48:35 +08:00
|
|
|
Ptr = GEP->getPointerOperand();
|
2014-07-15 06:39:22 +08:00
|
|
|
} else if (Operator::getOpcode(Ptr) == Instruction::BitCast ||
|
|
|
|
Operator::getOpcode(Ptr) == Instruction::AddrSpaceCast) {
|
2013-01-01 04:48:35 +08:00
|
|
|
Ptr = cast<Operator>(Ptr)->getOperand(0);
|
|
|
|
} else if (GlobalAlias *GA = dyn_cast<GlobalAlias>(Ptr)) {
|
|
|
|
if (GA->mayBeOverridden())
|
|
|
|
break;
|
|
|
|
Ptr = GA->getAliasee();
|
2010-12-01 06:25:26 +08:00
|
|
|
} else {
|
2013-01-01 04:48:35 +08:00
|
|
|
break;
|
2010-12-01 06:25:26 +08:00
|
|
|
}
|
|
|
|
}
|
2013-01-01 04:48:35 +08:00
|
|
|
Offset = ByteOffset.getSExtValue();
|
|
|
|
return Ptr;
|
2010-12-01 06:25:26 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-11-05 00:27:42 +08:00
|
|
|
/// This function computes the length of a null-terminated C string pointed to
|
|
|
|
/// by V. If successful, it returns true and returns the string in Str.
|
|
|
|
/// If unsuccessful, it returns false.
|
2012-02-05 10:29:43 +08:00
|
|
|
bool llvm::getConstantStringInfo(const Value *V, StringRef &Str,
|
|
|
|
uint64_t Offset, bool TrimAtNul) {
|
|
|
|
assert(V);
|
|
|
|
|
|
|
|
// Look through bitcast instructions and geps.
|
|
|
|
V = V->stripPointerCasts();
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2012-02-05 10:29:43 +08:00
|
|
|
// If the value is a GEP instructionor constant expression, treat it as an
|
|
|
|
// offset.
|
|
|
|
if (const GEPOperator *GEP = dyn_cast<GEPOperator>(V)) {
|
2008-06-30 15:31:25 +08:00
|
|
|
// Make sure the GEP has exactly three arguments.
|
2009-03-13 12:39:26 +08:00
|
|
|
if (GEP->getNumOperands() != 3)
|
|
|
|
return false;
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-30 15:31:25 +08:00
|
|
|
// Make sure the index-ee is a pointer to array of i8.
|
2011-07-18 12:54:35 +08:00
|
|
|
PointerType *PT = cast<PointerType>(GEP->getOperand(0)->getType());
|
|
|
|
ArrayType *AT = dyn_cast<ArrayType>(PT->getElementType());
|
2014-04-15 12:59:12 +08:00
|
|
|
if (!AT || !AT->getElementType()->isIntegerTy(8))
|
2009-03-13 12:39:26 +08:00
|
|
|
return false;
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-30 15:31:25 +08:00
|
|
|
// Check to make sure that the first operand of the GEP is an integer and
|
|
|
|
// has value 0 so that we are sure we're indexing into the initializer.
|
2010-04-15 06:20:45 +08:00
|
|
|
const ConstantInt *FirstIdx = dyn_cast<ConstantInt>(GEP->getOperand(1));
|
2014-04-15 12:59:12 +08:00
|
|
|
if (!FirstIdx || !FirstIdx->isZero())
|
2009-03-13 12:39:26 +08:00
|
|
|
return false;
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-30 15:31:25 +08:00
|
|
|
// If the second index isn't a ConstantInt, then this is a variable index
|
|
|
|
// into the array. If this occurs, we can't say anything meaningful about
|
|
|
|
// the string.
|
|
|
|
uint64_t StartIdx = 0;
|
2010-04-15 06:20:45 +08:00
|
|
|
if (const ConstantInt *CI = dyn_cast<ConstantInt>(GEP->getOperand(2)))
|
2008-06-30 15:31:25 +08:00
|
|
|
StartIdx = CI->getZExtValue();
|
2009-03-13 12:39:26 +08:00
|
|
|
else
|
|
|
|
return false;
|
2012-02-05 10:29:43 +08:00
|
|
|
return getConstantStringInfo(GEP->getOperand(0), Str, StartIdx+Offset);
|
2008-06-30 15:31:25 +08:00
|
|
|
}
|
2011-10-20 08:34:35 +08:00
|
|
|
|
2008-06-30 15:31:25 +08:00
|
|
|
// The GEP instruction, constant or instruction, must reference a global
|
|
|
|
// variable that is a constant and is initialized. The referenced constant
|
|
|
|
// initializer is the array that we'll use for optimization.
|
2012-02-05 10:29:43 +08:00
|
|
|
const GlobalVariable *GV = dyn_cast<GlobalVariable>(V);
|
2009-08-20 02:20:44 +08:00
|
|
|
if (!GV || !GV->isConstant() || !GV->hasDefinitiveInitializer())
|
2009-03-13 12:39:26 +08:00
|
|
|
return false;
|
2012-02-05 10:29:43 +08:00
|
|
|
|
2011-10-20 08:34:35 +08:00
|
|
|
// Handle the all-zeros case
|
2012-02-05 10:29:43 +08:00
|
|
|
if (GV->getInitializer()->isNullValue()) {
|
2008-06-30 15:31:25 +08:00
|
|
|
// This is a degenerate case. The initializer is constant zero so the
|
|
|
|
// length of the string must be zero.
|
2012-02-05 10:29:43 +08:00
|
|
|
Str = "";
|
2009-03-13 12:39:26 +08:00
|
|
|
return true;
|
|
|
|
}
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-30 15:31:25 +08:00
|
|
|
// Must be a Constant Array
|
2012-02-05 10:29:43 +08:00
|
|
|
const ConstantDataArray *Array =
|
|
|
|
dyn_cast<ConstantDataArray>(GV->getInitializer());
|
2014-04-15 12:59:12 +08:00
|
|
|
if (!Array || !Array->isString())
|
2009-03-13 12:39:26 +08:00
|
|
|
return false;
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2008-06-30 15:31:25 +08:00
|
|
|
// Get the number of elements in the array
|
2012-02-05 10:29:43 +08:00
|
|
|
uint64_t NumElts = Array->getType()->getArrayNumElements();
|
|
|
|
|
|
|
|
// Start out with the entire array in the StringRef.
|
|
|
|
Str = Array->getAsString();
|
|
|
|
|
2009-03-13 12:39:26 +08:00
|
|
|
if (Offset > NumElts)
|
|
|
|
return false;
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2012-02-05 10:29:43 +08:00
|
|
|
// Skip over 'offset' bytes.
|
|
|
|
Str = Str.substr(Offset);
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2012-02-05 10:29:43 +08:00
|
|
|
if (TrimAtNul) {
|
|
|
|
// Trim off the \0 and anything after it. If the array is not nul
|
|
|
|
// terminated, we just return the whole end of string. The client may know
|
|
|
|
// some other way that the string is length-bound.
|
|
|
|
Str = Str.substr(0, Str.find('\0'));
|
|
|
|
}
|
2009-03-13 12:39:26 +08:00
|
|
|
return true;
|
2008-06-30 15:31:25 +08:00
|
|
|
}
|
2010-03-05 14:58:57 +08:00
|
|
|
|
|
|
|
// These next two are very similar to the above, but also look through PHI
|
|
|
|
// nodes.
|
|
|
|
// TODO: See if we can integrate these two together.
|
|
|
|
|
2014-11-05 00:27:42 +08:00
|
|
|
/// If we can compute the length of the string pointed to by
|
2010-03-05 14:58:57 +08:00
|
|
|
/// the specified pointer, return 'len+1'. If we can't, return 0.
|
2014-08-21 13:55:13 +08:00
|
|
|
static uint64_t GetStringLengthH(Value *V, SmallPtrSetImpl<PHINode*> &PHIs) {
|
2010-03-05 14:58:57 +08:00
|
|
|
// Look through noop bitcast instructions.
|
2012-02-05 10:29:43 +08:00
|
|
|
V = V->stripPointerCasts();
|
2010-03-05 14:58:57 +08:00
|
|
|
|
|
|
|
// If this is a PHI node, there are two cases: either we have already seen it
|
|
|
|
// or we haven't.
|
|
|
|
if (PHINode *PN = dyn_cast<PHINode>(V)) {
|
2014-11-19 15:49:26 +08:00
|
|
|
if (!PHIs.insert(PN).second)
|
2010-03-05 14:58:57 +08:00
|
|
|
return ~0ULL; // already in the set.
|
|
|
|
|
|
|
|
// If it was new, see if all the input strings are the same length.
|
|
|
|
uint64_t LenSoFar = ~0ULL;
|
|
|
|
for (unsigned i = 0, e = PN->getNumIncomingValues(); i != e; ++i) {
|
|
|
|
uint64_t Len = GetStringLengthH(PN->getIncomingValue(i), PHIs);
|
|
|
|
if (Len == 0) return 0; // Unknown length -> unknown.
|
|
|
|
|
|
|
|
if (Len == ~0ULL) continue;
|
|
|
|
|
|
|
|
if (Len != LenSoFar && LenSoFar != ~0ULL)
|
|
|
|
return 0; // Disagree -> unknown.
|
|
|
|
LenSoFar = Len;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Success, all agree.
|
|
|
|
return LenSoFar;
|
|
|
|
}
|
|
|
|
|
|
|
|
// strlen(select(c,x,y)) -> strlen(x) ^ strlen(y)
|
|
|
|
if (SelectInst *SI = dyn_cast<SelectInst>(V)) {
|
|
|
|
uint64_t Len1 = GetStringLengthH(SI->getTrueValue(), PHIs);
|
|
|
|
if (Len1 == 0) return 0;
|
|
|
|
uint64_t Len2 = GetStringLengthH(SI->getFalseValue(), PHIs);
|
|
|
|
if (Len2 == 0) return 0;
|
|
|
|
if (Len1 == ~0ULL) return Len2;
|
|
|
|
if (Len2 == ~0ULL) return Len1;
|
|
|
|
if (Len1 != Len2) return 0;
|
|
|
|
return Len1;
|
|
|
|
}
|
2012-12-23 03:15:35 +08:00
|
|
|
|
2012-02-05 10:29:43 +08:00
|
|
|
// Otherwise, see if we can read the string.
|
|
|
|
StringRef StrData;
|
|
|
|
if (!getConstantStringInfo(V, StrData))
|
2012-02-01 12:51:17 +08:00
|
|
|
return 0;
|
2010-03-05 14:58:57 +08:00
|
|
|
|
2012-02-05 10:29:43 +08:00
|
|
|
return StrData.size()+1;
|
2010-03-05 14:58:57 +08:00
|
|
|
}
|
|
|
|
|
2014-11-05 00:27:42 +08:00
|
|
|
/// If we can compute the length of the string pointed to by
|
2010-03-05 14:58:57 +08:00
|
|
|
/// the specified pointer, return 'len+1'. If we can't, return 0.
|
|
|
|
uint64_t llvm::GetStringLength(Value *V) {
|
|
|
|
if (!V->getType()->isPointerTy()) return 0;
|
|
|
|
|
|
|
|
SmallPtrSet<PHINode*, 32> PHIs;
|
|
|
|
uint64_t Len = GetStringLengthH(V, PHIs);
|
|
|
|
// If Len is ~0ULL, we had an infinite phi cycle: this is dead code, so return
|
|
|
|
// an empty string as a length.
|
|
|
|
return Len == ~0ULL ? 1 : Len;
|
|
|
|
}
|
2010-12-16 04:02:24 +08:00
|
|
|
|
2011-01-25 02:53:32 +08:00
|
|
|
Value *
|
2012-10-09 00:38:25 +08:00
|
|
|
llvm::GetUnderlyingObject(Value *V, const DataLayout *TD, unsigned MaxLookup) {
|
2010-12-16 04:02:24 +08:00
|
|
|
if (!V->getType()->isPointerTy())
|
|
|
|
return V;
|
|
|
|
for (unsigned Count = 0; MaxLookup == 0 || Count < MaxLookup; ++Count) {
|
|
|
|
if (GEPOperator *GEP = dyn_cast<GEPOperator>(V)) {
|
|
|
|
V = GEP->getPointerOperand();
|
2014-07-15 08:56:40 +08:00
|
|
|
} else if (Operator::getOpcode(V) == Instruction::BitCast ||
|
|
|
|
Operator::getOpcode(V) == Instruction::AddrSpaceCast) {
|
2010-12-16 04:02:24 +08:00
|
|
|
V = cast<Operator>(V)->getOperand(0);
|
|
|
|
} else if (GlobalAlias *GA = dyn_cast<GlobalAlias>(V)) {
|
|
|
|
if (GA->mayBeOverridden())
|
|
|
|
return V;
|
|
|
|
V = GA->getAliasee();
|
|
|
|
} else {
|
2010-12-16 04:49:55 +08:00
|
|
|
// See if InstructionSimplify knows any relevant tricks.
|
|
|
|
if (Instruction *I = dyn_cast<Instruction>(V))
|
2015-01-04 20:03:27 +08:00
|
|
|
// TODO: Acquire a DominatorTree and AssumptionCache and use them.
|
2014-04-15 12:59:12 +08:00
|
|
|
if (Value *Simplified = SimplifyInstruction(I, TD, nullptr)) {
|
2010-12-16 04:49:55 +08:00
|
|
|
V = Simplified;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2010-12-16 04:02:24 +08:00
|
|
|
return V;
|
|
|
|
}
|
|
|
|
assert(V->getType()->isPointerTy() && "Unexpected operand type!");
|
|
|
|
}
|
|
|
|
return V;
|
|
|
|
}
|
2011-06-27 12:20:45 +08:00
|
|
|
|
2012-05-11 02:57:38 +08:00
|
|
|
void
|
|
|
|
llvm::GetUnderlyingObjects(Value *V,
|
|
|
|
SmallVectorImpl<Value *> &Objects,
|
2012-10-09 00:38:25 +08:00
|
|
|
const DataLayout *TD,
|
2012-05-11 02:57:38 +08:00
|
|
|
unsigned MaxLookup) {
|
|
|
|
SmallPtrSet<Value *, 4> Visited;
|
|
|
|
SmallVector<Value *, 4> Worklist;
|
|
|
|
Worklist.push_back(V);
|
|
|
|
do {
|
|
|
|
Value *P = Worklist.pop_back_val();
|
|
|
|
P = GetUnderlyingObject(P, TD, MaxLookup);
|
|
|
|
|
2014-11-19 15:49:26 +08:00
|
|
|
if (!Visited.insert(P).second)
|
2012-05-11 02:57:38 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
if (SelectInst *SI = dyn_cast<SelectInst>(P)) {
|
|
|
|
Worklist.push_back(SI->getTrueValue());
|
|
|
|
Worklist.push_back(SI->getFalseValue());
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (PHINode *PN = dyn_cast<PHINode>(P)) {
|
|
|
|
for (unsigned i = 0, e = PN->getNumIncomingValues(); i != e; ++i)
|
|
|
|
Worklist.push_back(PN->getIncomingValue(i));
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
Objects.push_back(P);
|
|
|
|
} while (!Worklist.empty());
|
|
|
|
}
|
|
|
|
|
2014-11-05 00:27:42 +08:00
|
|
|
/// Return true if the only users of this pointer are lifetime markers.
|
2011-06-27 12:20:45 +08:00
|
|
|
bool llvm::onlyUsedByLifetimeMarkers(const Value *V) {
|
2014-03-09 11:16:01 +08:00
|
|
|
for (const User *U : V->users()) {
|
|
|
|
const IntrinsicInst *II = dyn_cast<IntrinsicInst>(U);
|
2011-06-27 12:20:45 +08:00
|
|
|
if (!II) return false;
|
|
|
|
|
|
|
|
if (II->getIntrinsicID() != Intrinsic::lifetime_start &&
|
|
|
|
II->getIntrinsicID() != Intrinsic::lifetime_end)
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
2011-12-15 07:49:11 +08:00
|
|
|
|
2012-01-05 07:01:09 +08:00
|
|
|
bool llvm::isSafeToSpeculativelyExecute(const Value *V,
|
2012-10-09 00:38:25 +08:00
|
|
|
const DataLayout *TD) {
|
2012-01-05 07:01:09 +08:00
|
|
|
const Operator *Inst = dyn_cast<Operator>(V);
|
|
|
|
if (!Inst)
|
|
|
|
return false;
|
|
|
|
|
2011-12-15 07:49:11 +08:00
|
|
|
for (unsigned i = 0, e = Inst->getNumOperands(); i != e; ++i)
|
|
|
|
if (Constant *C = dyn_cast<Constant>(Inst->getOperand(i)))
|
|
|
|
if (C->canTrap())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
switch (Inst->getOpcode()) {
|
|
|
|
default:
|
|
|
|
return true;
|
|
|
|
case Instruction::UDiv:
|
2014-11-05 07:49:08 +08:00
|
|
|
case Instruction::URem: {
|
|
|
|
// x / y is undefined if y == 0.
|
|
|
|
const APInt *V;
|
|
|
|
if (match(Inst->getOperand(1), m_APInt(V)))
|
|
|
|
return *V != 0;
|
|
|
|
return false;
|
|
|
|
}
|
2011-12-15 07:49:11 +08:00
|
|
|
case Instruction::SDiv:
|
|
|
|
case Instruction::SRem: {
|
2014-11-05 07:49:08 +08:00
|
|
|
// x / y is undefined if y == 0 or x == INT_MIN and y == -1
|
2015-02-02 03:10:19 +08:00
|
|
|
const APInt *Numerator, *Denominator;
|
|
|
|
if (!match(Inst->getOperand(1), m_APInt(Denominator)))
|
|
|
|
return false;
|
|
|
|
// We cannot hoist this division if the denominator is 0.
|
|
|
|
if (*Denominator == 0)
|
|
|
|
return false;
|
|
|
|
// It's safe to hoist if the denominator is not 0 or -1.
|
|
|
|
if (*Denominator != -1)
|
|
|
|
return true;
|
|
|
|
// At this point we know that the denominator is -1. It is safe to hoist as
|
|
|
|
// long we know that the numerator is not INT_MIN.
|
|
|
|
if (match(Inst->getOperand(0), m_APInt(Numerator)))
|
|
|
|
return !Numerator->isMinSignedValue();
|
|
|
|
// The numerator *might* be MinSignedValue.
|
2014-11-05 07:49:08 +08:00
|
|
|
return false;
|
2011-12-15 07:49:11 +08:00
|
|
|
}
|
|
|
|
case Instruction::Load: {
|
|
|
|
const LoadInst *LI = cast<LoadInst>(Inst);
|
2013-11-21 15:29:28 +08:00
|
|
|
if (!LI->isUnordered() ||
|
|
|
|
// Speculative load may create a race that did not exist in the source.
|
|
|
|
LI->getParent()->getParent()->hasFnAttribute(Attribute::SanitizeThread))
|
2011-12-15 07:49:11 +08:00
|
|
|
return false;
|
2014-07-10 13:27:53 +08:00
|
|
|
return LI->getPointerOperand()->isDereferenceablePointer(TD);
|
2011-12-15 07:49:11 +08:00
|
|
|
}
|
2011-12-21 13:52:02 +08:00
|
|
|
case Instruction::Call: {
|
2014-11-07 03:05:57 +08:00
|
|
|
if (const IntrinsicInst *II = dyn_cast<IntrinsicInst>(Inst)) {
|
|
|
|
switch (II->getIntrinsicID()) {
|
|
|
|
// These synthetic intrinsics have no side-effects and just mark
|
|
|
|
// information about their operands.
|
|
|
|
// FIXME: There are other no-op synthetic instructions that potentially
|
|
|
|
// should be considered at least *safe* to speculate...
|
|
|
|
case Intrinsic::dbg_declare:
|
|
|
|
case Intrinsic::dbg_value:
|
|
|
|
return true;
|
|
|
|
|
|
|
|
case Intrinsic::bswap:
|
|
|
|
case Intrinsic::ctlz:
|
|
|
|
case Intrinsic::ctpop:
|
|
|
|
case Intrinsic::cttz:
|
|
|
|
case Intrinsic::objectsize:
|
|
|
|
case Intrinsic::sadd_with_overflow:
|
|
|
|
case Intrinsic::smul_with_overflow:
|
|
|
|
case Intrinsic::ssub_with_overflow:
|
|
|
|
case Intrinsic::uadd_with_overflow:
|
|
|
|
case Intrinsic::umul_with_overflow:
|
|
|
|
case Intrinsic::usub_with_overflow:
|
|
|
|
return true;
|
|
|
|
// Sqrt should be OK, since the llvm sqrt intrinsic isn't defined to set
|
|
|
|
// errno like libm sqrt would.
|
|
|
|
case Intrinsic::sqrt:
|
|
|
|
case Intrinsic::fma:
|
|
|
|
case Intrinsic::fmuladd:
|
|
|
|
case Intrinsic::fabs:
|
|
|
|
case Intrinsic::minnum:
|
|
|
|
case Intrinsic::maxnum:
|
|
|
|
return true;
|
|
|
|
// TODO: some fp intrinsics are marked as having the same error handling
|
|
|
|
// as libm. They're safe to speculate when they won't error.
|
|
|
|
// TODO: are convert_{from,to}_fp16 safe?
|
|
|
|
// TODO: can we list target-specific intrinsics here?
|
|
|
|
default: break;
|
|
|
|
}
|
|
|
|
}
|
2011-12-15 07:49:11 +08:00
|
|
|
return false; // The called function could have undefined behavior or
|
2011-12-21 13:52:02 +08:00
|
|
|
// side-effects, even if marked readnone nounwind.
|
|
|
|
}
|
2011-12-15 07:49:11 +08:00
|
|
|
case Instruction::VAArg:
|
|
|
|
case Instruction::Alloca:
|
|
|
|
case Instruction::Invoke:
|
|
|
|
case Instruction::PHI:
|
|
|
|
case Instruction::Store:
|
|
|
|
case Instruction::Ret:
|
|
|
|
case Instruction::Br:
|
|
|
|
case Instruction::IndirectBr:
|
|
|
|
case Instruction::Switch:
|
|
|
|
case Instruction::Unreachable:
|
|
|
|
case Instruction::Fence:
|
|
|
|
case Instruction::LandingPad:
|
|
|
|
case Instruction::AtomicRMW:
|
|
|
|
case Instruction::AtomicCmpXchg:
|
|
|
|
case Instruction::Resume:
|
|
|
|
return false; // Misc instructions which have effects
|
|
|
|
}
|
|
|
|
}
|
2013-01-31 10:40:59 +08:00
|
|
|
|
2014-11-05 00:27:42 +08:00
|
|
|
/// Return true if we know that the specified value is never null.
|
2013-09-25 00:37:51 +08:00
|
|
|
bool llvm::isKnownNonNull(const Value *V, const TargetLibraryInfo *TLI) {
|
2013-01-31 10:40:59 +08:00
|
|
|
// Alloca never returns null, malloc might.
|
|
|
|
if (isa<AllocaInst>(V)) return true;
|
|
|
|
|
2014-05-20 09:23:40 +08:00
|
|
|
// A byval, inalloca, or nonnull argument is never null.
|
2013-01-31 10:40:59 +08:00
|
|
|
if (const Argument *A = dyn_cast<Argument>(V))
|
2014-05-20 09:23:40 +08:00
|
|
|
return A->hasByValOrInAllocaAttr() || A->hasNonNullAttr();
|
2013-01-31 10:40:59 +08:00
|
|
|
|
|
|
|
// Global values are not null unless extern weak.
|
|
|
|
if (const GlobalValue *GV = dyn_cast<GlobalValue>(V))
|
|
|
|
return !GV->hasExternalWeakLinkage();
|
2013-09-25 00:37:51 +08:00
|
|
|
|
2014-10-21 06:40:55 +08:00
|
|
|
// A Load tagged w/nonnull metadata is never null.
|
|
|
|
if (const LoadInst *LI = dyn_cast<LoadInst>(V))
|
2014-10-21 08:13:20 +08:00
|
|
|
return LI->getMetadata(LLVMContext::MD_nonnull);
|
2014-10-21 06:40:55 +08:00
|
|
|
|
2014-05-20 13:13:21 +08:00
|
|
|
if (ImmutableCallSite CS = V)
|
2014-07-18 23:51:28 +08:00
|
|
|
if (CS.isReturnNonNull())
|
2014-05-20 13:13:21 +08:00
|
|
|
return true;
|
|
|
|
|
2013-09-25 00:37:51 +08:00
|
|
|
// operator new never returns null.
|
|
|
|
if (isOperatorNewLikeFn(V, TLI, /*LookThroughBitCast=*/true))
|
|
|
|
return true;
|
|
|
|
|
2013-01-31 10:40:59 +08:00
|
|
|
return false;
|
|
|
|
}
|
2015-01-02 15:29:43 +08:00
|
|
|
|
|
|
|
OverflowResult llvm::computeOverflowForUnsignedMul(Value *LHS, Value *RHS,
|
|
|
|
const DataLayout *DL,
|
2015-01-04 20:03:27 +08:00
|
|
|
AssumptionCache *AC,
|
2015-01-02 15:29:43 +08:00
|
|
|
const Instruction *CxtI,
|
|
|
|
const DominatorTree *DT) {
|
|
|
|
// Multiplying n * m significant bits yields a result of n + m significant
|
|
|
|
// bits. If the total number of significant bits does not exceed the
|
|
|
|
// result bit width (minus 1), there is no overflow.
|
|
|
|
// This means if we have enough leading zero bits in the operands
|
|
|
|
// we can guarantee that the result does not overflow.
|
|
|
|
// Ref: "Hacker's Delight" by Henry Warren
|
|
|
|
unsigned BitWidth = LHS->getType()->getScalarSizeInBits();
|
|
|
|
APInt LHSKnownZero(BitWidth, 0);
|
2015-01-02 15:29:47 +08:00
|
|
|
APInt LHSKnownOne(BitWidth, 0);
|
2015-01-02 15:29:43 +08:00
|
|
|
APInt RHSKnownZero(BitWidth, 0);
|
2015-01-02 15:29:47 +08:00
|
|
|
APInt RHSKnownOne(BitWidth, 0);
|
2015-01-04 20:03:27 +08:00
|
|
|
computeKnownBits(LHS, LHSKnownZero, LHSKnownOne, DL, /*Depth=*/0, AC, CxtI,
|
|
|
|
DT);
|
|
|
|
computeKnownBits(RHS, RHSKnownZero, RHSKnownOne, DL, /*Depth=*/0, AC, CxtI,
|
|
|
|
DT);
|
2015-01-02 15:29:43 +08:00
|
|
|
// Note that underestimating the number of zero bits gives a more
|
|
|
|
// conservative answer.
|
|
|
|
unsigned ZeroBits = LHSKnownZero.countLeadingOnes() +
|
|
|
|
RHSKnownZero.countLeadingOnes();
|
|
|
|
// First handle the easy case: if we have enough zero bits there's
|
|
|
|
// definitely no overflow.
|
|
|
|
if (ZeroBits >= BitWidth)
|
|
|
|
return OverflowResult::NeverOverflows;
|
|
|
|
|
|
|
|
// Get the largest possible values for each operand.
|
|
|
|
APInt LHSMax = ~LHSKnownZero;
|
|
|
|
APInt RHSMax = ~RHSKnownZero;
|
|
|
|
|
|
|
|
// We know the multiply operation doesn't overflow if the maximum values for
|
|
|
|
// each operand will not overflow after we multiply them together.
|
2015-01-02 15:29:47 +08:00
|
|
|
bool MaxOverflow;
|
|
|
|
LHSMax.umul_ov(RHSMax, MaxOverflow);
|
|
|
|
if (!MaxOverflow)
|
|
|
|
return OverflowResult::NeverOverflows;
|
|
|
|
|
|
|
|
// We know it always overflows if multiplying the smallest possible values for
|
|
|
|
// the operands also results in overflow.
|
|
|
|
bool MinOverflow;
|
|
|
|
LHSKnownOne.umul_ov(RHSKnownOne, MinOverflow);
|
|
|
|
if (MinOverflow)
|
|
|
|
return OverflowResult::AlwaysOverflows;
|
2015-01-02 15:29:43 +08:00
|
|
|
|
2015-01-02 15:29:47 +08:00
|
|
|
return OverflowResult::MayOverflow;
|
2015-01-02 15:29:43 +08:00
|
|
|
}
|
2015-01-07 08:39:50 +08:00
|
|
|
|
|
|
|
OverflowResult llvm::computeOverflowForUnsignedAdd(Value *LHS, Value *RHS,
|
|
|
|
const DataLayout *DL,
|
|
|
|
AssumptionCache *AC,
|
|
|
|
const Instruction *CxtI,
|
|
|
|
const DominatorTree *DT) {
|
|
|
|
bool LHSKnownNonNegative, LHSKnownNegative;
|
|
|
|
ComputeSignBit(LHS, LHSKnownNonNegative, LHSKnownNegative, DL, /*Depth=*/0,
|
|
|
|
AC, CxtI, DT);
|
|
|
|
if (LHSKnownNonNegative || LHSKnownNegative) {
|
|
|
|
bool RHSKnownNonNegative, RHSKnownNegative;
|
|
|
|
ComputeSignBit(RHS, RHSKnownNonNegative, RHSKnownNegative, DL, /*Depth=*/0,
|
|
|
|
AC, CxtI, DT);
|
|
|
|
|
|
|
|
if (LHSKnownNegative && RHSKnownNegative) {
|
|
|
|
// The sign bit is set in both cases: this MUST overflow.
|
|
|
|
// Create a simple add instruction, and insert it into the struct.
|
|
|
|
return OverflowResult::AlwaysOverflows;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (LHSKnownNonNegative && RHSKnownNonNegative) {
|
|
|
|
// The sign bit is clear in both cases: this CANNOT overflow.
|
|
|
|
// Create a simple add instruction, and insert it into the struct.
|
|
|
|
return OverflowResult::NeverOverflows;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return OverflowResult::MayOverflow;
|
|
|
|
}
|