2008-06-02 03:18:21 +02:00
|
|
|
//===- ValueTracking.cpp - Walk computations to compute properties --------===//
|
|
|
|
//
|
2019-01-19 09:50:56 +01:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2008-06-02 03:18:21 +02:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file contains routines that help analyze properties that chains of
|
|
|
|
// computations have.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "llvm/Analysis/ValueTracking.h"
|
2017-09-01 23:37:29 +02:00
|
|
|
#include "llvm/ADT/APFloat.h"
|
|
|
|
#include "llvm/ADT/APInt.h"
|
|
|
|
#include "llvm/ADT/ArrayRef.h"
|
|
|
|
#include "llvm/ADT/None.h"
|
2015-10-26 15:10:46 +01:00
|
|
|
#include "llvm/ADT/Optional.h"
|
2017-09-01 23:37:29 +02:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2012-12-03 17:50:05 +01:00
|
|
|
#include "llvm/ADT/SmallPtrSet.h"
|
2017-09-01 23:37:29 +02:00
|
|
|
#include "llvm/ADT/SmallSet.h"
|
|
|
|
#include "llvm/ADT/SmallVector.h"
|
|
|
|
#include "llvm/ADT/StringRef.h"
|
|
|
|
#include "llvm/ADT/iterator_range.h"
|
|
|
|
#include "llvm/Analysis/AliasAnalysis.h"
|
2016-12-19 09:22:17 +01:00
|
|
|
#include "llvm/Analysis/AssumptionCache.h"
|
2018-08-30 05:39:16 +02:00
|
|
|
#include "llvm/Analysis/GuardUtils.h"
|
2010-12-15 21:10:26 +01:00
|
|
|
#include "llvm/Analysis/InstructionSimplify.h"
|
2016-02-24 13:49:04 +01:00
|
|
|
#include "llvm/Analysis/Loads.h"
|
2015-04-23 22:09:20 +02:00
|
|
|
#include "llvm/Analysis/LoopInfo.h"
|
2017-10-10 01:19:02 +02:00
|
|
|
#include "llvm/Analysis/OptimizationRemarkEmitter.h"
|
2017-09-01 23:37:29 +02:00
|
|
|
#include "llvm/Analysis/TargetLibraryInfo.h"
|
|
|
|
#include "llvm/IR/Argument.h"
|
|
|
|
#include "llvm/IR/Attributes.h"
|
|
|
|
#include "llvm/IR/BasicBlock.h"
|
2014-05-20 07:13:21 +02:00
|
|
|
#include "llvm/IR/CallSite.h"
|
2017-09-01 23:37:29 +02:00
|
|
|
#include "llvm/IR/Constant.h"
|
2014-03-04 13:24:34 +01:00
|
|
|
#include "llvm/IR/ConstantRange.h"
|
2013-01-02 12:36:10 +01:00
|
|
|
#include "llvm/IR/Constants.h"
|
|
|
|
#include "llvm/IR/DataLayout.h"
|
2017-05-20 00:37:09 +02:00
|
|
|
#include "llvm/IR/DerivedTypes.h"
|
2017-09-01 23:37:29 +02:00
|
|
|
#include "llvm/IR/DiagnosticInfo.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-07 20:57:58 +02:00
|
|
|
#include "llvm/IR/Dominators.h"
|
2017-09-01 23:37:29 +02:00
|
|
|
#include "llvm/IR/Function.h"
|
2014-03-04 11:40:04 +01:00
|
|
|
#include "llvm/IR/GetElementPtrTypeIterator.h"
|
2013-01-02 12:36:10 +01:00
|
|
|
#include "llvm/IR/GlobalAlias.h"
|
2017-09-01 23:37:29 +02:00
|
|
|
#include "llvm/IR/GlobalValue.h"
|
2013-01-02 12:36:10 +01:00
|
|
|
#include "llvm/IR/GlobalVariable.h"
|
2017-09-01 23:37:29 +02:00
|
|
|
#include "llvm/IR/InstrTypes.h"
|
|
|
|
#include "llvm/IR/Instruction.h"
|
2013-01-02 12:36:10 +01:00
|
|
|
#include "llvm/IR/Instructions.h"
|
|
|
|
#include "llvm/IR/IntrinsicInst.h"
|
2017-09-01 23:37:29 +02:00
|
|
|
#include "llvm/IR/Intrinsics.h"
|
2013-01-02 12:36:10 +01:00
|
|
|
#include "llvm/IR/LLVMContext.h"
|
|
|
|
#include "llvm/IR/Metadata.h"
|
2017-09-01 23:37:29 +02:00
|
|
|
#include "llvm/IR/Module.h"
|
2013-01-02 12:36:10 +01:00
|
|
|
#include "llvm/IR/Operator.h"
|
2014-03-04 12:08:18 +01:00
|
|
|
#include "llvm/IR/PatternMatch.h"
|
2017-09-01 23:37:29 +02:00
|
|
|
#include "llvm/IR/Type.h"
|
|
|
|
#include "llvm/IR/User.h"
|
|
|
|
#include "llvm/IR/Value.h"
|
|
|
|
#include "llvm/Support/Casting.h"
|
|
|
|
#include "llvm/Support/CommandLine.h"
|
|
|
|
#include "llvm/Support/Compiler.h"
|
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
2017-04-26 18:39:58 +02:00
|
|
|
#include "llvm/Support/KnownBits.h"
|
2008-06-02 03:18:21 +02:00
|
|
|
#include "llvm/Support/MathExtras.h"
|
2016-01-28 07:29:33 +01:00
|
|
|
#include <algorithm>
|
|
|
|
#include <array>
|
2017-09-01 23:37:29 +02:00
|
|
|
#include <cassert>
|
|
|
|
#include <cstdint>
|
|
|
|
#include <iterator>
|
2018-07-30 21:41:25 +02:00
|
|
|
#include <utility>
|
2017-09-01 23:37:29 +02:00
|
|
|
|
2008-06-02 03:18:21 +02:00
|
|
|
using namespace llvm;
|
2011-01-25 10:38:29 +01:00
|
|
|
using namespace llvm::PatternMatch;
|
|
|
|
|
|
|
|
const unsigned MaxDepth = 6;
|
|
|
|
|
Infer known bits from dominating conditions
This patch adds limited support in ValueTracking for inferring known bits of a value from conditional expressions which must be true to reach the instruction we're trying to optimize. At this time, the feature is off by default. Once landed, I'm hoping for feedback from others on both profitability and compile time impact.
Forms of conditional value propagation have been tried in LLVM before and have failed due to compile time problems. In an attempt to side step that, this patch only considers conditions where the edge leaving the branch dominates the context instruction. It does not attempt full dataflow. Even with that restriction, it handles many interesting cases:
* Early exits from functions
* Early exits from loops (for context instructions in the loop and after the check)
* Conditions which control entry into loops, including multi-version loops (such as those produced during vectorization, IRCE, loop unswitch, etc..)
Possible applications include optimizing using information provided by constructs such as: preconditions, assumptions, null checks, & range checks.
This patch implements two approaches to the problem that need further benchmarking. Approach 1 is to directly walk the dominator tree looking for interesting conditions. Approach 2 is to inspect other uses of the value being queried for interesting comparisons. From initial benchmarking, it appears that Approach 2 is faster than Approach 1, but this needs to be further validated.
Differential Revision: http://reviews.llvm.org/D7708
llvm-svn: 231879
2015-03-10 23:43:20 +01:00
|
|
|
// Controls the number of uses of the value searched for possible
|
|
|
|
// dominating comparisons.
|
|
|
|
static cl::opt<unsigned> DomConditionsMaxUses("dom-conditions-max-uses",
|
2015-09-29 16:57:52 +02:00
|
|
|
cl::Hidden, cl::init(20));
|
Infer known bits from dominating conditions
This patch adds limited support in ValueTracking for inferring known bits of a value from conditional expressions which must be true to reach the instruction we're trying to optimize. At this time, the feature is off by default. Once landed, I'm hoping for feedback from others on both profitability and compile time impact.
Forms of conditional value propagation have been tried in LLVM before and have failed due to compile time problems. In an attempt to side step that, this patch only considers conditions where the edge leaving the branch dominates the context instruction. It does not attempt full dataflow. Even with that restriction, it handles many interesting cases:
* Early exits from functions
* Early exits from loops (for context instructions in the loop and after the check)
* Conditions which control entry into loops, including multi-version loops (such as those produced during vectorization, IRCE, loop unswitch, etc..)
Possible applications include optimizing using information provided by constructs such as: preconditions, assumptions, null checks, & range checks.
This patch implements two approaches to the problem that need further benchmarking. Approach 1 is to directly walk the dominator tree looking for interesting conditions. Approach 2 is to inspect other uses of the value being queried for interesting comparisons. From initial benchmarking, it appears that Approach 2 is faster than Approach 1, but this needs to be further validated.
Differential Revision: http://reviews.llvm.org/D7708
llvm-svn: 231879
2015-03-10 23:43:20 +01:00
|
|
|
|
2017-05-04 00:25:19 +02:00
|
|
|
/// Returns the bitwidth of the given scalar or pointer type. For vector types,
|
|
|
|
/// returns the element type's bitwidth.
|
2015-03-10 03:37:25 +01:00
|
|
|
static unsigned getBitWidth(Type *Ty, const DataLayout &DL) {
|
2011-01-25 10:38:29 +01:00
|
|
|
if (unsigned BitWidth = Ty->getScalarSizeInBits())
|
|
|
|
return BitWidth;
|
2013-08-10 19:34:08 +02:00
|
|
|
|
2018-02-14 07:58:08 +01:00
|
|
|
return DL.getIndexTypeSizeInBits(Ty);
|
2011-01-25 10:38:29 +01:00
|
|
|
}
|
2008-06-02 03:18:21 +02:00
|
|
|
|
2014-09-12 10:56:53 +02:00
|
|
|
namespace {
|
2017-09-01 23:37:29 +02: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-07 20:57:58 +02: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 {
|
2016-01-15 23:22:04 +01:00
|
|
|
const DataLayout &DL;
|
2016-12-19 09:22:17 +01: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-07 20:57:58 +02:00
|
|
|
const Instruction *CxtI;
|
|
|
|
const DominatorTree *DT;
|
2017-09-01 23:37:29 +02:00
|
|
|
|
2017-02-06 19:26:06 +01:00
|
|
|
// Unlike the other analyses, this may be a nullptr because not all clients
|
|
|
|
// provide it currently.
|
|
|
|
OptimizationRemarkEmitter *ORE;
|
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-07 20:57:58 +02:00
|
|
|
|
2016-01-28 07:29:33 +01:00
|
|
|
/// Set of assumptions that should be excluded from further queries.
|
|
|
|
/// 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
|
2017-05-08 18:22:48 +02:00
|
|
|
/// isKnownNonZero, which calls computeKnownBits and isKnownToBeAPowerOfTwo
|
|
|
|
/// (all of which can call computeKnownBits), and so on.
|
2016-10-15 21:00:04 +02:00
|
|
|
std::array<const Value *, MaxDepth> Excluded;
|
2017-09-01 23:37:29 +02:00
|
|
|
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
/// If true, it is safe to use metadata during simplification.
|
|
|
|
InstrInfoQuery IIQ;
|
|
|
|
|
2017-09-01 23:37:29 +02:00
|
|
|
unsigned NumExcluded = 0;
|
2016-01-28 07:29:33 +01:00
|
|
|
|
2016-12-19 09:22:17 +01:00
|
|
|
Query(const DataLayout &DL, AssumptionCache *AC, const Instruction *CxtI,
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
const DominatorTree *DT, bool UseInstrInfo,
|
|
|
|
OptimizationRemarkEmitter *ORE = nullptr)
|
|
|
|
: DL(DL), AC(AC), CxtI(CxtI), DT(DT), ORE(ORE), IIQ(UseInstrInfo) {}
|
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-07 20:57:58 +02:00
|
|
|
|
|
|
|
Query(const Query &Q, const Value *NewExcl)
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
: DL(Q.DL), AC(Q.AC), CxtI(Q.CxtI), DT(Q.DT), ORE(Q.ORE), IIQ(Q.IIQ),
|
2017-02-06 19:26:06 +01:00
|
|
|
NumExcluded(Q.NumExcluded) {
|
2016-01-28 07:29:33 +01:00
|
|
|
Excluded = Q.Excluded;
|
|
|
|
Excluded[NumExcluded++] = NewExcl;
|
|
|
|
assert(NumExcluded <= Excluded.size());
|
|
|
|
}
|
|
|
|
|
|
|
|
bool isExcluded(const Value *Value) const {
|
|
|
|
if (NumExcluded == 0)
|
|
|
|
return false;
|
|
|
|
auto End = Excluded.begin() + NumExcluded;
|
|
|
|
return std::find(Excluded.begin(), End, Value) != End;
|
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-07 20:57:58 +02:00
|
|
|
}
|
|
|
|
};
|
2017-09-01 23:37:29 +02:00
|
|
|
|
2014-09-12 10:56:53 +02: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-07 20:57:58 +02:00
|
|
|
|
2014-11-04 17:09:50 +01: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-07 20:57:58 +02: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;
|
|
|
|
}
|
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
static void computeKnownBits(const Value *V, KnownBits &Known,
|
2016-01-15 23:22:04 +01:00
|
|
|
unsigned Depth, const Query &Q);
|
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-07 20:57:58 +02:00
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
void llvm::computeKnownBits(const Value *V, KnownBits &Known,
|
2015-03-10 03:37:25 +01:00
|
|
|
const DataLayout &DL, unsigned Depth,
|
2016-12-19 09:22:17 +01:00
|
|
|
AssumptionCache *AC, const Instruction *CxtI,
|
2017-02-06 19:26:06 +01:00
|
|
|
const DominatorTree *DT,
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
OptimizationRemarkEmitter *ORE, bool UseInstrInfo) {
|
2017-04-26 18:39:58 +02:00
|
|
|
::computeKnownBits(V, Known, Depth,
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
Query(DL, AC, safeCxtI(V, CxtI), DT, UseInstrInfo, ORE));
|
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-07 20:57:58 +02:00
|
|
|
}
|
|
|
|
|
2017-05-08 18:22:48 +02:00
|
|
|
static KnownBits computeKnownBits(const Value *V, unsigned Depth,
|
|
|
|
const Query &Q);
|
|
|
|
|
|
|
|
KnownBits llvm::computeKnownBits(const Value *V, const DataLayout &DL,
|
|
|
|
unsigned Depth, AssumptionCache *AC,
|
|
|
|
const Instruction *CxtI,
|
2017-05-24 18:53:03 +02:00
|
|
|
const DominatorTree *DT,
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
OptimizationRemarkEmitter *ORE,
|
|
|
|
bool UseInstrInfo) {
|
|
|
|
return ::computeKnownBits(
|
|
|
|
V, Depth, Query(DL, AC, safeCxtI(V, CxtI), DT, UseInstrInfo, ORE));
|
2017-05-08 18:22:48 +02:00
|
|
|
}
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
bool llvm::haveNoCommonBitsSet(const Value *LHS, const Value *RHS,
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
const DataLayout &DL, AssumptionCache *AC,
|
|
|
|
const Instruction *CxtI, const DominatorTree *DT,
|
|
|
|
bool UseInstrInfo) {
|
2015-05-15 01:53:19 +02:00
|
|
|
assert(LHS->getType() == RHS->getType() &&
|
|
|
|
"LHS and RHS should have the same type");
|
|
|
|
assert(LHS->getType()->isIntOrIntVectorTy() &&
|
|
|
|
"LHS and RHS should be integers");
|
2018-04-15 20:59:33 +02:00
|
|
|
// Look for an inverted mask: (X & ~M) op (Y & M).
|
|
|
|
Value *M;
|
|
|
|
if (match(LHS, m_c_And(m_Not(m_Value(M)), m_Value())) &&
|
|
|
|
match(RHS, m_c_And(m_Specific(M), m_Value())))
|
|
|
|
return true;
|
|
|
|
if (match(RHS, m_c_And(m_Not(m_Value(M)), m_Value())) &&
|
|
|
|
match(LHS, m_c_And(m_Specific(M), m_Value())))
|
|
|
|
return true;
|
2015-05-15 01:53:19 +02:00
|
|
|
IntegerType *IT = cast<IntegerType>(LHS->getType()->getScalarType());
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits LHSKnown(IT->getBitWidth());
|
|
|
|
KnownBits RHSKnown(IT->getBitWidth());
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
computeKnownBits(LHS, LHSKnown, DL, 0, AC, CxtI, DT, nullptr, UseInstrInfo);
|
|
|
|
computeKnownBits(RHS, RHSKnown, DL, 0, AC, CxtI, DT, nullptr, UseInstrInfo);
|
2017-04-26 18:39:58 +02:00
|
|
|
return (LHSKnown.Zero | RHSKnown.Zero).isAllOnesValue();
|
2015-05-15 01:53:19 +02:00
|
|
|
}
|
|
|
|
|
2017-05-31 19:12:38 +02:00
|
|
|
bool llvm::isOnlyUsedInZeroEqualityComparison(const Instruction *CxtI) {
|
|
|
|
for (const User *U : CxtI->users()) {
|
|
|
|
if (const ICmpInst *IC = dyn_cast<ICmpInst>(U))
|
|
|
|
if (IC->isEquality())
|
|
|
|
if (Constant *C = dyn_cast<Constant>(IC->getOperand(1)))
|
|
|
|
if (C->isNullValue())
|
|
|
|
continue;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
static bool isKnownToBeAPowerOfTwo(const Value *V, bool OrZero, unsigned Depth,
|
2016-01-15 23:22:04 +01:00
|
|
|
const Query &Q);
|
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-07 20:57:58 +02:00
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
bool llvm::isKnownToBeAPowerOfTwo(const Value *V, const DataLayout &DL,
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
bool OrZero, unsigned Depth,
|
|
|
|
AssumptionCache *AC, const Instruction *CxtI,
|
|
|
|
const DominatorTree *DT, bool UseInstrInfo) {
|
|
|
|
return ::isKnownToBeAPowerOfTwo(
|
|
|
|
V, OrZero, Depth, Query(DL, AC, safeCxtI(V, CxtI), DT, UseInstrInfo));
|
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-07 20:57:58 +02:00
|
|
|
}
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
static bool isKnownNonZero(const Value *V, unsigned Depth, const Query &Q);
|
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-07 20:57:58 +02:00
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
bool llvm::isKnownNonZero(const Value *V, const DataLayout &DL, unsigned Depth,
|
2016-12-19 09:22:17 +01:00
|
|
|
AssumptionCache *AC, const Instruction *CxtI,
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
const DominatorTree *DT, bool UseInstrInfo) {
|
|
|
|
return ::isKnownNonZero(V, Depth,
|
|
|
|
Query(DL, AC, safeCxtI(V, CxtI), DT, UseInstrInfo));
|
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-07 20:57:58 +02:00
|
|
|
}
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
bool llvm::isKnownNonNegative(const Value *V, const DataLayout &DL,
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
unsigned Depth, AssumptionCache *AC,
|
|
|
|
const Instruction *CxtI, const DominatorTree *DT,
|
|
|
|
bool UseInstrInfo) {
|
|
|
|
KnownBits Known =
|
|
|
|
computeKnownBits(V, DL, Depth, AC, CxtI, DT, nullptr, UseInstrInfo);
|
2017-05-08 18:22:48 +02:00
|
|
|
return Known.isNonNegative();
|
2015-08-20 20:27:04 +02:00
|
|
|
}
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
bool llvm::isKnownPositive(const Value *V, const DataLayout &DL, unsigned Depth,
|
2016-12-19 09:22:17 +01:00
|
|
|
AssumptionCache *AC, const Instruction *CxtI,
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
const DominatorTree *DT, bool UseInstrInfo) {
|
2016-03-09 22:31:47 +01:00
|
|
|
if (auto *CI = dyn_cast<ConstantInt>(V))
|
|
|
|
return CI->getValue().isStrictlyPositive();
|
2016-05-07 04:08:15 +02:00
|
|
|
|
2016-03-09 22:31:47 +01:00
|
|
|
// TODO: We'd doing two recursive queries here. We should factor this such
|
|
|
|
// that only a single query is needed.
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
return isKnownNonNegative(V, DL, Depth, AC, CxtI, DT, UseInstrInfo) &&
|
|
|
|
isKnownNonZero(V, DL, Depth, AC, CxtI, DT, UseInstrInfo);
|
2016-03-09 22:31:47 +01:00
|
|
|
}
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
bool llvm::isKnownNegative(const Value *V, const DataLayout &DL, unsigned Depth,
|
2016-12-19 09:22:17 +01:00
|
|
|
AssumptionCache *AC, const Instruction *CxtI,
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
const DominatorTree *DT, bool UseInstrInfo) {
|
|
|
|
KnownBits Known =
|
|
|
|
computeKnownBits(V, DL, Depth, AC, CxtI, DT, nullptr, UseInstrInfo);
|
2017-05-08 18:22:48 +02:00
|
|
|
return Known.isNegative();
|
Add optimization for 'icmp slt (or A, B), A' and some related idioms based on knowledge of the sign bit for A and B.
No matter what value you OR in to A, the result of (or A, B) is going to be UGE A. When A and B are positive, it's SGE too. If A is negative, OR'ing a value into it can't make it positive, but can increase its value closer to -1, therefore (or A, B) is SGE A. Working through all possible combinations produces this truth table:
```
A is
+, -, +/-
F F F + B is
T F ? -
? F ? +/-
```
The related optimizations are flipping the 'slt' for 'sge' which always NOTs the result (if the result is known), and swapping the LHS and RHS while swapping the comparison predicate.
There are more idioms left to implement (aren't there always!) but I've stopped here because any more would risk becoming unreasonable for reviewers.
llvm-svn: 266939
2016-04-21 02:53:14 +02:00
|
|
|
}
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
static bool isKnownNonEqual(const Value *V1, const Value *V2, const Query &Q);
|
2015-10-22 15:18:42 +02:00
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
bool llvm::isKnownNonEqual(const Value *V1, const Value *V2,
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
const DataLayout &DL, AssumptionCache *AC,
|
|
|
|
const Instruction *CxtI, const DominatorTree *DT,
|
|
|
|
bool UseInstrInfo) {
|
|
|
|
return ::isKnownNonEqual(V1, V2,
|
|
|
|
Query(DL, AC, safeCxtI(V1, safeCxtI(V2, CxtI)), DT,
|
|
|
|
UseInstrInfo, /*ORE=*/nullptr));
|
2015-10-22 15:18:42 +02:00
|
|
|
}
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
static bool MaskedValueIsZero(const Value *V, const APInt &Mask, unsigned Depth,
|
2016-01-15 23:22:04 +01:00
|
|
|
const Query &Q);
|
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-07 20:57:58 +02:00
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
bool llvm::MaskedValueIsZero(const Value *V, const APInt &Mask,
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
const DataLayout &DL, unsigned Depth,
|
|
|
|
AssumptionCache *AC, const Instruction *CxtI,
|
|
|
|
const DominatorTree *DT, bool UseInstrInfo) {
|
|
|
|
return ::MaskedValueIsZero(
|
|
|
|
V, Mask, Depth, Query(DL, AC, safeCxtI(V, CxtI), DT, UseInstrInfo));
|
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-07 20:57:58 +02:00
|
|
|
}
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
static unsigned ComputeNumSignBits(const Value *V, unsigned Depth,
|
|
|
|
const Query &Q);
|
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-07 20:57:58 +02:00
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
unsigned llvm::ComputeNumSignBits(const Value *V, const DataLayout &DL,
|
2016-12-19 09:22:17 +01:00
|
|
|
unsigned Depth, AssumptionCache *AC,
|
|
|
|
const Instruction *CxtI,
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
const DominatorTree *DT, bool UseInstrInfo) {
|
|
|
|
return ::ComputeNumSignBits(
|
|
|
|
V, Depth, Query(DL, AC, safeCxtI(V, CxtI), DT, UseInstrInfo));
|
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-07 20:57:58 +02:00
|
|
|
}
|
|
|
|
|
2017-03-24 23:12:10 +01:00
|
|
|
static void computeKnownBitsAddSub(bool Add, const Value *Op0, const Value *Op1,
|
|
|
|
bool NSW,
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits &KnownOut, KnownBits &Known2,
|
2017-03-24 23:12:10 +01:00
|
|
|
unsigned Depth, const Query &Q) {
|
2017-04-26 18:39:58 +02:00
|
|
|
unsigned BitWidth = KnownOut.getBitWidth();
|
2017-03-24 23:12:10 +01:00
|
|
|
|
|
|
|
// If an initial sequence of bits in the result is not needed, the
|
|
|
|
// corresponding bits in the operands are not needed.
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits LHSKnown(BitWidth);
|
|
|
|
computeKnownBits(Op0, LHSKnown, Depth + 1, Q);
|
|
|
|
computeKnownBits(Op1, Known2, Depth + 1, Q);
|
2017-03-24 23:12:10 +01:00
|
|
|
|
2017-08-08 18:29:35 +02:00
|
|
|
KnownOut = KnownBits::computeForAddSub(Add, NSW, LHSKnown, Known2);
|
2012-03-09 10:23:50 +01:00
|
|
|
}
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
static void computeKnownBitsMul(const Value *Op0, const Value *Op1, bool NSW,
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits &Known, KnownBits &Known2,
|
2016-01-15 23:22:04 +01:00
|
|
|
unsigned Depth, const Query &Q) {
|
2017-04-26 18:39:58 +02:00
|
|
|
unsigned BitWidth = Known.getBitWidth();
|
|
|
|
computeKnownBits(Op1, Known, Depth + 1, Q);
|
|
|
|
computeKnownBits(Op0, Known2, Depth + 1, Q);
|
2012-03-19 00:28:48 +01:00
|
|
|
|
|
|
|
bool isKnownNegative = false;
|
|
|
|
bool isKnownNonNegative = false;
|
|
|
|
// If the multiplication is known not to overflow, compute the sign bit.
|
2012-04-04 14:51:34 +02:00
|
|
|
if (NSW) {
|
2012-03-19 00:28:48 +01:00
|
|
|
if (Op0 == Op1) {
|
|
|
|
// The product of a number with itself is non-negative.
|
|
|
|
isKnownNonNegative = true;
|
|
|
|
} else {
|
2017-04-29 18:43:11 +02:00
|
|
|
bool isKnownNonNegativeOp1 = Known.isNonNegative();
|
|
|
|
bool isKnownNonNegativeOp0 = Known2.isNonNegative();
|
|
|
|
bool isKnownNegativeOp1 = Known.isNegative();
|
|
|
|
bool isKnownNegativeOp0 = Known2.isNegative();
|
2012-03-19 00:28:48 +01:00
|
|
|
// 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 &&
|
2016-01-15 23:22:04 +01:00
|
|
|
isKnownNonZero(Op0, Depth, Q)) ||
|
2012-03-19 00:28:48 +01:00
|
|
|
(isKnownNegativeOp0 && isKnownNonNegativeOp1 &&
|
2016-01-15 23:22:04 +01:00
|
|
|
isKnownNonZero(Op1, Depth, Q));
|
2012-03-19 00:28:48 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-12-10 00:25:57 +01:00
|
|
|
assert(!Known.hasConflict() && !Known2.hasConflict());
|
|
|
|
// Compute a conservative estimate for high known-0 bits.
|
2017-05-12 19:20:30 +02:00
|
|
|
unsigned LeadZ = std::max(Known.countMinLeadingZeros() +
|
|
|
|
Known2.countMinLeadingZeros(),
|
2012-03-19 00:28:48 +01:00
|
|
|
BitWidth) - BitWidth;
|
|
|
|
LeadZ = std::min(LeadZ, BitWidth);
|
2017-12-10 00:25:57 +01:00
|
|
|
|
|
|
|
// The result of the bottom bits of an integer multiply can be
|
|
|
|
// inferred by looking at the bottom bits of both operands and
|
|
|
|
// multiplying them together.
|
|
|
|
// We can infer at least the minimum number of known trailing bits
|
|
|
|
// of both operands. Depending on number of trailing zeros, we can
|
|
|
|
// infer more bits, because (a*b) <=> ((a/m) * (b/n)) * (m*n) assuming
|
|
|
|
// a and b are divisible by m and n respectively.
|
|
|
|
// We then calculate how many of those bits are inferrable and set
|
|
|
|
// the output. For example, the i8 mul:
|
|
|
|
// a = XXXX1100 (12)
|
|
|
|
// b = XXXX1110 (14)
|
|
|
|
// We know the bottom 3 bits are zero since the first can be divided by
|
|
|
|
// 4 and the second by 2, thus having ((12/4) * (14/2)) * (2*4).
|
|
|
|
// Applying the multiplication to the trimmed arguments gets:
|
|
|
|
// XX11 (3)
|
|
|
|
// X111 (7)
|
|
|
|
// -------
|
|
|
|
// XX11
|
|
|
|
// XX11
|
|
|
|
// XX11
|
|
|
|
// XX11
|
|
|
|
// -------
|
|
|
|
// XXXXX01
|
|
|
|
// Which allows us to infer the 2 LSBs. Since we're multiplying the result
|
|
|
|
// by 8, the bottom 3 bits will be 0, so we can infer a total of 5 bits.
|
|
|
|
// The proof for this can be described as:
|
|
|
|
// Pre: (C1 >= 0) && (C1 < (1 << C5)) && (C2 >= 0) && (C2 < (1 << C6)) &&
|
|
|
|
// (C7 == (1 << (umin(countTrailingZeros(C1), C5) +
|
|
|
|
// umin(countTrailingZeros(C2), C6) +
|
|
|
|
// umin(C5 - umin(countTrailingZeros(C1), C5),
|
|
|
|
// C6 - umin(countTrailingZeros(C2), C6)))) - 1)
|
|
|
|
// %aa = shl i8 %a, C5
|
|
|
|
// %bb = shl i8 %b, C6
|
|
|
|
// %aaa = or i8 %aa, C1
|
|
|
|
// %bbb = or i8 %bb, C2
|
|
|
|
// %mul = mul i8 %aaa, %bbb
|
|
|
|
// %mask = and i8 %mul, C7
|
|
|
|
// =>
|
|
|
|
// %mask = i8 ((C1*C2)&C7)
|
|
|
|
// Where C5, C6 describe the known bits of %a, %b
|
|
|
|
// C1, C2 describe the known bottom bits of %a, %b.
|
|
|
|
// C7 describes the mask of the known bits of the result.
|
|
|
|
APInt Bottom0 = Known.One;
|
|
|
|
APInt Bottom1 = Known2.One;
|
|
|
|
|
|
|
|
// How many times we'd be able to divide each argument by 2 (shr by 1).
|
|
|
|
// This gives us the number of trailing zeros on the multiplication result.
|
|
|
|
unsigned TrailBitsKnown0 = (Known.Zero | Known.One).countTrailingOnes();
|
|
|
|
unsigned TrailBitsKnown1 = (Known2.Zero | Known2.One).countTrailingOnes();
|
|
|
|
unsigned TrailZero0 = Known.countMinTrailingZeros();
|
|
|
|
unsigned TrailZero1 = Known2.countMinTrailingZeros();
|
|
|
|
unsigned TrailZ = TrailZero0 + TrailZero1;
|
|
|
|
|
|
|
|
// Figure out the fewest known-bits operand.
|
|
|
|
unsigned SmallestOperand = std::min(TrailBitsKnown0 - TrailZero0,
|
|
|
|
TrailBitsKnown1 - TrailZero1);
|
|
|
|
unsigned ResultBitsKnown = std::min(SmallestOperand + TrailZ, BitWidth);
|
|
|
|
|
|
|
|
APInt BottomKnown = Bottom0.getLoBits(TrailBitsKnown0) *
|
|
|
|
Bottom1.getLoBits(TrailBitsKnown1);
|
|
|
|
|
2017-05-05 19:36:09 +02:00
|
|
|
Known.resetAll();
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero.setHighBits(LeadZ);
|
2017-12-10 00:25:57 +01:00
|
|
|
Known.Zero |= (~BottomKnown).getLoBits(ResultBitsKnown);
|
|
|
|
Known.One |= BottomKnown.getLoBits(ResultBitsKnown);
|
2012-03-19 00:28:48 +01:00
|
|
|
|
|
|
|
// 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.
|
2017-04-29 18:43:11 +02:00
|
|
|
if (isKnownNonNegative && !Known.isNegative())
|
|
|
|
Known.makeNonNegative();
|
|
|
|
else if (isKnownNegative && !Known.isNonNegative())
|
|
|
|
Known.makeNegative();
|
2012-03-19 00:28:48 +01:00
|
|
|
}
|
|
|
|
|
2014-06-19 18:50:16 +02:00
|
|
|
void llvm::computeKnownBitsFromRangeMetadata(const MDNode &Ranges,
|
2017-04-28 08:28:56 +02:00
|
|
|
KnownBits &Known) {
|
|
|
|
unsigned BitWidth = Known.getBitWidth();
|
2012-03-30 17:52:11 +02:00
|
|
|
unsigned NumRanges = Ranges.getNumOperands() / 2;
|
|
|
|
assert(NumRanges >= 1);
|
|
|
|
|
2017-04-28 08:28:56 +02:00
|
|
|
Known.Zero.setAllBits();
|
|
|
|
Known.One.setAllBits();
|
2015-10-28 04:20:15 +01:00
|
|
|
|
2012-03-30 17:52:11 +02:00
|
|
|
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-09 19:38:53 +01:00
|
|
|
ConstantInt *Lower =
|
|
|
|
mdconst::extract<ConstantInt>(Ranges.getOperand(2 * i + 0));
|
|
|
|
ConstantInt *Upper =
|
|
|
|
mdconst::extract<ConstantInt>(Ranges.getOperand(2 * i + 1));
|
2012-03-30 17:52:11 +02:00
|
|
|
ConstantRange Range(Lower->getValue(), Upper->getValue());
|
|
|
|
|
2015-10-28 04:20:15 +01:00
|
|
|
// The first CommonPrefixBits of all values in Range are equal.
|
|
|
|
unsigned CommonPrefixBits =
|
|
|
|
(Range.getUnsignedMax() ^ Range.getUnsignedMin()).countLeadingZeros();
|
|
|
|
|
|
|
|
APInt Mask = APInt::getHighBitsSet(BitWidth, CommonPrefixBits);
|
2017-04-28 08:28:56 +02:00
|
|
|
Known.One &= Range.getUnsignedMax() & Mask;
|
|
|
|
Known.Zero &= ~Range.getUnsignedMax() & Mask;
|
2015-10-28 04:20:15 +01:00
|
|
|
}
|
2012-03-30 17:52:11 +02:00
|
|
|
}
|
2014-05-15 14:12:55 +02:00
|
|
|
|
2016-08-12 00:23:07 +02:00
|
|
|
static bool isEphemeralValueOf(const Instruction *I, const Value *E) {
|
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-07 20:57:58 +02:00
|
|
|
SmallVector<const Value *, 16> WorkSet(1, I);
|
|
|
|
SmallPtrSet<const Value *, 32> Visited;
|
|
|
|
SmallPtrSet<const Value *, 16> EphValues;
|
|
|
|
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
// The instruction defining an assumption's condition itself is always
|
|
|
|
// considered ephemeral to that assumption (even if it has other
|
|
|
|
// non-ephemeral users). See r246696's test case for an example.
|
2016-08-11 23:15:00 +02:00
|
|
|
if (is_contained(I->operands(), E))
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02: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-07 20:57:58 +02:00
|
|
|
while (!WorkSet.empty()) {
|
|
|
|
const Value *V = WorkSet.pop_back_val();
|
2014-11-19 08:49:26 +01: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-07 20:57:58 +02:00
|
|
|
continue;
|
|
|
|
|
|
|
|
// If all uses of this value are ephemeral, then so is this value.
|
2017-09-01 23:37:29 +02:00
|
|
|
if (llvm::all_of(V->users(), [&](const User *U) {
|
|
|
|
return EphValues.count(U);
|
|
|
|
})) {
|
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-07 20:57:58 +02:00
|
|
|
if (V == E)
|
|
|
|
return true;
|
|
|
|
|
2017-08-14 19:11:43 +02:00
|
|
|
if (V == I || isSafeToSpeculativelyExecute(V)) {
|
|
|
|
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)
|
|
|
|
WorkSet.push_back(*J);
|
|
|
|
}
|
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-07 20:57:58 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Is this an intrinsic that cannot be speculated but also cannot trap?
|
2017-12-15 15:34:41 +01:00
|
|
|
bool llvm::isAssumeLikeIntrinsic(const Instruction *I) {
|
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-07 20:57:58 +02:00
|
|
|
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:
|
Add an @llvm.sideeffect intrinsic
This patch implements Chandler's idea [0] for supporting languages that
require support for infinite loops with side effects, such as Rust, providing
part of a solution to bug 965 [1].
Specifically, it adds an `llvm.sideeffect()` intrinsic, which has no actual
effect, but which appears to optimization passes to have obscure side effects,
such that they don't optimize away loops containing it. It also teaches
several optimization passes to ignore this intrinsic, so that it doesn't
significantly impact optimization in most cases.
As discussed on llvm-dev [2], this patch is the first of two major parts.
The second part, to change LLVM's semantics to have defined behavior
on infinite loops by default, with a function attribute for opting into
potential-undefined-behavior, will be implemented and posted for review in
a separate patch.
[0] http://lists.llvm.org/pipermail/llvm-dev/2015-July/088103.html
[1] https://bugs.llvm.org/show_bug.cgi?id=965
[2] http://lists.llvm.org/pipermail/llvm-dev/2017-October/118632.html
Differential Revision: https://reviews.llvm.org/D38336
llvm-svn: 317729
2017-11-08 22:59:51 +01:00
|
|
|
case Intrinsic::sideeffect:
|
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-07 20:57:58 +02:00
|
|
|
case Intrinsic::dbg_declare:
|
|
|
|
case Intrinsic::dbg_value:
|
[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.
In order to set breakpoints on labels and list source code around
labels, we need collect debug information for labels, i.e., label
name, the function label belong, line number in the file, and the
address label located. In order to keep these information in LLVM
IR and to allow backend to generate debug information correctly.
We create a new kind of metadata for labels, DILabel. The format
of DILabel is
!DILabel(scope: !1, name: "foo", file: !2, line: 3)
We hope to keep debug information as much as possible even the
code is optimized. So, we create a new kind of intrinsic for label
metadata to avoid the metadata is eliminated with basic block.
The intrinsic will keep existing if we keep it from optimized out.
The format of the intrinsic is
llvm.dbg.label(metadata !1)
It has only one argument, that is the DILabel metadata. The
intrinsic will follow the label immediately. Backend could get the
label metadata through the intrinsic's parameter.
We also create DIBuilder API for labels to be used by Frontend.
Frontend could use createLabel() to allocate DILabel objects, and use
insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR.
Differential Revision: https://reviews.llvm.org/D45024
Patch by Hsiangkai Wang.
llvm-svn: 331841
2018-05-09 04:40:45 +02:00
|
|
|
case Intrinsic::dbg_label:
|
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-07 20:57:58 +02:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2016-08-12 00:23:07 +02:00
|
|
|
bool llvm::isValidAssumeForContext(const Instruction *Inv,
|
|
|
|
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-07 20:57:58 +02:00
|
|
|
// 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).
|
|
|
|
|
2016-01-15 23:22:04 +01:00
|
|
|
if (DT) {
|
2016-08-12 03:00:15 +02:00
|
|
|
if (DT->dominates(Inv, 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-07 20:57:58 +02:00
|
|
|
return true;
|
2016-08-12 03:00:15 +02:00
|
|
|
} else if (Inv->getParent() == CxtI->getParent()->getSinglePredecessor()) {
|
|
|
|
// We don't have a DT, but this trivially dominates.
|
|
|
|
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-07 20:57:58 +02:00
|
|
|
|
2016-08-12 03:00:15 +02:00
|
|
|
// With or without a DT, the only remaining case we will check is if the
|
|
|
|
// instructions are in the same BB. Give up if that is not the case.
|
|
|
|
if (Inv->getParent() != CxtI->getParent())
|
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-07 20:57:58 +02:00
|
|
|
return false;
|
|
|
|
|
2018-02-28 20:08:52 +01:00
|
|
|
// If we have a dom tree, then we now know that the assume doesn't dominate
|
2016-08-12 03:00:15 +02:00
|
|
|
// the other instruction. If we don't have a dom tree then we can check if
|
|
|
|
// the assume is first in the BB.
|
|
|
|
if (!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-07 20:57:58 +02:00
|
|
|
// 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.
|
2016-08-12 00:23:07 +02:00
|
|
|
for (auto I = std::next(BasicBlock::const_iterator(Inv)),
|
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-07 20:57:58 +02:00
|
|
|
IE = Inv->getParent()->end(); I != IE; ++I)
|
2016-01-15 23:22:04 +01:00
|
|
|
if (&*I == 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-07 20:57:58 +02:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2016-08-12 03:00:15 +02:00
|
|
|
// 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(CxtI)), IE(Inv);
|
|
|
|
I != IE; ++I)
|
|
|
|
if (!isSafeToSpeculativelyExecute(&*I) && !isAssumeLikeIntrinsic(&*I))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return !isEphemeralValueOf(Inv, 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-07 20:57:58 +02:00
|
|
|
}
|
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
static void computeKnownBitsFromAssume(const Value *V, KnownBits &Known,
|
|
|
|
unsigned Depth, const Query &Q) {
|
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-07 20:57:58 +02:00
|
|
|
// Use of assumptions is context-sensitive. If we don't have a context, we
|
|
|
|
// cannot use them!
|
2016-12-19 09:22:17 +01: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-07 20:57:58 +02:00
|
|
|
return;
|
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
unsigned BitWidth = Known.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-07 20:57:58 +02:00
|
|
|
|
2017-01-11 14:24:24 +01:00
|
|
|
// Note that the patterns below need to be kept in sync with the code
|
|
|
|
// in AssumptionCache::updateAffectedValues.
|
|
|
|
|
|
|
|
for (auto &AssumeVH : Q.AC->assumptionsFor(V)) {
|
2016-12-19 09:22:17 +01:00
|
|
|
if (!AssumeVH)
|
2016-12-15 03:53:42 +01:00
|
|
|
continue;
|
2016-12-19 09:22:17 +01:00
|
|
|
CallInst *I = cast<CallInst>(AssumeVH);
|
|
|
|
assert(I->getParent()->getParent() == Q.CxtI->getParent()->getParent() &&
|
|
|
|
"Got assumption for the wrong function!");
|
|
|
|
if (Q.isExcluded(I))
|
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-07 20:57:58 +02:00
|
|
|
continue;
|
|
|
|
|
2018-02-28 20:08:52 +01:00
|
|
|
// Warning: This loop can end up being somewhat performance sensitive.
|
2016-12-19 09:22:17 +01:00
|
|
|
// We're running this loop for once for each value queried resulting in a
|
|
|
|
// runtime of ~O(#assumes * #values).
|
2014-11-25 00:44:28 +01:00
|
|
|
|
2016-12-19 09:22:17 +01:00
|
|
|
assert(I->getCalledFunction()->getIntrinsicID() == Intrinsic::assume &&
|
|
|
|
"must be an assume intrinsic");
|
|
|
|
|
|
|
|
Value *Arg = I->getArgOperand(0);
|
|
|
|
|
|
|
|
if (Arg == V && isValidAssumeForContext(I, Q.CxtI, 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-07 20:57:58 +02:00
|
|
|
assert(BitWidth == 1 && "assume operand is not i1?");
|
2017-05-05 19:36:09 +02:00
|
|
|
Known.setAllOnes();
|
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-07 20:57:58 +02:00
|
|
|
return;
|
|
|
|
}
|
2017-01-17 19:15:49 +01:00
|
|
|
if (match(Arg, m_Not(m_Specific(V))) &&
|
|
|
|
isValidAssumeForContext(I, Q.CxtI, Q.DT)) {
|
|
|
|
assert(BitWidth == 1 && "assume operand is not i1?");
|
2017-05-05 19:36:09 +02:00
|
|
|
Known.setAllZero();
|
2017-01-17 19:15:49 +01:00
|
|
|
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-07 20:57:58 +02:00
|
|
|
|
2014-12-13 00:59:29 +01: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-07 20:57:58 +02: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;
|
2017-12-05 13:18:15 +01:00
|
|
|
uint64_t 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-07 20:57:58 +02:00
|
|
|
// assume(v = a)
|
2014-11-25 00:44:28 +01:00
|
|
|
if (match(Arg, m_c_ICmp(Pred, m_V, m_Value(A))) &&
|
2016-12-19 09:22:17 +01:00
|
|
|
Pred == ICmpInst::ICMP_EQ && isValidAssumeForContext(I, Q.CxtI, Q.DT)) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits RHSKnown(BitWidth);
|
|
|
|
computeKnownBits(A, RHSKnown, Depth+1, Query(Q, I));
|
|
|
|
Known.Zero |= RHSKnown.Zero;
|
|
|
|
Known.One |= RHSKnown.One;
|
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-07 20:57:58 +02:00
|
|
|
// assume(v & b = a)
|
2015-03-10 03:37:25 +01:00
|
|
|
} else if (match(Arg,
|
|
|
|
m_c_ICmp(Pred, m_c_And(m_V, m_Value(B)), m_Value(A))) &&
|
2016-01-15 23:22:04 +01:00
|
|
|
Pred == ICmpInst::ICMP_EQ &&
|
2016-12-19 09:22:17 +01:00
|
|
|
isValidAssumeForContext(I, Q.CxtI, Q.DT)) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits RHSKnown(BitWidth);
|
|
|
|
computeKnownBits(A, RHSKnown, Depth+1, Query(Q, I));
|
|
|
|
KnownBits MaskKnown(BitWidth);
|
|
|
|
computeKnownBits(B, MaskKnown, Depth+1, Query(Q, I));
|
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-07 20:57:58 +02:00
|
|
|
|
|
|
|
// For those bits in the mask that are known to be one, we can propagate
|
|
|
|
// known bits from the RHS to V.
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero |= RHSKnown.Zero & MaskKnown.One;
|
|
|
|
Known.One |= RHSKnown.One & MaskKnown.One;
|
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-07 21:21:07 +02:00
|
|
|
// assume(~(v & b) = a)
|
2014-11-25 00:44:28 +01:00
|
|
|
} else if (match(Arg, m_c_ICmp(Pred, m_Not(m_c_And(m_V, m_Value(B))),
|
|
|
|
m_Value(A))) &&
|
2016-01-15 23:22:04 +01:00
|
|
|
Pred == ICmpInst::ICMP_EQ &&
|
2016-12-19 09:22:17 +01:00
|
|
|
isValidAssumeForContext(I, Q.CxtI, Q.DT)) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits RHSKnown(BitWidth);
|
|
|
|
computeKnownBits(A, RHSKnown, Depth+1, Query(Q, I));
|
|
|
|
KnownBits MaskKnown(BitWidth);
|
|
|
|
computeKnownBits(B, MaskKnown, Depth+1, Query(Q, I));
|
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-07 21:21:07 +02:00
|
|
|
|
|
|
|
// For those bits in the mask that are known to be one, we can propagate
|
|
|
|
// inverted known bits from the RHS to V.
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero |= RHSKnown.One & MaskKnown.One;
|
|
|
|
Known.One |= RHSKnown.Zero & MaskKnown.One;
|
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-07 21:21:07 +02:00
|
|
|
// assume(v | b = a)
|
2015-03-10 03:37:25 +01:00
|
|
|
} else if (match(Arg,
|
|
|
|
m_c_ICmp(Pred, m_c_Or(m_V, m_Value(B)), m_Value(A))) &&
|
2016-01-15 23:22:04 +01:00
|
|
|
Pred == ICmpInst::ICMP_EQ &&
|
2016-12-19 09:22:17 +01:00
|
|
|
isValidAssumeForContext(I, Q.CxtI, Q.DT)) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits RHSKnown(BitWidth);
|
|
|
|
computeKnownBits(A, RHSKnown, Depth+1, Query(Q, I));
|
|
|
|
KnownBits BKnown(BitWidth);
|
|
|
|
computeKnownBits(B, BKnown, Depth+1, Query(Q, I));
|
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-07 21:21:07 +02:00
|
|
|
|
|
|
|
// For those bits in B that are known to be zero, we can propagate known
|
|
|
|
// bits from the RHS to V.
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero |= RHSKnown.Zero & BKnown.Zero;
|
|
|
|
Known.One |= RHSKnown.One & BKnown.Zero;
|
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-07 21:21:07 +02:00
|
|
|
// assume(~(v | b) = a)
|
2014-11-25 00:44:28 +01:00
|
|
|
} else if (match(Arg, m_c_ICmp(Pred, m_Not(m_c_Or(m_V, m_Value(B))),
|
|
|
|
m_Value(A))) &&
|
2016-01-15 23:22:04 +01:00
|
|
|
Pred == ICmpInst::ICMP_EQ &&
|
2016-12-19 09:22:17 +01:00
|
|
|
isValidAssumeForContext(I, Q.CxtI, Q.DT)) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits RHSKnown(BitWidth);
|
|
|
|
computeKnownBits(A, RHSKnown, Depth+1, Query(Q, I));
|
|
|
|
KnownBits BKnown(BitWidth);
|
|
|
|
computeKnownBits(B, BKnown, Depth+1, Query(Q, I));
|
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-07 21:21:07 +02:00
|
|
|
|
|
|
|
// For those bits in B that are known to be zero, we can propagate
|
|
|
|
// inverted known bits from the RHS to V.
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero |= RHSKnown.One & BKnown.Zero;
|
|
|
|
Known.One |= RHSKnown.Zero & BKnown.Zero;
|
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-07 21:21:07 +02:00
|
|
|
// assume(v ^ b = a)
|
2015-03-10 03:37:25 +01:00
|
|
|
} else if (match(Arg,
|
|
|
|
m_c_ICmp(Pred, m_c_Xor(m_V, m_Value(B)), m_Value(A))) &&
|
2016-01-15 23:22:04 +01:00
|
|
|
Pred == ICmpInst::ICMP_EQ &&
|
2016-12-19 09:22:17 +01:00
|
|
|
isValidAssumeForContext(I, Q.CxtI, Q.DT)) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits RHSKnown(BitWidth);
|
|
|
|
computeKnownBits(A, RHSKnown, Depth+1, Query(Q, I));
|
|
|
|
KnownBits BKnown(BitWidth);
|
|
|
|
computeKnownBits(B, BKnown, Depth+1, Query(Q, I));
|
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-07 21:21:07 +02:00
|
|
|
|
|
|
|
// 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.
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero |= RHSKnown.Zero & BKnown.Zero;
|
|
|
|
Known.One |= RHSKnown.One & BKnown.Zero;
|
|
|
|
Known.Zero |= RHSKnown.One & BKnown.One;
|
|
|
|
Known.One |= RHSKnown.Zero & BKnown.One;
|
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-07 21:21:07 +02:00
|
|
|
// assume(~(v ^ b) = a)
|
2014-11-25 00:44:28 +01:00
|
|
|
} else if (match(Arg, m_c_ICmp(Pred, m_Not(m_c_Xor(m_V, m_Value(B))),
|
|
|
|
m_Value(A))) &&
|
2016-01-15 23:22:04 +01:00
|
|
|
Pred == ICmpInst::ICMP_EQ &&
|
2016-12-19 09:22:17 +01:00
|
|
|
isValidAssumeForContext(I, Q.CxtI, Q.DT)) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits RHSKnown(BitWidth);
|
|
|
|
computeKnownBits(A, RHSKnown, Depth+1, Query(Q, I));
|
|
|
|
KnownBits BKnown(BitWidth);
|
|
|
|
computeKnownBits(B, BKnown, Depth+1, Query(Q, I));
|
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-07 21:21:07 +02:00
|
|
|
|
|
|
|
// 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.
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero |= RHSKnown.One & BKnown.Zero;
|
|
|
|
Known.One |= RHSKnown.Zero & BKnown.Zero;
|
|
|
|
Known.Zero |= RHSKnown.Zero & BKnown.One;
|
|
|
|
Known.One |= RHSKnown.One & BKnown.One;
|
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-07 21:21:07 +02:00
|
|
|
// assume(v << c = a)
|
2014-11-25 00:44:28 +01:00
|
|
|
} else if (match(Arg, m_c_ICmp(Pred, m_Shl(m_V, m_ConstantInt(C)),
|
|
|
|
m_Value(A))) &&
|
2016-01-15 23:22:04 +01:00
|
|
|
Pred == ICmpInst::ICMP_EQ &&
|
2017-12-05 13:18:15 +01:00
|
|
|
isValidAssumeForContext(I, Q.CxtI, Q.DT) &&
|
|
|
|
C < BitWidth) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits RHSKnown(BitWidth);
|
|
|
|
computeKnownBits(A, RHSKnown, Depth+1, Query(Q, I));
|
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-07 21:21:07 +02:00
|
|
|
// For those bits in RHS that are known, we can propagate them to known
|
|
|
|
// bits in V shifted to the right by C.
|
2017-12-05 13:18:15 +01:00
|
|
|
RHSKnown.Zero.lshrInPlace(C);
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero |= RHSKnown.Zero;
|
2017-12-05 13:18:15 +01:00
|
|
|
RHSKnown.One.lshrInPlace(C);
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.One |= RHSKnown.One;
|
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-07 21:21:07 +02:00
|
|
|
// assume(~(v << c) = a)
|
2014-11-25 00:44:28 +01:00
|
|
|
} else if (match(Arg, m_c_ICmp(Pred, m_Not(m_Shl(m_V, m_ConstantInt(C))),
|
|
|
|
m_Value(A))) &&
|
2016-01-15 23:22:04 +01:00
|
|
|
Pred == ICmpInst::ICMP_EQ &&
|
2017-12-05 13:18:15 +01:00
|
|
|
isValidAssumeForContext(I, Q.CxtI, Q.DT) &&
|
|
|
|
C < BitWidth) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits RHSKnown(BitWidth);
|
|
|
|
computeKnownBits(A, RHSKnown, Depth+1, Query(Q, I));
|
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-07 21:21:07 +02:00
|
|
|
// For those bits in RHS that are known, we can propagate them inverted
|
|
|
|
// to known bits in V shifted to the right by C.
|
2017-12-05 13:18:15 +01:00
|
|
|
RHSKnown.One.lshrInPlace(C);
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero |= RHSKnown.One;
|
2017-12-05 13:18:15 +01:00
|
|
|
RHSKnown.Zero.lshrInPlace(C);
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.One |= RHSKnown.Zero;
|
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-07 21:21:07 +02:00
|
|
|
// assume(v >> c = a)
|
2014-11-25 00:44:28 +01:00
|
|
|
} else if (match(Arg,
|
2017-06-24 08:24:04 +02:00
|
|
|
m_c_ICmp(Pred, m_Shr(m_V, m_ConstantInt(C)),
|
2015-03-10 03:37:25 +01:00
|
|
|
m_Value(A))) &&
|
2016-01-15 23:22:04 +01:00
|
|
|
Pred == ICmpInst::ICMP_EQ &&
|
2017-12-05 13:18:15 +01:00
|
|
|
isValidAssumeForContext(I, Q.CxtI, Q.DT) &&
|
|
|
|
C < BitWidth) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits RHSKnown(BitWidth);
|
|
|
|
computeKnownBits(A, RHSKnown, Depth+1, Query(Q, I));
|
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-07 21:21:07 +02:00
|
|
|
// For those bits in RHS that are known, we can propagate them to known
|
|
|
|
// bits in V shifted to the right by C.
|
2017-12-05 13:18:15 +01:00
|
|
|
Known.Zero |= RHSKnown.Zero << C;
|
|
|
|
Known.One |= RHSKnown.One << 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-07 21:21:07 +02:00
|
|
|
// assume(~(v >> c) = a)
|
2017-06-24 08:24:04 +02:00
|
|
|
} else if (match(Arg, m_c_ICmp(Pred, m_Not(m_Shr(m_V, m_ConstantInt(C))),
|
2014-11-25 00:44:28 +01:00
|
|
|
m_Value(A))) &&
|
2016-01-15 23:22:04 +01:00
|
|
|
Pred == ICmpInst::ICMP_EQ &&
|
2017-12-05 13:18:15 +01:00
|
|
|
isValidAssumeForContext(I, Q.CxtI, Q.DT) &&
|
|
|
|
C < BitWidth) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits RHSKnown(BitWidth);
|
|
|
|
computeKnownBits(A, RHSKnown, Depth+1, Query(Q, I));
|
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-07 21:21:07 +02:00
|
|
|
// For those bits in RHS that are known, we can propagate them inverted
|
|
|
|
// to known bits in V shifted to the right by C.
|
2017-12-05 13:18:15 +01:00
|
|
|
Known.Zero |= RHSKnown.One << C;
|
|
|
|
Known.One |= RHSKnown.Zero << 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-07 21:21:07 +02:00
|
|
|
// assume(v >=_s c) where c is non-negative
|
2014-11-25 00:44:28 +01:00
|
|
|
} else if (match(Arg, m_ICmp(Pred, m_V, m_Value(A))) &&
|
2016-01-15 23:22:04 +01:00
|
|
|
Pred == ICmpInst::ICMP_SGE &&
|
2016-12-19 09:22:17 +01:00
|
|
|
isValidAssumeForContext(I, Q.CxtI, Q.DT)) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits RHSKnown(BitWidth);
|
|
|
|
computeKnownBits(A, RHSKnown, Depth+1, Query(Q, I));
|
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-07 21:21:07 +02:00
|
|
|
|
2017-04-29 18:43:11 +02:00
|
|
|
if (RHSKnown.isNonNegative()) {
|
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-07 21:21:07 +02:00
|
|
|
// We know that the sign bit is zero.
|
2017-04-29 18:43:11 +02:00
|
|
|
Known.makeNonNegative();
|
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-07 21:21:07 +02:00
|
|
|
}
|
|
|
|
// assume(v >_s c) where c is at least -1.
|
2014-11-25 00:44:28 +01:00
|
|
|
} else if (match(Arg, m_ICmp(Pred, m_V, m_Value(A))) &&
|
2016-01-15 23:22:04 +01:00
|
|
|
Pred == ICmpInst::ICMP_SGT &&
|
2016-12-19 09:22:17 +01:00
|
|
|
isValidAssumeForContext(I, Q.CxtI, Q.DT)) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits RHSKnown(BitWidth);
|
|
|
|
computeKnownBits(A, RHSKnown, Depth+1, Query(Q, I));
|
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-07 21:21:07 +02:00
|
|
|
|
2017-05-05 19:36:09 +02:00
|
|
|
if (RHSKnown.isAllOnes() || RHSKnown.isNonNegative()) {
|
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-07 21:21:07 +02:00
|
|
|
// We know that the sign bit is zero.
|
2017-04-29 18:43:11 +02:00
|
|
|
Known.makeNonNegative();
|
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-07 21:21:07 +02:00
|
|
|
}
|
|
|
|
// assume(v <=_s c) where c is negative
|
2014-11-25 00:44:28 +01:00
|
|
|
} else if (match(Arg, m_ICmp(Pred, m_V, m_Value(A))) &&
|
2016-01-15 23:22:04 +01:00
|
|
|
Pred == ICmpInst::ICMP_SLE &&
|
2016-12-19 09:22:17 +01:00
|
|
|
isValidAssumeForContext(I, Q.CxtI, Q.DT)) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits RHSKnown(BitWidth);
|
|
|
|
computeKnownBits(A, RHSKnown, Depth+1, Query(Q, I));
|
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-07 21:21:07 +02:00
|
|
|
|
2017-04-29 18:43:11 +02:00
|
|
|
if (RHSKnown.isNegative()) {
|
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-07 21:21:07 +02:00
|
|
|
// We know that the sign bit is one.
|
2017-04-29 18:43:11 +02:00
|
|
|
Known.makeNegative();
|
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-07 21:21:07 +02:00
|
|
|
}
|
|
|
|
// assume(v <_s c) where c is non-positive
|
2014-11-25 00:44:28 +01:00
|
|
|
} else if (match(Arg, m_ICmp(Pred, m_V, m_Value(A))) &&
|
2016-01-15 23:22:04 +01:00
|
|
|
Pred == ICmpInst::ICMP_SLT &&
|
2016-12-19 09:22:17 +01:00
|
|
|
isValidAssumeForContext(I, Q.CxtI, Q.DT)) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits RHSKnown(BitWidth);
|
|
|
|
computeKnownBits(A, RHSKnown, Depth+1, Query(Q, I));
|
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-07 21:21:07 +02:00
|
|
|
|
2017-05-05 19:36:09 +02:00
|
|
|
if (RHSKnown.isZero() || RHSKnown.isNegative()) {
|
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-07 21:21:07 +02:00
|
|
|
// We know that the sign bit is one.
|
2017-04-29 18:43:11 +02:00
|
|
|
Known.makeNegative();
|
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-07 21:21:07 +02:00
|
|
|
}
|
|
|
|
// assume(v <=_u c)
|
2014-11-25 00:44:28 +01:00
|
|
|
} else if (match(Arg, m_ICmp(Pred, m_V, m_Value(A))) &&
|
2016-01-15 23:22:04 +01:00
|
|
|
Pred == ICmpInst::ICMP_ULE &&
|
2016-12-19 09:22:17 +01:00
|
|
|
isValidAssumeForContext(I, Q.CxtI, Q.DT)) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits RHSKnown(BitWidth);
|
|
|
|
computeKnownBits(A, RHSKnown, Depth+1, Query(Q, I));
|
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-07 21:21:07 +02:00
|
|
|
|
|
|
|
// Whatever high bits in c are zero are known to be zero.
|
2017-05-12 19:20:30 +02:00
|
|
|
Known.Zero.setHighBits(RHSKnown.countMinLeadingZeros());
|
|
|
|
// assume(v <_u c)
|
2014-11-25 00:44:28 +01:00
|
|
|
} else if (match(Arg, m_ICmp(Pred, m_V, m_Value(A))) &&
|
2016-01-15 23:22:04 +01:00
|
|
|
Pred == ICmpInst::ICMP_ULT &&
|
2016-12-19 09:22:17 +01:00
|
|
|
isValidAssumeForContext(I, Q.CxtI, Q.DT)) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits RHSKnown(BitWidth);
|
|
|
|
computeKnownBits(A, RHSKnown, Depth+1, Query(Q, I));
|
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-07 21:21:07 +02:00
|
|
|
|
2018-02-08 15:52:40 +01:00
|
|
|
// If the RHS is known zero, then this assumption must be wrong (nothing
|
|
|
|
// is unsigned less than zero). Signal a conflict and get out of here.
|
|
|
|
if (RHSKnown.isZero()) {
|
|
|
|
Known.Zero.setAllBits();
|
|
|
|
Known.One.setAllBits();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
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-07 21:21:07 +02:00
|
|
|
// Whatever high bits in c are zero are known to be zero (if c is a power
|
|
|
|
// of 2, then one more).
|
2016-12-19 09:22:17 +01:00
|
|
|
if (isKnownToBeAPowerOfTwo(A, false, Depth + 1, Query(Q, I)))
|
2017-05-12 19:20:30 +02:00
|
|
|
Known.Zero.setHighBits(RHSKnown.countMinLeadingZeros() + 1);
|
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-07 21:21:07 +02:00
|
|
|
else
|
2017-05-12 19:20:30 +02:00
|
|
|
Known.Zero.setHighBits(RHSKnown.countMinLeadingZeros());
|
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-07 20:57:58 +02:00
|
|
|
}
|
|
|
|
}
|
2017-02-01 16:41:32 +01:00
|
|
|
|
|
|
|
// If assumptions conflict with each other or previous known bits, then we
|
2017-02-06 19:26:06 +01:00
|
|
|
// have a logical fallacy. It's possible that the assumption is not reachable,
|
|
|
|
// so this isn't a real bug. On the other hand, the program may have undefined
|
|
|
|
// behavior, or we might have a bug in the compiler. We can't assert/crash, so
|
|
|
|
// clear out the known bits, try to warn the user, and hope for the best.
|
2017-04-26 18:39:58 +02:00
|
|
|
if (Known.Zero.intersects(Known.One)) {
|
2017-05-05 19:36:09 +02:00
|
|
|
Known.resetAll();
|
2017-02-06 19:26:06 +01:00
|
|
|
|
2017-10-11 19:12:59 +02:00
|
|
|
if (Q.ORE)
|
|
|
|
Q.ORE->emit([&]() {
|
|
|
|
auto *CxtI = const_cast<Instruction *>(Q.CxtI);
|
|
|
|
return OptimizationRemarkAnalysis("value-tracking", "BadAssumption",
|
|
|
|
CxtI)
|
|
|
|
<< "Detected conflicting code assumptions. Program may "
|
|
|
|
"have undefined behavior, or compiler may have "
|
|
|
|
"internal error.";
|
|
|
|
});
|
2017-02-01 16:41:32 +01: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-07 20:57:58 +02:00
|
|
|
}
|
|
|
|
|
2017-10-16 16:46:37 +02:00
|
|
|
/// Compute known bits from a shift operator, including those with a
|
|
|
|
/// non-constant shift amount. Known is the output of this function. Known2 is a
|
|
|
|
/// pre-allocated temporary with the same bit width as Known. KZF and KOF are
|
2018-02-28 20:08:52 +01:00
|
|
|
/// operator-specific functions that, given the known-zero or known-one bits
|
2017-10-16 16:46:37 +02:00
|
|
|
/// respectively, and a shift amount, compute the implied known-zero or
|
|
|
|
/// known-one bits of the shift operator's result respectively for that shift
|
|
|
|
/// amount. The results from calling KZF and KOF are conservatively combined for
|
|
|
|
/// all permitted shift amounts.
|
2016-08-23 22:52:00 +02:00
|
|
|
static void computeKnownBitsFromShiftOperator(
|
2017-04-26 18:39:58 +02:00
|
|
|
const Operator *I, KnownBits &Known, KnownBits &Known2,
|
|
|
|
unsigned Depth, const Query &Q,
|
2017-12-04 13:51:49 +01:00
|
|
|
function_ref<APInt(const APInt &, unsigned)> KZF,
|
|
|
|
function_ref<APInt(const APInt &, unsigned)> KOF) {
|
2017-04-26 18:39:58 +02:00
|
|
|
unsigned BitWidth = Known.getBitWidth();
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
|
|
|
|
if (auto *SA = dyn_cast<ConstantInt>(I->getOperand(1))) {
|
|
|
|
unsigned ShiftAmt = SA->getLimitedValue(BitWidth-1);
|
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(I->getOperand(0), Known, Depth + 1, Q);
|
2017-12-04 13:51:49 +01:00
|
|
|
Known.Zero = KZF(Known.Zero, ShiftAmt);
|
|
|
|
Known.One = KOF(Known.One, ShiftAmt);
|
2017-10-12 19:31:46 +02:00
|
|
|
// If the known bits conflict, this must be an overflowing left shift, so
|
|
|
|
// the shift result is poison. We can return anything we want. Choose 0 for
|
|
|
|
// the best folding opportunity.
|
|
|
|
if (Known.hasConflict())
|
|
|
|
Known.setAllZero();
|
2016-08-25 01:01:33 +02:00
|
|
|
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(I->getOperand(1), Known, Depth + 1, Q);
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
|
2017-10-12 19:31:46 +02:00
|
|
|
// If the shift amount could be greater than or equal to the bit-width of the
|
|
|
|
// LHS, the value could be poison, but bail out because the check below is
|
|
|
|
// expensive. TODO: Should we just carry on?
|
2017-04-26 18:39:58 +02:00
|
|
|
if ((~Known.Zero).uge(BitWidth)) {
|
2017-05-05 19:36:09 +02:00
|
|
|
Known.resetAll();
|
2017-03-14 11:13:17 +01:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
// Note: We cannot use Known.Zero.getLimitedValue() here, because if
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
// BitWidth > 64 and any upper bits are known, we'll end up returning the
|
|
|
|
// limit value (which implies all bits are known).
|
2017-04-26 18:39:58 +02:00
|
|
|
uint64_t ShiftAmtKZ = Known.Zero.zextOrTrunc(64).getZExtValue();
|
|
|
|
uint64_t ShiftAmtKO = Known.One.zextOrTrunc(64).getZExtValue();
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
|
|
|
|
// It would be more-clearly correct to use the two temporaries for this
|
|
|
|
// calculation. Reusing the APInts here to prevent unnecessary allocations.
|
2017-05-05 19:36:09 +02:00
|
|
|
Known.resetAll();
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
|
2015-10-26 15:10:46 +01:00
|
|
|
// If we know the shifter operand is nonzero, we can sometimes infer more
|
|
|
|
// known bits. However this is expensive to compute, so be lazy about it and
|
|
|
|
// only compute it when absolutely necessary.
|
|
|
|
Optional<bool> ShifterOperandIsNonZero;
|
|
|
|
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
// Early exit if we can't constrain any well-defined shift amount.
|
2017-06-14 19:04:59 +02:00
|
|
|
if (!(ShiftAmtKZ & (PowerOf2Ceil(BitWidth) - 1)) &&
|
|
|
|
!(ShiftAmtKO & (PowerOf2Ceil(BitWidth) - 1))) {
|
2017-10-16 16:46:37 +02:00
|
|
|
ShifterOperandIsNonZero = isKnownNonZero(I->getOperand(1), Depth + 1, Q);
|
2015-10-26 15:10:46 +01:00
|
|
|
if (!*ShifterOperandIsNonZero)
|
|
|
|
return;
|
|
|
|
}
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(I->getOperand(0), Known2, Depth + 1, Q);
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero.setAllBits();
|
|
|
|
Known.One.setAllBits();
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
for (unsigned ShiftAmt = 0; ShiftAmt < BitWidth; ++ShiftAmt) {
|
|
|
|
// Combine the shifted known input bits only for those shift amounts
|
|
|
|
// compatible with its known constraints.
|
|
|
|
if ((ShiftAmt & ~ShiftAmtKZ) != ShiftAmt)
|
|
|
|
continue;
|
|
|
|
if ((ShiftAmt | ShiftAmtKO) != ShiftAmt)
|
|
|
|
continue;
|
2015-10-26 15:10:46 +01:00
|
|
|
// If we know the shifter is nonzero, we may be able to infer more known
|
|
|
|
// bits. This check is sunk down as far as possible to avoid the expensive
|
|
|
|
// call to isKnownNonZero if the cheaper checks above fail.
|
|
|
|
if (ShiftAmt == 0) {
|
|
|
|
if (!ShifterOperandIsNonZero.hasValue())
|
|
|
|
ShifterOperandIsNonZero =
|
2016-01-15 23:22:04 +01:00
|
|
|
isKnownNonZero(I->getOperand(1), Depth + 1, Q);
|
2015-10-26 15:10:46 +01:00
|
|
|
if (*ShifterOperandIsNonZero)
|
|
|
|
continue;
|
|
|
|
}
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
|
2017-12-04 13:51:49 +01:00
|
|
|
Known.Zero &= KZF(Known2.Zero, ShiftAmt);
|
|
|
|
Known.One &= KOF(Known2.One, ShiftAmt);
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
}
|
|
|
|
|
2017-10-12 19:31:46 +02:00
|
|
|
// If the known bits conflict, the result is poison. Return a 0 and hope the
|
|
|
|
// caller can further optimize that.
|
|
|
|
if (Known.hasConflict())
|
|
|
|
Known.setAllZero();
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
}
|
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
static void computeKnownBitsFromOperator(const Operator *I, KnownBits &Known,
|
|
|
|
unsigned Depth, const Query &Q) {
|
|
|
|
unsigned BitWidth = Known.getBitWidth();
|
2012-04-04 14:51:34 +02:00
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits Known2(Known);
|
2009-07-17 22:47:02 +02:00
|
|
|
switch (I->getOpcode()) {
|
2008-06-02 03:18:21 +02:00
|
|
|
default: break;
|
2012-03-30 17:52:11 +02:00
|
|
|
case Instruction::Load:
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
if (MDNode *MD =
|
|
|
|
Q.IIQ.getMetadata(cast<LoadInst>(I), LLVMContext::MD_range))
|
2017-04-28 08:28:56 +02:00
|
|
|
computeKnownBitsFromRangeMetadata(*MD, Known);
|
2014-05-15 14:12:55 +02:00
|
|
|
break;
|
2008-06-02 03:18:21 +02:00
|
|
|
case Instruction::And: {
|
|
|
|
// If either the LHS or the RHS are Zero, the result is zero.
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(I->getOperand(1), Known, Depth + 1, Q);
|
|
|
|
computeKnownBits(I->getOperand(0), Known2, Depth + 1, Q);
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2008-06-02 03:18:21 +02:00
|
|
|
// Output known-1 bits are only known if set in both the LHS & RHS.
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.One &= Known2.One;
|
2008-06-02 03:18:21 +02:00
|
|
|
// Output known-0 are known to be clear if zero in either the LHS | RHS.
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero |= Known2.Zero;
|
2015-11-10 19:46:14 +01:00
|
|
|
|
|
|
|
// and(x, add (x, -1)) is a common idiom that always clears the low bit;
|
|
|
|
// here we handle the more general case of adding any odd number by
|
|
|
|
// matching the form add(x, add(x, y)) where y is odd.
|
|
|
|
// TODO: This could be generalized to clearing any bit set in y where the
|
|
|
|
// following bit is known to be unset in y.
|
[PatternMatch] Stabilize the matching order of commutative matchers
Summary:
Currently, we
1. match `LHS` matcher to the `first` operand of binary operator,
2. and then match `RHS` matcher to the `second` operand of binary operator.
If that does not match, we swap the `LHS` and `RHS` matchers:
1. match `RHS` matcher to the `first` operand of binary operator,
2. and then match `LHS` matcher to the `second` operand of binary operator.
This works ok.
But it complicates writing of commutative matchers, where one would like to match
(`m_Value()`) the value on one side, and use (`m_Specific()`) it on the other side.
This is additionally complicated by the fact that `m_Specific()` stores the `Value *`,
not `Value **`, so it won't work at all out of the box.
The last problem is trivially solved by adding a new `m_c_Specific()` that stores the
`Value **`, not `Value *`. I'm choosing to add a new matcher, not change the existing
one because i guess all the current users are ok with existing behavior,
and this additional pointer indirection may have performance drawbacks.
Also, i'm storing pointer, not reference, because for some mysterious-to-me reason
it did not work with the reference.
The first one appears trivial, too.
Currently, we
1. match `LHS` matcher to the `first` operand of binary operator,
2. and then match `RHS` matcher to the `second` operand of binary operator.
If that does not match, we swap the ~~`LHS` and `RHS` matchers~~ **operands**:
1. match ~~`RHS`~~ **`LHS`** matcher to the ~~`first`~~ **`second`** operand of binary operator,
2. and then match ~~`LHS`~~ **`RHS`** matcher to the ~~`second`~ **`first`** operand of binary operator.
Surprisingly, `$ ninja check-llvm` still passes with this.
But i expect the bots will disagree..
The motivational unittest is included.
I'd like to use this in D45664.
Reviewers: spatel, craig.topper, arsenm, RKSimon
Reviewed By: craig.topper
Subscribers: xbolva00, wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D45828
llvm-svn: 331085
2018-04-27 23:23:20 +02:00
|
|
|
Value *X = nullptr, *Y = nullptr;
|
2017-04-26 18:39:58 +02:00
|
|
|
if (!Known.Zero[0] && !Known.One[0] &&
|
[PatternMatch] Stabilize the matching order of commutative matchers
Summary:
Currently, we
1. match `LHS` matcher to the `first` operand of binary operator,
2. and then match `RHS` matcher to the `second` operand of binary operator.
If that does not match, we swap the `LHS` and `RHS` matchers:
1. match `RHS` matcher to the `first` operand of binary operator,
2. and then match `LHS` matcher to the `second` operand of binary operator.
This works ok.
But it complicates writing of commutative matchers, where one would like to match
(`m_Value()`) the value on one side, and use (`m_Specific()`) it on the other side.
This is additionally complicated by the fact that `m_Specific()` stores the `Value *`,
not `Value **`, so it won't work at all out of the box.
The last problem is trivially solved by adding a new `m_c_Specific()` that stores the
`Value **`, not `Value *`. I'm choosing to add a new matcher, not change the existing
one because i guess all the current users are ok with existing behavior,
and this additional pointer indirection may have performance drawbacks.
Also, i'm storing pointer, not reference, because for some mysterious-to-me reason
it did not work with the reference.
The first one appears trivial, too.
Currently, we
1. match `LHS` matcher to the `first` operand of binary operator,
2. and then match `RHS` matcher to the `second` operand of binary operator.
If that does not match, we swap the ~~`LHS` and `RHS` matchers~~ **operands**:
1. match ~~`RHS`~~ **`LHS`** matcher to the ~~`first`~~ **`second`** operand of binary operator,
2. and then match ~~`LHS`~~ **`RHS`** matcher to the ~~`second`~ **`first`** operand of binary operator.
Surprisingly, `$ ninja check-llvm` still passes with this.
But i expect the bots will disagree..
The motivational unittest is included.
I'd like to use this in D45664.
Reviewers: spatel, craig.topper, arsenm, RKSimon
Reviewed By: craig.topper
Subscribers: xbolva00, wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D45828
llvm-svn: 331085
2018-04-27 23:23:20 +02:00
|
|
|
match(I, m_c_BinOp(m_Value(X), m_Add(m_Deferred(X), m_Value(Y))))) {
|
2017-05-05 19:36:09 +02:00
|
|
|
Known2.resetAll();
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(Y, Known2, Depth + 1, Q);
|
2017-05-12 19:20:30 +02:00
|
|
|
if (Known2.countMinTrailingOnes() > 0)
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero.setBit(0);
|
2015-11-10 19:46:14 +01:00
|
|
|
}
|
2014-05-15 14:12:55 +02:00
|
|
|
break;
|
2008-06-02 03:18:21 +02:00
|
|
|
}
|
2017-09-01 23:37:29 +02:00
|
|
|
case Instruction::Or:
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(I->getOperand(1), Known, Depth + 1, Q);
|
|
|
|
computeKnownBits(I->getOperand(0), Known2, Depth + 1, Q);
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2008-06-02 03:18:21 +02:00
|
|
|
// Output known-0 bits are only known if clear in both the LHS & RHS.
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero &= Known2.Zero;
|
2008-06-02 03:18:21 +02:00
|
|
|
// Output known-1 are known to be set if set in either the LHS | RHS.
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.One |= Known2.One;
|
2014-05-15 14:12:55 +02:00
|
|
|
break;
|
2008-06-02 03:18:21 +02:00
|
|
|
case Instruction::Xor: {
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(I->getOperand(1), Known, Depth + 1, Q);
|
|
|
|
computeKnownBits(I->getOperand(0), Known2, Depth + 1, Q);
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2008-06-02 03:18:21 +02:00
|
|
|
// Output known-0 bits are known if clear or set in both the LHS & RHS.
|
2017-04-26 18:39:58 +02:00
|
|
|
APInt KnownZeroOut = (Known.Zero & Known2.Zero) | (Known.One & Known2.One);
|
2008-06-02 03:18:21 +02:00
|
|
|
// Output known-1 are known to be set if set in only one of the LHS, RHS.
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.One = (Known.Zero & Known2.One) | (Known.One & Known2.Zero);
|
|
|
|
Known.Zero = std::move(KnownZeroOut);
|
2014-05-15 14:12:55 +02:00
|
|
|
break;
|
2008-06-02 03:18:21 +02:00
|
|
|
}
|
|
|
|
case Instruction::Mul: {
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
bool NSW = Q.IIQ.hasNoSignedWrap(cast<OverflowingBinaryOperator>(I));
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBitsMul(I->getOperand(0), I->getOperand(1), NSW, Known,
|
|
|
|
Known2, Depth, Q);
|
2012-03-19 00:28:48 +01:00
|
|
|
break;
|
2008-06-02 03:18:21 +02: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.
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(I->getOperand(0), Known2, Depth + 1, Q);
|
2017-05-12 19:20:30 +02:00
|
|
|
unsigned LeadZ = Known2.countMinLeadingZeros();
|
2008-06-02 03:18:21 +02:00
|
|
|
|
2017-05-05 19:36:09 +02:00
|
|
|
Known2.resetAll();
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(I->getOperand(1), Known2, Depth + 1, Q);
|
2017-05-12 19:20:30 +02:00
|
|
|
unsigned RHSMaxLeadingZeros = Known2.countMaxLeadingZeros();
|
|
|
|
if (RHSMaxLeadingZeros != BitWidth)
|
|
|
|
LeadZ = std::min(BitWidth, LeadZ + BitWidth - RHSMaxLeadingZeros - 1);
|
2008-06-02 03:18:21 +02:00
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero.setHighBits(LeadZ);
|
2014-05-15 14:12:55 +02:00
|
|
|
break;
|
2008-06-02 03:18:21 +02:00
|
|
|
}
|
2016-08-06 10:16:00 +02:00
|
|
|
case Instruction::Select: {
|
2017-04-13 22:39:37 +02:00
|
|
|
const Value *LHS, *RHS;
|
2016-08-06 10:16:00 +02:00
|
|
|
SelectPatternFlavor SPF = matchSelectPattern(I, LHS, RHS).Flavor;
|
|
|
|
if (SelectPatternResult::isMinOrMax(SPF)) {
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(RHS, Known, Depth + 1, Q);
|
|
|
|
computeKnownBits(LHS, Known2, Depth + 1, Q);
|
2016-08-06 10:16:00 +02:00
|
|
|
} else {
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(I->getOperand(2), Known, Depth + 1, Q);
|
|
|
|
computeKnownBits(I->getOperand(1), Known2, Depth + 1, Q);
|
2016-08-06 10:16:00 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
unsigned MaxHighOnes = 0;
|
|
|
|
unsigned MaxHighZeros = 0;
|
|
|
|
if (SPF == SPF_SMAX) {
|
|
|
|
// If both sides are negative, the result is negative.
|
2017-04-29 18:43:11 +02:00
|
|
|
if (Known.isNegative() && Known2.isNegative())
|
2016-08-06 10:16:00 +02:00
|
|
|
// We can derive a lower bound on the result by taking the max of the
|
|
|
|
// leading one bits.
|
2017-05-12 19:20:30 +02:00
|
|
|
MaxHighOnes =
|
|
|
|
std::max(Known.countMinLeadingOnes(), Known2.countMinLeadingOnes());
|
2016-08-06 10:16:00 +02:00
|
|
|
// If either side is non-negative, the result is non-negative.
|
2017-04-29 18:43:11 +02:00
|
|
|
else if (Known.isNonNegative() || Known2.isNonNegative())
|
2016-08-06 10:16:00 +02:00
|
|
|
MaxHighZeros = 1;
|
|
|
|
} else if (SPF == SPF_SMIN) {
|
|
|
|
// If both sides are non-negative, the result is non-negative.
|
2017-04-29 18:43:11 +02:00
|
|
|
if (Known.isNonNegative() && Known2.isNonNegative())
|
2016-08-06 10:16:00 +02:00
|
|
|
// We can derive an upper bound on the result by taking the max of the
|
|
|
|
// leading zero bits.
|
2017-05-12 19:20:30 +02:00
|
|
|
MaxHighZeros = std::max(Known.countMinLeadingZeros(),
|
|
|
|
Known2.countMinLeadingZeros());
|
2016-08-06 10:16:00 +02:00
|
|
|
// If either side is negative, the result is negative.
|
2017-04-29 18:43:11 +02:00
|
|
|
else if (Known.isNegative() || Known2.isNegative())
|
2016-08-06 10:16:00 +02:00
|
|
|
MaxHighOnes = 1;
|
|
|
|
} else if (SPF == SPF_UMAX) {
|
|
|
|
// We can derive a lower bound on the result by taking the max of the
|
|
|
|
// leading one bits.
|
|
|
|
MaxHighOnes =
|
2017-05-12 19:20:30 +02:00
|
|
|
std::max(Known.countMinLeadingOnes(), Known2.countMinLeadingOnes());
|
2016-08-06 10:16:00 +02:00
|
|
|
} else if (SPF == SPF_UMIN) {
|
|
|
|
// We can derive an upper bound on the result by taking the max of the
|
|
|
|
// leading zero bits.
|
|
|
|
MaxHighZeros =
|
2017-05-12 19:20:30 +02:00
|
|
|
std::max(Known.countMinLeadingZeros(), Known2.countMinLeadingZeros());
|
2018-05-25 21:18:09 +02:00
|
|
|
} else if (SPF == SPF_ABS) {
|
|
|
|
// RHS from matchSelectPattern returns the negation part of abs pattern.
|
|
|
|
// If the negate has an NSW flag we can assume the sign bit of the result
|
|
|
|
// will be 0 because that makes abs(INT_MIN) undefined.
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
if (Q.IIQ.hasNoSignedWrap(cast<Instruction>(RHS)))
|
2018-05-25 21:18:09 +02:00
|
|
|
MaxHighZeros = 1;
|
2016-08-06 10:16:00 +02:00
|
|
|
}
|
|
|
|
|
2008-06-02 03:18:21 +02:00
|
|
|
// Only known if known in both the LHS and RHS.
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.One &= Known2.One;
|
|
|
|
Known.Zero &= Known2.Zero;
|
2016-08-06 10:16:00 +02:00
|
|
|
if (MaxHighOnes > 0)
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.One.setHighBits(MaxHighOnes);
|
2016-08-06 10:16:00 +02:00
|
|
|
if (MaxHighZeros > 0)
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero.setHighBits(MaxHighZeros);
|
2014-05-15 14:12:55 +02:00
|
|
|
break;
|
2016-08-06 10:16:00 +02:00
|
|
|
}
|
2008-06-02 03:18:21 +02:00
|
|
|
case Instruction::FPTrunc:
|
|
|
|
case Instruction::FPExt:
|
|
|
|
case Instruction::FPToUI:
|
|
|
|
case Instruction::FPToSI:
|
|
|
|
case Instruction::SIToFP:
|
|
|
|
case Instruction::UIToFP:
|
2014-05-15 14:12:55 +02:00
|
|
|
break; // Can't work with floating point.
|
2008-06-02 03:18:21 +02:00
|
|
|
case Instruction::PtrToInt:
|
|
|
|
case Instruction::IntToPtr:
|
2016-08-17 22:30:52 +02:00
|
|
|
// Fall through and handle them the same as zext/trunc.
|
|
|
|
LLVM_FALLTHROUGH;
|
2008-06-02 03:18:21 +02:00
|
|
|
case Instruction::ZExt:
|
|
|
|
case Instruction::Trunc: {
|
2011-07-18 06:54:35 +02:00
|
|
|
Type *SrcTy = I->getOperand(0)->getType();
|
2012-10-26 19:17:05 +02:00
|
|
|
|
2009-09-08 02:13:52 +02:00
|
|
|
unsigned SrcBitWidth;
|
2008-06-02 03:18:21 +02:00
|
|
|
// Note that we handle pointer operands here because of inttoptr/ptrtoint
|
|
|
|
// which fall through here.
|
2018-02-14 07:58:08 +01:00
|
|
|
Type *ScalarTy = SrcTy->getScalarType();
|
|
|
|
SrcBitWidth = ScalarTy->isPointerTy() ?
|
|
|
|
Q.DL.getIndexTypeSizeInBits(ScalarTy) :
|
|
|
|
Q.DL.getTypeSizeInBits(ScalarTy);
|
2012-10-26 19:17:05 +02:00
|
|
|
|
|
|
|
assert(SrcBitWidth && "SrcBitWidth can't be zero");
|
2017-05-04 00:07:25 +02:00
|
|
|
Known = Known.zextOrTrunc(SrcBitWidth);
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(I->getOperand(0), Known, Depth + 1, Q);
|
2017-05-04 00:07:25 +02:00
|
|
|
Known = Known.zextOrTrunc(BitWidth);
|
2008-06-02 03:18:21 +02:00
|
|
|
// Any top bits are known to be zero.
|
|
|
|
if (BitWidth > SrcBitWidth)
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero.setBitsFrom(SrcBitWidth);
|
2014-05-15 14:12:55 +02:00
|
|
|
break;
|
2008-06-02 03:18:21 +02:00
|
|
|
}
|
|
|
|
case Instruction::BitCast: {
|
2011-07-18 06:54:35 +02:00
|
|
|
Type *SrcTy = I->getOperand(0)->getType();
|
2018-07-06 22:17:42 +02:00
|
|
|
if (SrcTy->isIntOrPtrTy() &&
|
2009-07-02 18:04:08 +02:00
|
|
|
// TODO: For now, not handling conversions like:
|
|
|
|
// (bitcast i64 %x to <2 x i32>)
|
2010-02-16 12:11:14 +01:00
|
|
|
!I->getType()->isVectorTy()) {
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(I->getOperand(0), Known, Depth + 1, Q);
|
2014-05-15 14:12:55 +02:00
|
|
|
break;
|
2008-06-02 03:18:21 +02:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case Instruction::SExt: {
|
|
|
|
// Compute the bits in the result that are not present in the input.
|
2009-09-08 02:13:52 +02:00
|
|
|
unsigned SrcBitWidth = I->getOperand(0)->getType()->getScalarSizeInBits();
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2017-05-04 00:07:25 +02:00
|
|
|
Known = Known.trunc(SrcBitWidth);
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(I->getOperand(0), Known, Depth + 1, Q);
|
2008-06-02 03:18:21 +02:00
|
|
|
// If the sign bit of the input is known set or clear, then we know the
|
|
|
|
// top bits of the result.
|
2017-05-04 00:07:25 +02:00
|
|
|
Known = Known.sext(BitWidth);
|
2014-05-15 14:12:55 +02:00
|
|
|
break;
|
2008-06-02 03:18:21 +02:00
|
|
|
}
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
case Instruction::Shl: {
|
2012-09-27 12:14:43 +02:00
|
|
|
// (shl X, C1) & C2 == 0 iff (X & C2 >>u C1) == 0
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
bool NSW = Q.IIQ.hasNoSignedWrap(cast<OverflowingBinaryOperator>(I));
|
2017-12-04 13:51:49 +01:00
|
|
|
auto KZF = [NSW](const APInt &KnownZero, unsigned ShiftAmt) {
|
|
|
|
APInt KZResult = KnownZero << ShiftAmt;
|
|
|
|
KZResult.setLowBits(ShiftAmt); // Low bits known 0.
|
2016-08-25 01:01:33 +02:00
|
|
|
// If this shift has "nsw" keyword, then the result is either a poison
|
|
|
|
// value or has the same sign bit as the first operand.
|
2017-12-04 13:51:49 +01:00
|
|
|
if (NSW && KnownZero.isSignBitSet())
|
|
|
|
KZResult.setSignBit();
|
|
|
|
return KZResult;
|
|
|
|
};
|
|
|
|
|
|
|
|
auto KOF = [NSW](const APInt &KnownOne, unsigned ShiftAmt) {
|
|
|
|
APInt KOResult = KnownOne << ShiftAmt;
|
|
|
|
if (NSW && KnownOne.isSignBitSet())
|
|
|
|
KOResult.setSignBit();
|
|
|
|
return KOResult;
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
};
|
|
|
|
|
2017-12-04 13:51:49 +01:00
|
|
|
computeKnownBitsFromShiftOperator(I, Known, Known2, Depth, Q, KZF, KOF);
|
2008-06-02 03:18:21 +02:00
|
|
|
break;
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
}
|
|
|
|
case Instruction::LShr: {
|
2017-10-16 16:46:37 +02:00
|
|
|
// (lshr X, C1) & C2 == 0 iff (-1 >> C1) & C2 == 0
|
2017-12-04 13:51:49 +01:00
|
|
|
auto KZF = [](const APInt &KnownZero, unsigned ShiftAmt) {
|
|
|
|
APInt KZResult = KnownZero.lshr(ShiftAmt);
|
|
|
|
// High bits known zero.
|
|
|
|
KZResult.setHighBits(ShiftAmt);
|
|
|
|
return KZResult;
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
};
|
|
|
|
|
2017-12-04 13:51:49 +01:00
|
|
|
auto KOF = [](const APInt &KnownOne, unsigned ShiftAmt) {
|
|
|
|
return KnownOne.lshr(ShiftAmt);
|
|
|
|
};
|
|
|
|
|
|
|
|
computeKnownBitsFromShiftOperator(I, Known, Known2, Depth, Q, KZF, KOF);
|
2008-06-02 03:18:21 +02:00
|
|
|
break;
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
}
|
|
|
|
case Instruction::AShr: {
|
2012-09-27 12:14:43 +02:00
|
|
|
// (ashr X, C1) & C2 == 0 iff (-1 >> C1) & C2 == 0
|
2017-12-04 13:51:49 +01:00
|
|
|
auto KZF = [](const APInt &KnownZero, unsigned ShiftAmt) {
|
|
|
|
return KnownZero.ashr(ShiftAmt);
|
|
|
|
};
|
|
|
|
|
|
|
|
auto KOF = [](const APInt &KnownOne, unsigned ShiftAmt) {
|
|
|
|
return KnownOne.ashr(ShiftAmt);
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
};
|
|
|
|
|
2017-12-04 13:51:49 +01:00
|
|
|
computeKnownBitsFromShiftOperator(I, Known, Known2, Depth, Q, KZF, KOF);
|
2008-06-02 03:18:21 +02:00
|
|
|
break;
|
Handle non-constant shifts in computeKnownBits, and use computeKnownBits for constant folding in InstCombine/Simplify
First, the motivation: LLVM currently does not realize that:
((2072 >> (L == 0)) >> 7) & 1 == 0
where L is some arbitrary value. Whether you right-shift 2072 by 7 or by 8, the
lowest-order bit is always zero. There are obviously several ways to go about
fixing this, but the generic solution pursued in this patch is to teach
computeKnownBits something about shifts by a non-constant amount. Previously,
we would give up completely on these. Instead, in cases where we know something
about the low-order bits of the shift-amount operand, we can combine (and
together) the associated restrictions for all shift amounts consistent with
that knowledge. As a further generalization, I refactored all of the logic for
all three kinds of shifts to have this capability. This works well in the above
case, for example, because the dynamic shift amount can only be 0 or 1, and
thus we can say a lot about the known bits of the result.
This brings us to the second part of this change: Even when we know all of the
bits of a value via computeKnownBits, nothing used to constant-fold the result.
This introduces the necessary code into InstCombine and InstSimplify. I've
added it into both because:
1. InstCombine won't automatically pick up the associated logic in
InstSimplify (InstCombine uses InstSimplify, but not via the API that
passes in the original instruction).
2. Putting the logic in InstCombine allows the resulting simplifications to become
part of the iterative worklist
3. Putting the logic in InstSimplify allows the resulting simplifications to be
used by everywhere else that calls SimplifyInstruction (inlining, unrolling,
and many others).
And this requires a small change to our definition of an ephemeral value so
that we don't break the rest case from r246696 (where the icmp feeding the
@llvm.assume, is also feeding a br). Under the old definition, the icmp would
not be considered ephemeral (because it is used by the br), but this causes the
assume to remove itself (in addition to simplifying the branch structure), and
it seems more-useful to prevent that from happening.
llvm-svn: 251146
2015-10-23 22:37:08 +02:00
|
|
|
}
|
2008-06-02 03:18:21 +02:00
|
|
|
case Instruction::Sub: {
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
bool NSW = Q.IIQ.hasNoSignedWrap(cast<OverflowingBinaryOperator>(I));
|
2014-05-14 23:14:37 +02:00
|
|
|
computeKnownBitsAddSub(false, I->getOperand(0), I->getOperand(1), NSW,
|
2017-04-26 18:39:58 +02:00
|
|
|
Known, Known2, Depth, Q);
|
2012-03-09 10:23:50 +01:00
|
|
|
break;
|
2008-06-02 03:18:21 +02:00
|
|
|
}
|
|
|
|
case Instruction::Add: {
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
bool NSW = Q.IIQ.hasNoSignedWrap(cast<OverflowingBinaryOperator>(I));
|
2014-05-14 23:14:37 +02:00
|
|
|
computeKnownBitsAddSub(true, I->getOperand(0), I->getOperand(1), NSW,
|
2017-04-26 18:39:58 +02:00
|
|
|
Known, Known2, Depth, Q);
|
2012-03-09 10:23:50 +01:00
|
|
|
break;
|
2008-06-02 03:18:21 +02:00
|
|
|
}
|
|
|
|
case Instruction::SRem:
|
|
|
|
if (ConstantInt *Rem = dyn_cast<ConstantInt>(I->getOperand(1))) {
|
2010-01-29 07:18:37 +01:00
|
|
|
APInt RA = Rem->getValue().abs();
|
|
|
|
if (RA.isPowerOf2()) {
|
|
|
|
APInt LowBits = RA - 1;
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(I->getOperand(0), Known2, Depth + 1, Q);
|
2008-06-02 03:18:21 +02:00
|
|
|
|
2010-01-29 07:18:37 +01:00
|
|
|
// The low bits of the first operand are unchanged by the srem.
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero = Known2.Zero & LowBits;
|
|
|
|
Known.One = Known2.One & LowBits;
|
2010-01-29 07:18:37 +01:00
|
|
|
|
|
|
|
// If the first operand is non-negative or has all low bits zero, then
|
|
|
|
// the upper bits are all zero.
|
2017-04-29 18:43:11 +02:00
|
|
|
if (Known2.isNonNegative() || LowBits.isSubsetOf(Known2.Zero))
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero |= ~LowBits;
|
2008-06-02 03:18:21 +02:00
|
|
|
|
2010-01-29 07:18:37 +01:00
|
|
|
// If the first operand is negative and not all low bits are zero, then
|
|
|
|
// the upper bits are all one.
|
2017-04-29 18:43:11 +02:00
|
|
|
if (Known2.isNegative() && LowBits.intersects(Known2.One))
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.One |= ~LowBits;
|
2010-01-29 07:18:37 +01:00
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
assert((Known.Zero & Known.One) == 0 && "Bits known to be one AND zero?");
|
2017-04-16 23:46:12 +02:00
|
|
|
break;
|
2008-06-02 03:18:21 +02:00
|
|
|
}
|
|
|
|
}
|
2011-03-07 02:50:10 +01:00
|
|
|
|
|
|
|
// The sign bit is the LHS's sign bit, except when the result of the
|
|
|
|
// remainder is zero.
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(I->getOperand(0), Known2, Depth + 1, Q);
|
2017-04-16 23:46:12 +02:00
|
|
|
// If it's known zero, our sign bit is also zero.
|
2017-04-29 18:43:11 +02:00
|
|
|
if (Known2.isNonNegative())
|
|
|
|
Known.makeNonNegative();
|
2011-03-07 02:50:10 +01:00
|
|
|
|
2008-06-02 03:18:21 +02:00
|
|
|
break;
|
|
|
|
case Instruction::URem: {
|
|
|
|
if (ConstantInt *Rem = dyn_cast<ConstantInt>(I->getOperand(1))) {
|
2016-06-08 12:01:20 +02:00
|
|
|
const APInt &RA = Rem->getValue();
|
2008-06-02 03:18:21 +02:00
|
|
|
if (RA.isPowerOf2()) {
|
|
|
|
APInt LowBits = (RA - 1);
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(I->getOperand(0), Known, Depth + 1, Q);
|
|
|
|
Known.Zero |= ~LowBits;
|
|
|
|
Known.One &= LowBits;
|
2008-06-02 03:18:21 +02: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.
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(I->getOperand(0), Known, Depth + 1, Q);
|
|
|
|
computeKnownBits(I->getOperand(1), Known2, Depth + 1, Q);
|
|
|
|
|
2017-05-12 19:20:30 +02:00
|
|
|
unsigned Leaders =
|
|
|
|
std::max(Known.countMinLeadingZeros(), Known2.countMinLeadingZeros());
|
2017-05-05 19:36:09 +02:00
|
|
|
Known.resetAll();
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero.setHighBits(Leaders);
|
2008-06-02 03:18:21 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2009-10-17 03:18:07 +02:00
|
|
|
case Instruction::Alloca: {
|
2016-08-13 03:05:32 +02:00
|
|
|
const AllocaInst *AI = cast<AllocaInst>(I);
|
2008-06-02 03:18:21 +02:00
|
|
|
unsigned Align = AI->getAlignment();
|
2015-03-10 03:37:25 +01:00
|
|
|
if (Align == 0)
|
2016-01-18 01:10:01 +01:00
|
|
|
Align = Q.DL.getABITypeAlignment(AI->getAllocatedType());
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2008-06-02 03:18:21 +02:00
|
|
|
if (Align > 0)
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero.setLowBits(countTrailingZeros(Align));
|
2008-06-02 03:18:21 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case Instruction::GetElementPtr: {
|
|
|
|
// Analyze all of the subscripts of this getelementptr instruction
|
|
|
|
// to determine if we can prove known low zero bits.
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits LocalKnown(BitWidth);
|
|
|
|
computeKnownBits(I->getOperand(0), LocalKnown, Depth + 1, Q);
|
2017-05-12 19:20:30 +02:00
|
|
|
unsigned TrailZ = LocalKnown.countMinTrailingZeros();
|
2008-06-02 03:18:21 +02:00
|
|
|
|
|
|
|
gep_type_iterator GTI = gep_type_begin(I);
|
|
|
|
for (unsigned i = 1, e = I->getNumOperands(); i != e; ++i, ++GTI) {
|
|
|
|
Value *Index = I->getOperand(i);
|
2016-12-02 03:24:42 +01:00
|
|
|
if (StructType *STy = GTI.getStructTypeOrNull()) {
|
2008-06-02 03:18:21 +02:00
|
|
|
// Handle struct member offset arithmetic.
|
2013-08-19 23:43:16 +02: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 03:18:21 +02:00
|
|
|
unsigned Idx = cast<ConstantInt>(Index)->getZExtValue();
|
2016-01-15 23:22:04 +01:00
|
|
|
const StructLayout *SL = Q.DL.getStructLayout(STy);
|
2008-06-02 03:18:21 +02:00
|
|
|
uint64_t Offset = SL->getElementOffset(Idx);
|
2013-05-25 00:23:49 +02:00
|
|
|
TrailZ = std::min<unsigned>(TrailZ,
|
|
|
|
countTrailingZeros(Offset));
|
2008-06-02 03:18:21 +02:00
|
|
|
} else {
|
|
|
|
// Handle array index arithmetic.
|
2011-07-18 06:54:35 +02:00
|
|
|
Type *IndexedTy = GTI.getIndexedType();
|
2014-05-15 14:12:55 +02:00
|
|
|
if (!IndexedTy->isSized()) {
|
|
|
|
TrailZ = 0;
|
|
|
|
break;
|
|
|
|
}
|
2009-06-16 00:12:54 +02:00
|
|
|
unsigned GEPOpiBits = Index->getType()->getScalarSizeInBits();
|
2016-01-15 23:22:04 +01:00
|
|
|
uint64_t TypeSize = Q.DL.getTypeAllocSize(IndexedTy);
|
2017-04-26 18:39:58 +02:00
|
|
|
LocalKnown.Zero = LocalKnown.One = APInt(GEPOpiBits, 0);
|
|
|
|
computeKnownBits(Index, LocalKnown, Depth + 1, Q);
|
2008-06-02 03:18:21 +02:00
|
|
|
TrailZ = std::min(TrailZ,
|
2013-05-25 00:23:49 +02:00
|
|
|
unsigned(countTrailingZeros(TypeSize) +
|
2017-05-12 19:20:30 +02:00
|
|
|
LocalKnown.countMinTrailingZeros()));
|
2008-06-02 03:18:21 +02:00
|
|
|
}
|
|
|
|
}
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero.setLowBits(TrailZ);
|
2008-06-02 03:18:21 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case Instruction::PHI: {
|
2016-08-13 03:05:32 +02:00
|
|
|
const PHINode *P = cast<PHINode>(I);
|
2008-06-02 03:18:21 +02:00
|
|
|
// 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-17 22:47:02 +02:00
|
|
|
Operator *LU = dyn_cast<Operator>(L);
|
2008-06-02 03:18:21 +02:00
|
|
|
if (!LU)
|
|
|
|
continue;
|
2009-07-17 22:47:02 +02:00
|
|
|
unsigned Opcode = LU->getOpcode();
|
2008-06-02 03:18:21 +02:00
|
|
|
// Check for operations that have the property that if
|
|
|
|
// both their operands have low zero bits, the result
|
2016-08-22 15:14:07 +02:00
|
|
|
// will have low zero bits.
|
2008-06-02 03:18:21 +02:00
|
|
|
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.
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(R, Known2, Depth + 1, Q);
|
2008-10-28 00:24:03 +01:00
|
|
|
|
|
|
|
// We need to take the minimum number of known bits
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits Known3(Known);
|
|
|
|
computeKnownBits(L, Known3, Depth + 1, Q);
|
2008-10-28 00:24:03 +01:00
|
|
|
|
2017-05-12 19:20:30 +02:00
|
|
|
Known.Zero.setLowBits(std::min(Known2.countMinTrailingZeros(),
|
|
|
|
Known3.countMinTrailingZeros()));
|
2016-10-12 18:18:43 +02:00
|
|
|
|
|
|
|
auto *OverflowOp = dyn_cast<OverflowingBinaryOperator>(LU);
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
if (OverflowOp && Q.IIQ.hasNoSignedWrap(OverflowOp)) {
|
2016-10-12 18:18:43 +02:00
|
|
|
// If initial value of recurrence is nonnegative, and we are adding
|
|
|
|
// a nonnegative number with nsw, the result can only be nonnegative
|
|
|
|
// or poison value regardless of the number of times we execute the
|
|
|
|
// add in phi recurrence. If initial value is negative and we are
|
|
|
|
// adding a negative number with nsw, the result can only be
|
|
|
|
// negative or poison value. Similar arguments apply to sub and mul.
|
|
|
|
//
|
|
|
|
// (add non-negative, non-negative) --> non-negative
|
|
|
|
// (add negative, negative) --> negative
|
|
|
|
if (Opcode == Instruction::Add) {
|
2017-04-29 18:43:11 +02:00
|
|
|
if (Known2.isNonNegative() && Known3.isNonNegative())
|
|
|
|
Known.makeNonNegative();
|
|
|
|
else if (Known2.isNegative() && Known3.isNegative())
|
|
|
|
Known.makeNegative();
|
2016-10-12 18:18:43 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// (sub nsw non-negative, negative) --> non-negative
|
|
|
|
// (sub nsw negative, non-negative) --> negative
|
|
|
|
else if (Opcode == Instruction::Sub && LL == I) {
|
2017-04-29 18:43:11 +02:00
|
|
|
if (Known2.isNonNegative() && Known3.isNegative())
|
|
|
|
Known.makeNonNegative();
|
|
|
|
else if (Known2.isNegative() && Known3.isNonNegative())
|
|
|
|
Known.makeNegative();
|
2016-10-12 18:18:43 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// (mul nsw non-negative, non-negative) --> non-negative
|
2017-04-29 18:43:11 +02:00
|
|
|
else if (Opcode == Instruction::Mul && Known2.isNonNegative() &&
|
|
|
|
Known3.isNonNegative())
|
|
|
|
Known.makeNonNegative();
|
2016-10-12 18:18:43 +02:00
|
|
|
}
|
|
|
|
|
2008-06-02 03:18:21 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2009-05-21 04:28:33 +02:00
|
|
|
|
2011-02-11 00:54:10 +01:00
|
|
|
// Unreachable blocks may have zero-operand PHI nodes.
|
|
|
|
if (P->getNumIncomingValues() == 0)
|
2014-05-15 14:12:55 +02:00
|
|
|
break;
|
2011-02-11 00:54:10 +01:00
|
|
|
|
2009-05-21 04:28:33 +02:00
|
|
|
// Otherwise take the unions of the known bit sets of the operands,
|
|
|
|
// taking conservative care to avoid excessive recursion.
|
2017-04-26 18:39:58 +02:00
|
|
|
if (Depth < MaxDepth - 1 && !Known.Zero && !Known.One) {
|
2011-03-08 13:39:03 +01:00
|
|
|
// Skip if every incoming value references to ourself.
|
2012-07-03 23:15:40 +02:00
|
|
|
if (dyn_cast_or_null<UndefValue>(P->hasConstantValue()))
|
2011-03-08 13:39:03 +01:00
|
|
|
break;
|
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero.setAllBits();
|
|
|
|
Known.One.setAllBits();
|
2015-05-12 22:05:31 +02:00
|
|
|
for (Value *IncValue : P->incoming_values()) {
|
2009-05-21 04:28:33 +02:00
|
|
|
// Skip direct self references.
|
2015-05-12 22:05:31 +02:00
|
|
|
if (IncValue == P) continue;
|
2009-05-21 04:28:33 +02:00
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
Known2 = KnownBits(BitWidth);
|
2009-05-21 04:28:33 +02:00
|
|
|
// Recurse, but cap the recursion to one level, because we don't
|
|
|
|
// want to waste time spinning around in loops.
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(IncValue, Known2, MaxDepth - 1, Q);
|
|
|
|
Known.Zero &= Known2.Zero;
|
|
|
|
Known.One &= Known2.One;
|
2009-05-21 04:28:33 +02:00
|
|
|
// If all bits have been ruled out, there's no need to check
|
|
|
|
// more operands.
|
2017-04-26 18:39:58 +02:00
|
|
|
if (!Known.Zero && !Known.One)
|
2009-05-21 04:28:33 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2008-06-02 03:18:21 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case Instruction::Call:
|
2014-06-19 18:50:16 +02:00
|
|
|
case Instruction::Invoke:
|
2016-07-11 04:25:14 +02:00
|
|
|
// If range metadata is attached to this call, set known bits from that,
|
|
|
|
// and then intersect with known bits based on other properties of the
|
|
|
|
// function.
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
if (MDNode *MD =
|
|
|
|
Q.IIQ.getMetadata(cast<Instruction>(I), LLVMContext::MD_range))
|
2017-04-28 08:28:56 +02:00
|
|
|
computeKnownBitsFromRangeMetadata(*MD, Known);
|
2016-08-13 03:05:32 +02:00
|
|
|
if (const Value *RV = ImmutableCallSite(I).getReturnedArgOperand()) {
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(RV, Known2, Depth + 1, Q);
|
|
|
|
Known.Zero |= Known2.Zero;
|
|
|
|
Known.One |= Known2.One;
|
2016-07-11 04:25:14 +02:00
|
|
|
}
|
2016-08-13 03:05:32 +02:00
|
|
|
if (const IntrinsicInst *II = dyn_cast<IntrinsicInst>(I)) {
|
2008-06-02 03:18:21 +02:00
|
|
|
switch (II->getIntrinsicID()) {
|
|
|
|
default: break;
|
2017-01-17 18:23:51 +01:00
|
|
|
case Intrinsic::bitreverse:
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(I->getOperand(0), Known2, Depth + 1, Q);
|
|
|
|
Known.Zero |= Known2.Zero.reverseBits();
|
|
|
|
Known.One |= Known2.One.reverseBits();
|
2017-01-17 18:23:51 +01:00
|
|
|
break;
|
2015-10-06 22:20:45 +02:00
|
|
|
case Intrinsic::bswap:
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(I->getOperand(0), Known2, Depth + 1, Q);
|
|
|
|
Known.Zero |= Known2.Zero.byteSwap();
|
|
|
|
Known.One |= Known2.One.byteSwap();
|
2015-10-06 22:20:45 +02:00
|
|
|
break;
|
2017-05-08 19:22:34 +02:00
|
|
|
case Intrinsic::ctlz: {
|
|
|
|
computeKnownBits(I->getOperand(0), Known2, Depth + 1, Q);
|
|
|
|
// If we have a known 1, its position is our upper bound.
|
|
|
|
unsigned PossibleLZ = Known2.One.countLeadingZeros();
|
|
|
|
// If this call is undefined for 0, the result will be less than 2^n.
|
|
|
|
if (II->getArgOperand(1) == ConstantInt::getTrue(II->getContext()))
|
|
|
|
PossibleLZ = std::min(PossibleLZ, BitWidth - 1);
|
|
|
|
unsigned LowBits = Log2_32(PossibleLZ)+1;
|
|
|
|
Known.Zero.setBitsFrom(LowBits);
|
|
|
|
break;
|
|
|
|
}
|
2008-06-02 03:18:21 +02:00
|
|
|
case Intrinsic::cttz: {
|
2017-05-08 19:22:34 +02:00
|
|
|
computeKnownBits(I->getOperand(0), Known2, Depth + 1, Q);
|
|
|
|
// If we have a known 1, its position is our upper bound.
|
|
|
|
unsigned PossibleTZ = Known2.One.countTrailingZeros();
|
2011-12-24 18:31:46 +01:00
|
|
|
// If this call is undefined for 0, the result will be less than 2^n.
|
|
|
|
if (II->getArgOperand(1) == ConstantInt::getTrue(II->getContext()))
|
2017-05-08 19:22:34 +02:00
|
|
|
PossibleTZ = std::min(PossibleTZ, BitWidth - 1);
|
|
|
|
unsigned LowBits = Log2_32(PossibleTZ)+1;
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero.setBitsFrom(LowBits);
|
2011-12-24 18:31:46 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case Intrinsic::ctpop: {
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(I->getOperand(0), Known2, Depth + 1, Q);
|
2015-10-15 00:42:12 +02:00
|
|
|
// We can bound the space the count needs. Also, bits known to be zero
|
|
|
|
// can't contribute to the population.
|
2017-05-12 19:20:30 +02:00
|
|
|
unsigned BitsPossiblySet = Known2.countMaxPopulation();
|
2017-04-14 08:43:34 +02:00
|
|
|
unsigned LowBits = Log2_32(BitsPossiblySet)+1;
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero.setBitsFrom(LowBits);
|
2015-10-15 00:42:12 +02:00
|
|
|
// TODO: we could bound KnownOne using the lower bound on the number
|
|
|
|
// of bits which might be set provided by popcnt KnownOne2.
|
2008-06-02 03:18:21 +02:00
|
|
|
break;
|
|
|
|
}
|
2018-12-02 15:14:11 +01:00
|
|
|
case Intrinsic::fshr:
|
|
|
|
case Intrinsic::fshl: {
|
|
|
|
const APInt *SA;
|
|
|
|
if (!match(I->getOperand(2), m_APInt(SA)))
|
|
|
|
break;
|
|
|
|
|
|
|
|
// Normalize to funnel shift left.
|
|
|
|
uint64_t ShiftAmt = SA->urem(BitWidth);
|
|
|
|
if (II->getIntrinsicID() == Intrinsic::fshr)
|
|
|
|
ShiftAmt = BitWidth - ShiftAmt;
|
|
|
|
|
|
|
|
KnownBits Known3(Known);
|
|
|
|
computeKnownBits(I->getOperand(0), Known2, Depth + 1, Q);
|
|
|
|
computeKnownBits(I->getOperand(1), Known3, Depth + 1, Q);
|
|
|
|
|
|
|
|
Known.Zero =
|
|
|
|
Known2.Zero.shl(ShiftAmt) | Known3.Zero.lshr(BitWidth - ShiftAmt);
|
|
|
|
Known.One =
|
|
|
|
Known2.One.shl(ShiftAmt) | Known3.One.lshr(BitWidth - ShiftAmt);
|
|
|
|
break;
|
|
|
|
}
|
2011-05-27 01:13:19 +02:00
|
|
|
case Intrinsic::x86_sse42_crc32_64_64:
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero.setBitsFrom(32);
|
2011-05-22 20:25:30 +02:00
|
|
|
break;
|
2008-06-02 03:18:21 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
2016-10-06 11:56:21 +02:00
|
|
|
case Instruction::ExtractElement:
|
|
|
|
// Look through extract element. At the moment we keep this simple and skip
|
|
|
|
// tracking the specific element. But at least we might find information
|
|
|
|
// valid for all elements of the vector (for example if vector is sign
|
|
|
|
// extended, shifted, etc).
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(I->getOperand(0), Known, Depth + 1, Q);
|
2016-10-06 11:56:21 +02:00
|
|
|
break;
|
2012-03-09 10:23:50 +01:00
|
|
|
case Instruction::ExtractValue:
|
|
|
|
if (IntrinsicInst *II = dyn_cast<IntrinsicInst>(I->getOperand(0))) {
|
2016-08-13 03:05:32 +02:00
|
|
|
const ExtractValueInst *EVI = cast<ExtractValueInst>(I);
|
2012-03-09 10:23:50 +01:00
|
|
|
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-14 23:14:37 +02:00
|
|
|
computeKnownBitsAddSub(true, II->getArgOperand(0),
|
2017-04-26 18:39:58 +02:00
|
|
|
II->getArgOperand(1), false, Known, Known2,
|
|
|
|
Depth, Q);
|
2012-03-09 10:23:50 +01:00
|
|
|
break;
|
|
|
|
case Intrinsic::usub_with_overflow:
|
|
|
|
case Intrinsic::ssub_with_overflow:
|
2014-05-14 23:14:37 +02:00
|
|
|
computeKnownBitsAddSub(false, II->getArgOperand(0),
|
2017-04-26 18:39:58 +02:00
|
|
|
II->getArgOperand(1), false, Known, Known2,
|
|
|
|
Depth, Q);
|
2012-03-09 10:23:50 +01:00
|
|
|
break;
|
2012-03-19 00:28:48 +01:00
|
|
|
case Intrinsic::umul_with_overflow:
|
|
|
|
case Intrinsic::smul_with_overflow:
|
2015-03-10 03:37:25 +01:00
|
|
|
computeKnownBitsMul(II->getArgOperand(0), II->getArgOperand(1), false,
|
2017-04-26 18:39:58 +02:00
|
|
|
Known, Known2, Depth, Q);
|
2012-03-19 00:28:48 +01:00
|
|
|
break;
|
2012-03-09 10:23:50 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2008-06-02 03:18:21 +02:00
|
|
|
}
|
2015-06-15 07:46:29 +02:00
|
|
|
}
|
|
|
|
|
2017-05-08 18:22:48 +02:00
|
|
|
/// Determine which bits of V are known to be either zero or one and return
|
|
|
|
/// them.
|
|
|
|
KnownBits computeKnownBits(const Value *V, unsigned Depth, const Query &Q) {
|
|
|
|
KnownBits Known(getBitWidth(V->getType(), Q.DL));
|
|
|
|
computeKnownBits(V, Known, Depth, Q);
|
|
|
|
return Known;
|
|
|
|
}
|
|
|
|
|
2015-06-15 07:46:29 +02:00
|
|
|
/// Determine which bits of V are known to be either zero or one and return
|
2017-04-26 18:39:58 +02:00
|
|
|
/// them in the Known bit set.
|
2015-06-15 07:46:29 +02: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.
|
|
|
|
///
|
|
|
|
/// This function is defined on values with integer type, values with pointer
|
|
|
|
/// type, and vectors of integers. In the case
|
|
|
|
/// where V is a vector, 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.
|
2017-04-26 18:39:58 +02:00
|
|
|
void computeKnownBits(const Value *V, KnownBits &Known, unsigned Depth,
|
|
|
|
const Query &Q) {
|
2015-06-15 07:46:29 +02:00
|
|
|
assert(V && "No Value?");
|
|
|
|
assert(Depth <= MaxDepth && "Limit Search Depth");
|
2017-04-26 18:39:58 +02:00
|
|
|
unsigned BitWidth = Known.getBitWidth();
|
2015-06-15 07:46:29 +02:00
|
|
|
|
2017-07-09 09:04:03 +02:00
|
|
|
assert((V->getType()->isIntOrIntVectorTy(BitWidth) ||
|
2017-07-09 09:04:00 +02:00
|
|
|
V->getType()->isPtrOrPtrVectorTy()) &&
|
2016-06-02 22:01:37 +02:00
|
|
|
"Not integer or pointer type!");
|
2018-02-14 07:58:08 +01:00
|
|
|
|
|
|
|
Type *ScalarTy = V->getType()->getScalarType();
|
|
|
|
unsigned ExpectedWidth = ScalarTy->isPointerTy() ?
|
|
|
|
Q.DL.getIndexTypeSizeInBits(ScalarTy) : Q.DL.getTypeSizeInBits(ScalarTy);
|
|
|
|
assert(ExpectedWidth == BitWidth && "V and Known should have same BitWidth");
|
2017-03-23 08:06:39 +01:00
|
|
|
(void)BitWidth;
|
2018-02-14 07:58:08 +01:00
|
|
|
(void)ExpectedWidth;
|
2015-06-15 07:46:29 +02:00
|
|
|
|
2016-09-16 23:20:36 +02:00
|
|
|
const APInt *C;
|
|
|
|
if (match(V, m_APInt(C))) {
|
|
|
|
// We know all of the bits for a scalar constant or a splat vector constant!
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.One = *C;
|
|
|
|
Known.Zero = ~Known.One;
|
2015-06-15 07:46:29 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
// Null and aggregate-zero are all-zeros.
|
2016-05-23 19:57:54 +02:00
|
|
|
if (isa<ConstantPointerNull>(V) || isa<ConstantAggregateZero>(V)) {
|
2017-05-05 19:36:09 +02:00
|
|
|
Known.setAllZero();
|
2015-06-15 07:46:29 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
// Handle a constant vector by taking the intersection of the known bits of
|
2016-05-04 08:13:33 +02:00
|
|
|
// each element.
|
2016-08-13 03:05:32 +02:00
|
|
|
if (const ConstantDataSequential *CDS = dyn_cast<ConstantDataSequential>(V)) {
|
2015-06-15 07:46:29 +02:00
|
|
|
// We know that CDS must be a vector of integers. Take the intersection of
|
|
|
|
// each element.
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero.setAllBits(); Known.One.setAllBits();
|
2015-06-15 07:46:29 +02:00
|
|
|
for (unsigned i = 0, e = CDS->getNumElements(); i != e; ++i) {
|
2017-10-21 18:35:39 +02:00
|
|
|
APInt Elt = CDS->getElementAsAPInt(i);
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero &= ~Elt;
|
|
|
|
Known.One &= Elt;
|
2015-06-15 07:46:29 +02:00
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
if (const auto *CV = dyn_cast<ConstantVector>(V)) {
|
2016-05-04 08:13:33 +02:00
|
|
|
// We know that CV must be a vector of integers. Take the intersection of
|
|
|
|
// each element.
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero.setAllBits(); Known.One.setAllBits();
|
2016-05-04 08:13:33 +02:00
|
|
|
for (unsigned i = 0, e = CV->getNumOperands(); i != e; ++i) {
|
|
|
|
Constant *Element = CV->getAggregateElement(i);
|
|
|
|
auto *ElementCI = dyn_cast_or_null<ConstantInt>(Element);
|
|
|
|
if (!ElementCI) {
|
2017-05-05 19:36:09 +02:00
|
|
|
Known.resetAll();
|
2016-05-04 08:13:33 +02:00
|
|
|
return;
|
|
|
|
}
|
2017-10-21 18:35:39 +02:00
|
|
|
const APInt &Elt = ElementCI->getValue();
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero &= ~Elt;
|
|
|
|
Known.One &= Elt;
|
2016-05-04 08:13:33 +02:00
|
|
|
}
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2015-06-15 07:46:29 +02:00
|
|
|
// Start out not knowing anything.
|
2017-05-05 19:36:09 +02:00
|
|
|
Known.resetAll();
|
2015-06-15 07:46:29 +02:00
|
|
|
|
2016-09-24 22:42:02 +02:00
|
|
|
// We can't imply anything about undefs.
|
|
|
|
if (isa<UndefValue>(V))
|
|
|
|
return;
|
|
|
|
|
|
|
|
// There's no point in looking through other users of ConstantData for
|
|
|
|
// assumptions. Confirm that we've handled them all.
|
|
|
|
assert(!isa<ConstantData>(V) && "Unhandled constant data!");
|
|
|
|
|
2015-06-15 07:46:29 +02:00
|
|
|
// Limit search depth.
|
|
|
|
// All recursive calls that increase depth must come after this.
|
|
|
|
if (Depth == MaxDepth)
|
|
|
|
return;
|
|
|
|
|
|
|
|
// A weak GlobalAlias is totally unknown. A non-weak GlobalAlias has
|
|
|
|
// the bits of its aliasee.
|
2016-08-13 03:05:32 +02:00
|
|
|
if (const GlobalAlias *GA = dyn_cast<GlobalAlias>(V)) {
|
Don't IPO over functions that can be de-refined
Summary:
Fixes PR26774.
If you're aware of the issue, feel free to skip the "Motivation"
section and jump directly to "This patch".
Motivation:
I define "refinement" as discarding behaviors from a program that the
optimizer has license to discard. So transforming:
```
void f(unsigned x) {
unsigned t = 5 / x;
(void)t;
}
```
to
```
void f(unsigned x) { }
```
is refinement, since the behavior went from "if x == 0 then undefined
else nothing" to "nothing" (the optimizer has license to discard
undefined behavior).
Refinement is a fundamental aspect of many mid-level optimizations done
by LLVM. For instance, transforming `x == (x + 1)` to `false` also
involves refinement since the expression's value went from "if x is
`undef` then { `true` or `false` } else { `false` }" to "`false`" (by
definition, the optimizer has license to fold `undef` to any non-`undef`
value).
Unfortunately, refinement implies that the optimizer cannot assume
that the implementation of a function it can see has all of the
behavior an unoptimized or a differently optimized version of the same
function can have. This is a problem for functions with comdat
linkage, where a function can be replaced by an unoptimized or a
differently optimized version of the same source level function.
For instance, FunctionAttrs cannot assume a comdat function is
actually `readnone` even if it does not have any loads or stores in
it; since there may have been loads and stores in the "original
function" that were refined out in the currently visible variant, and
at the link step the linker may in fact choose an implementation with
a load or a store. As an example, consider a function that does two
atomic loads from the same memory location, and writes to memory only
if the two values are not equal. The optimizer is allowed to refine
this function by first CSE'ing the two loads, and the folding the
comparision to always report that the two values are equal. Such a
refined variant will look like it is `readonly`. However, the
unoptimized version of the function can still write to memory (since
the two loads //can// result in different values), and selecting the
unoptimized version at link time will retroactively invalidate
transforms we may have done under the assumption that the function
does not write to memory.
Note: this is not just a problem with atomics or with linking
differently optimized object files. See PR26774 for more realistic
examples that involved neither.
This patch:
This change introduces a new set of linkage types, predicated as
`GlobalValue::mayBeDerefined` that returns true if the linkage type
allows a function to be replaced by a differently optimized variant at
link time. It then changes a set of IPO passes to bail out if they see
such a function.
Reviewers: chandlerc, hfinkel, dexonsmith, joker.eph, rnk
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D18634
llvm-svn: 265762
2016-04-08 02:48:30 +02:00
|
|
|
if (!GA->isInterposable())
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBits(GA->getAliasee(), Known, Depth + 1, Q);
|
2015-06-15 07:46:29 +02:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
if (const Operator *I = dyn_cast<Operator>(V))
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBitsFromOperator(I, Known, Depth, Q);
|
2015-09-25 22:12:43 +02:00
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
// Aligned pointers have trailing zeros - refine Known.Zero set
|
2015-09-30 13:55:45 +02:00
|
|
|
if (V->getType()->isPointerTy()) {
|
2016-02-24 13:25:10 +01:00
|
|
|
unsigned Align = V->getPointerAlignment(Q.DL);
|
2015-09-30 13:55:45 +02:00
|
|
|
if (Align)
|
2017-04-26 18:39:58 +02:00
|
|
|
Known.Zero.setLowBits(countTrailingZeros(Align));
|
2015-09-30 13:55:45 +02:00
|
|
|
}
|
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
// computeKnownBitsFromAssume strictly refines Known.
|
|
|
|
// Therefore, we run them after computeKnownBitsFromOperator.
|
2015-06-15 07:46:29 +02:00
|
|
|
|
|
|
|
// Check whether a nearby assume intrinsic can determine some known bits.
|
2017-04-26 18:39:58 +02:00
|
|
|
computeKnownBitsFromAssume(V, Known, Depth, Q);
|
2015-06-15 07:46:29 +02:00
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
assert((Known.Zero & Known.One) == 0 && "Bits known to be one AND zero?");
|
2008-06-02 03:18:21 +02:00
|
|
|
}
|
|
|
|
|
2014-11-04 17:27:42 +01:00
|
|
|
/// Return true if the given value is known to have exactly one
|
2011-01-25 10:38:29 +01:00
|
|
|
/// bit set when defined. For vectors return true if every element is known to
|
2014-11-04 17:27:42 +01:00
|
|
|
/// be a power of two when defined. Supports values with integer or pointer
|
2011-01-25 10:38:29 +01:00
|
|
|
/// types and vectors of integers.
|
2016-08-13 03:05:32 +02:00
|
|
|
bool isKnownToBeAPowerOfTwo(const Value *V, bool OrZero, unsigned Depth,
|
2016-01-15 23:22:04 +01:00
|
|
|
const Query &Q) {
|
2017-08-22 00:56:12 +02:00
|
|
|
assert(Depth <= MaxDepth && "Limit Search Depth");
|
|
|
|
|
2018-02-06 19:39:23 +01:00
|
|
|
// Attempt to match against constants.
|
|
|
|
if (OrZero && match(V, m_Power2OrZero()))
|
|
|
|
return true;
|
|
|
|
if (match(V, m_Power2()))
|
|
|
|
return true;
|
2011-01-25 10:38:29 +01: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;
|
|
|
|
|
2017-04-20 18:56:25 +02:00
|
|
|
// (signmask) >>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.
|
|
|
|
if (match(V, m_LShr(m_SignMask(), m_Value())))
|
2011-01-25 10:38:29 +01: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 06:59:12 +02:00
|
|
|
Value *X = nullptr, *Y = nullptr;
|
2015-12-30 23:40:52 +01:00
|
|
|
// A shift left or a logical shift right of a power of two is a power of two
|
|
|
|
// or zero.
|
2011-10-28 20:30:05 +02:00
|
|
|
if (OrZero && (match(V, m_Shl(m_Value(X), m_Value())) ||
|
2015-12-30 23:40:52 +01:00
|
|
|
match(V, m_LShr(m_Value(X), m_Value()))))
|
2016-01-15 23:22:04 +01:00
|
|
|
return isKnownToBeAPowerOfTwo(X, /*OrZero*/ true, Depth, Q);
|
2011-10-28 20:30:05 +02:00
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
if (const ZExtInst *ZI = dyn_cast<ZExtInst>(V))
|
2016-01-15 23:22:04 +01:00
|
|
|
return isKnownToBeAPowerOfTwo(ZI->getOperand(0), OrZero, Depth, Q);
|
2011-01-25 10:38:29 +01:00
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
if (const SelectInst *SI = dyn_cast<SelectInst>(V))
|
2016-01-15 23:22:04 +01:00
|
|
|
return isKnownToBeAPowerOfTwo(SI->getTrueValue(), OrZero, Depth, Q) &&
|
|
|
|
isKnownToBeAPowerOfTwo(SI->getFalseValue(), OrZero, Depth, Q);
|
2011-10-26 22:55:21 +02: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.
|
2016-01-15 23:22:04 +01:00
|
|
|
if (isKnownToBeAPowerOfTwo(X, /*OrZero*/ true, Depth, Q) ||
|
|
|
|
isKnownToBeAPowerOfTwo(Y, /*OrZero*/ true, Depth, Q))
|
2011-10-26 22:55:21 +02: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 10:38:29 +01:00
|
|
|
|
2013-07-30 23:01:36 +02: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)))) {
|
2016-08-13 03:05:32 +02:00
|
|
|
const OverflowingBinaryOperator *VOBO = cast<OverflowingBinaryOperator>(V);
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
if (OrZero || Q.IIQ.hasNoUnsignedWrap(VOBO) ||
|
|
|
|
Q.IIQ.hasNoSignedWrap(VOBO)) {
|
2013-07-30 23:01:36 +02:00
|
|
|
if (match(X, m_And(m_Specific(Y), m_Value())) ||
|
|
|
|
match(X, m_And(m_Value(), m_Specific(Y))))
|
2016-01-15 23:22:04 +01:00
|
|
|
if (isKnownToBeAPowerOfTwo(Y, OrZero, Depth, Q))
|
2013-07-30 23:01:36 +02:00
|
|
|
return true;
|
|
|
|
if (match(Y, m_And(m_Specific(X), m_Value())) ||
|
|
|
|
match(Y, m_And(m_Value(), m_Specific(X))))
|
2016-01-15 23:22:04 +01:00
|
|
|
if (isKnownToBeAPowerOfTwo(X, OrZero, Depth, Q))
|
2013-07-30 23:01:36 +02:00
|
|
|
return true;
|
|
|
|
|
|
|
|
unsigned BitWidth = V->getType()->getScalarSizeInBits();
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits LHSBits(BitWidth);
|
|
|
|
computeKnownBits(X, LHSBits, Depth, Q);
|
2013-07-30 23:01:36 +02:00
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits RHSBits(BitWidth);
|
|
|
|
computeKnownBits(Y, RHSBits, Depth, Q);
|
2013-07-30 23:01:36 +02: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
|
2017-04-26 18:39:58 +02:00
|
|
|
if ((~(LHSBits.Zero & RHSBits.Zero)).isPowerOf2())
|
2013-07-30 23:01:36 +02:00
|
|
|
// If OrZero isn't set, we cannot give back a zero result.
|
|
|
|
// Make sure either the LHS or RHS has a bit set.
|
2017-04-26 18:39:58 +02:00
|
|
|
if (OrZero || RHSBits.One.getBoolValue() || LHSBits.One.getBoolValue())
|
2013-07-30 23:01:36 +02:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
2013-05-18 21:30:37 +02:00
|
|
|
|
2011-02-28 09:02:21 +01:00
|
|
|
// An exact divide or right shift can only shift off zero bits, so the result
|
2011-03-21 22:40:32 +01: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-01 18:55:30 +01: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-07 20:57:58 +02:00
|
|
|
return isKnownToBeAPowerOfTwo(cast<Operator>(V)->getOperand(0), OrZero,
|
2016-01-15 23:22:04 +01:00
|
|
|
Depth, Q);
|
2011-02-28 09:02:21 +01:00
|
|
|
}
|
|
|
|
|
2011-01-25 10:38:29 +01:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Test whether a GEP's result is known to be non-null.
|
2012-12-07 03:08:58 +01:00
|
|
|
///
|
|
|
|
/// 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.
|
2016-08-13 03:05:32 +02:00
|
|
|
static bool isGEPKnownNonNull(const GEPOperator *GEP, unsigned Depth,
|
2016-01-15 23:22:04 +01:00
|
|
|
const Query &Q) {
|
llvm: Add support for "-fno-delete-null-pointer-checks"
Summary:
Support for this option is needed for building Linux kernel.
This is a very frequently requested feature by kernel developers.
More details : https://lkml.org/lkml/2018/4/4/601
GCC option description for -fdelete-null-pointer-checks:
This Assume that programs cannot safely dereference null pointers,
and that no code or data element resides at address zero.
-fno-delete-null-pointer-checks is the inverse of this implying that
null pointer dereferencing is not undefined.
This feature is implemented in LLVM IR in this CL as the function attribute
"null-pointer-is-valid"="true" in IR (Under review at D47894).
The CL updates several passes that assumed null pointer dereferencing is
undefined to not optimize when the "null-pointer-is-valid"="true"
attribute is present.
Reviewers: t.p.northover, efriedma, jyknight, chandlerc, rnk, srhines, void, george.burgess.iv
Reviewed By: efriedma, george.burgess.iv
Subscribers: eraman, haicheng, george.burgess.iv, drinkcat, theraven, reames, sanjoy, xbolva00, llvm-commits
Differential Revision: https://reviews.llvm.org/D47895
llvm-svn: 336613
2018-07-10 00:27:23 +02:00
|
|
|
const Function *F = nullptr;
|
|
|
|
if (const Instruction *I = dyn_cast<Instruction>(GEP))
|
|
|
|
F = I->getFunction();
|
|
|
|
|
|
|
|
if (!GEP->isInBounds() ||
|
|
|
|
NullPointerIsDefined(F, GEP->getPointerAddressSpace()))
|
2012-12-07 03:08:58 +01:00
|
|
|
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.
|
2016-01-15 23:22:04 +01:00
|
|
|
if (isKnownNonZero(GEP->getPointerOperand(), Depth, Q))
|
2012-12-07 03:08:58 +01:00
|
|
|
return true;
|
|
|
|
|
|
|
|
// 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.
|
2016-12-02 03:24:42 +01:00
|
|
|
if (StructType *STy = GTI.getStructTypeOrNull()) {
|
2012-12-07 03:08:58 +01:00
|
|
|
ConstantInt *OpC = cast<ConstantInt>(GTI.getOperand());
|
|
|
|
unsigned ElementIdx = OpC->getZExtValue();
|
2016-01-15 23:22:04 +01:00
|
|
|
const StructLayout *SL = Q.DL.getStructLayout(STy);
|
2012-12-07 03:08:58 +01:00
|
|
|
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.
|
2016-01-15 23:22:04 +01:00
|
|
|
if (Q.DL.getTypeAllocSize(GTI.getIndexedType()) == 0)
|
2012-12-07 03:08:58 +01:00
|
|
|
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;
|
|
|
|
|
2016-01-15 23:22:04 +01:00
|
|
|
if (isKnownNonZero(GTI.getOperand(), Depth, Q))
|
2012-12-07 03:08:58 +01:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2017-09-09 20:23:11 +02:00
|
|
|
static bool isKnownNonNullFromDominatingCondition(const Value *V,
|
|
|
|
const Instruction *CtxI,
|
|
|
|
const DominatorTree *DT) {
|
|
|
|
assert(V->getType()->isPointerTy() && "V must be pointer type");
|
|
|
|
assert(!isa<ConstantData>(V) && "Did not expect ConstantPointerNull");
|
|
|
|
|
|
|
|
if (!CtxI || !DT)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
unsigned NumUsesExplored = 0;
|
|
|
|
for (auto *U : V->users()) {
|
|
|
|
// Avoid massive lists
|
|
|
|
if (NumUsesExplored >= DomConditionsMaxUses)
|
|
|
|
break;
|
|
|
|
NumUsesExplored++;
|
|
|
|
|
|
|
|
// If the value is used as an argument to a call or invoke, then argument
|
|
|
|
// attributes may provide an answer about null-ness.
|
|
|
|
if (auto CS = ImmutableCallSite(U))
|
|
|
|
if (auto *CalledFunc = CS.getCalledFunction())
|
|
|
|
for (const Argument &Arg : CalledFunc->args())
|
|
|
|
if (CS.getArgOperand(Arg.getArgNo()) == V &&
|
|
|
|
Arg.hasNonNullAttr() && DT->dominates(CS.getInstruction(), CtxI))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// Consider only compare instructions uniquely controlling a branch
|
|
|
|
CmpInst::Predicate Pred;
|
|
|
|
if (!match(const_cast<User *>(U),
|
|
|
|
m_c_ICmp(Pred, m_Specific(V), m_Zero())) ||
|
|
|
|
(Pred != ICmpInst::ICMP_EQ && Pred != ICmpInst::ICMP_NE))
|
|
|
|
continue;
|
|
|
|
|
2018-08-06 13:14:18 +02:00
|
|
|
SmallVector<const User *, 4> WorkList;
|
|
|
|
SmallPtrSet<const User *, 4> Visited;
|
2017-09-09 20:23:11 +02:00
|
|
|
for (auto *CmpU : U->users()) {
|
2018-08-06 13:14:18 +02:00
|
|
|
assert(WorkList.empty() && "Should be!");
|
|
|
|
if (Visited.insert(CmpU).second)
|
|
|
|
WorkList.push_back(CmpU);
|
|
|
|
|
|
|
|
while (!WorkList.empty()) {
|
|
|
|
auto *Curr = WorkList.pop_back_val();
|
|
|
|
|
|
|
|
// If a user is an AND, add all its users to the work list. We only
|
|
|
|
// propagate "pred != null" condition through AND because it is only
|
|
|
|
// correct to assume that all conditions of AND are met in true branch.
|
|
|
|
// TODO: Support similar logic of OR and EQ predicate?
|
|
|
|
if (Pred == ICmpInst::ICMP_NE)
|
|
|
|
if (auto *BO = dyn_cast<BinaryOperator>(Curr))
|
|
|
|
if (BO->getOpcode() == Instruction::And) {
|
|
|
|
for (auto *BOU : BO->users())
|
|
|
|
if (Visited.insert(BOU).second)
|
|
|
|
WorkList.push_back(BOU);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (const BranchInst *BI = dyn_cast<BranchInst>(Curr)) {
|
|
|
|
assert(BI->isConditional() && "uses a comparison!");
|
2017-09-09 20:23:11 +02:00
|
|
|
|
2018-08-06 13:14:18 +02:00
|
|
|
BasicBlock *NonNullSuccessor =
|
|
|
|
BI->getSuccessor(Pred == ICmpInst::ICMP_EQ ? 1 : 0);
|
|
|
|
BasicBlockEdge Edge(BI->getParent(), NonNullSuccessor);
|
|
|
|
if (Edge.isSingleEdge() && DT->dominates(Edge, CtxI->getParent()))
|
|
|
|
return true;
|
2018-08-30 05:39:16 +02:00
|
|
|
} else if (Pred == ICmpInst::ICMP_NE && isGuard(Curr) &&
|
2018-08-06 13:14:18 +02:00
|
|
|
DT->dominates(cast<Instruction>(Curr), CtxI)) {
|
2017-09-09 20:23:11 +02:00
|
|
|
return true;
|
2018-08-06 13:14:18 +02:00
|
|
|
}
|
2017-09-09 20:23:11 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-10-30 21:25:19 +01: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.
|
2016-08-13 03:05:32 +02:00
|
|
|
static bool rangeMetadataExcludesValue(const MDNode* Ranges, const APInt& Value) {
|
2014-10-30 21:25:19 +01:00
|
|
|
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-09 19:38:53 +01:00
|
|
|
ConstantInt *Lower =
|
|
|
|
mdconst::extract<ConstantInt>(Ranges->getOperand(2 * i + 0));
|
|
|
|
ConstantInt *Upper =
|
|
|
|
mdconst::extract<ConstantInt>(Ranges->getOperand(2 * i + 1));
|
2014-10-30 21:25:19 +01:00
|
|
|
ConstantRange Range(Lower->getValue(), Upper->getValue());
|
|
|
|
if (Range.contains(Value))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-02-12 16:35:34 +01: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. For pointers, if the context instruction and dominator tree are
|
|
|
|
/// specified, perform context-sensitive analysis and return true if the
|
|
|
|
/// pointer couldn't possibly be null at the specified instruction.
|
|
|
|
/// Supports values with integer or pointer type and vectors of integers.
|
2016-08-13 03:05:32 +02:00
|
|
|
bool isKnownNonZero(const Value *V, unsigned Depth, const Query &Q) {
|
2016-05-22 18:07:20 +02:00
|
|
|
if (auto *C = dyn_cast<Constant>(V)) {
|
2011-01-25 10:38:29 +01:00
|
|
|
if (C->isNullValue())
|
|
|
|
return false;
|
|
|
|
if (isa<ConstantInt>(C))
|
|
|
|
// Must be non-zero due to null test above.
|
|
|
|
return true;
|
2016-05-24 16:18:49 +02:00
|
|
|
|
|
|
|
// For constant vectors, check that all elements are undefined or known
|
|
|
|
// non-zero to determine that the whole vector is known non-zero.
|
|
|
|
if (auto *VecTy = dyn_cast<VectorType>(C->getType())) {
|
|
|
|
for (unsigned i = 0, e = VecTy->getNumElements(); i != e; ++i) {
|
|
|
|
Constant *Elt = C->getAggregateElement(i);
|
|
|
|
if (!Elt || Elt->isNullValue())
|
|
|
|
return false;
|
|
|
|
if (!isa<UndefValue>(Elt) && !isa<ConstantInt>(Elt))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-09-09 20:23:11 +02:00
|
|
|
// A global variable in address space 0 is non null unless extern weak
|
|
|
|
// or an absolute symbol reference. Other address spaces may have null as a
|
|
|
|
// valid address for a global, so we can't assume anything.
|
|
|
|
if (const GlobalValue *GV = dyn_cast<GlobalValue>(V)) {
|
|
|
|
if (!GV->isAbsoluteSymbolRef() && !GV->hasExternalWeakLinkage() &&
|
|
|
|
GV->getType()->getAddressSpace() == 0)
|
|
|
|
return true;
|
|
|
|
} else
|
|
|
|
return false;
|
2011-01-25 10:38:29 +01:00
|
|
|
}
|
|
|
|
|
2016-05-22 18:07:20 +02:00
|
|
|
if (auto *I = dyn_cast<Instruction>(V)) {
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
if (MDNode *Ranges = Q.IIQ.getMetadata(I, LLVMContext::MD_range)) {
|
2014-10-30 21:25:19 +01:00
|
|
|
// If the possible ranges don't contain zero, then the value is
|
|
|
|
// definitely non-zero.
|
2016-05-22 18:07:20 +02:00
|
|
|
if (auto *Ty = dyn_cast<IntegerType>(V->getType())) {
|
2014-10-30 21:25:19 +01:00
|
|
|
const APInt ZeroValue(Ty->getBitWidth(), 0);
|
|
|
|
if (rangeMetadataExcludesValue(Ranges, ZeroValue))
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-05-30 17:56:46 +02:00
|
|
|
// Some of the tests below are recursive, so bail out if we hit the limit.
|
|
|
|
if (Depth++ >= MaxDepth)
|
|
|
|
return false;
|
|
|
|
|
2017-09-09 20:23:11 +02:00
|
|
|
// Check for pointer simplifications.
|
|
|
|
if (V->getType()->isPointerTy()) {
|
|
|
|
// Alloca never returns null, malloc might.
|
|
|
|
if (isa<AllocaInst>(V) && Q.DL.getAllocaAddrSpace() == 0)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// A byval, inalloca, or nonnull argument is never null.
|
|
|
|
if (const Argument *A = dyn_cast<Argument>(V))
|
|
|
|
if (A->hasByValOrInAllocaAttr() || A->hasNonNullAttr())
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// A Load tagged with nonnull metadata is never null.
|
|
|
|
if (const LoadInst *LI = dyn_cast<LoadInst>(V))
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
if (Q.IIQ.getMetadata(LI, LLVMContext::MD_nonnull))
|
2017-09-09 20:23:11 +02:00
|
|
|
return true;
|
|
|
|
|
2019-01-07 06:42:51 +01:00
|
|
|
if (const auto *Call = dyn_cast<CallBase>(V)) {
|
|
|
|
if (Call->isReturnNonNull())
|
2017-09-09 20:23:11 +02:00
|
|
|
return true;
|
2019-01-07 06:42:51 +01:00
|
|
|
if (const auto *RP = getArgumentAliasingToReturnedPointer(Call))
|
2018-05-30 17:56:46 +02:00
|
|
|
return isKnownNonZero(RP, Depth, Q);
|
2018-05-19 01:54:33 +02:00
|
|
|
}
|
2017-09-09 20:23:11 +02:00
|
|
|
}
|
|
|
|
|
2011-01-25 10:38:29 +01:00
|
|
|
|
2017-09-09 20:23:11 +02:00
|
|
|
// Check for recursive pointer simplifications.
|
2012-12-07 03:08:58 +01:00
|
|
|
if (V->getType()->isPointerTy()) {
|
2017-09-09 20:23:11 +02:00
|
|
|
if (isKnownNonNullFromDominatingCondition(V, Q.CxtI, Q.DT))
|
2016-05-07 04:08:15 +02:00
|
|
|
return true;
|
2017-09-09 20:23:11 +02:00
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
if (const GEPOperator *GEP = dyn_cast<GEPOperator>(V))
|
2016-01-15 23:22:04 +01:00
|
|
|
if (isGEPKnownNonNull(GEP, Depth, Q))
|
2012-12-07 03:08:58 +01:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2016-01-15 23:22:04 +01:00
|
|
|
unsigned BitWidth = getBitWidth(V->getType()->getScalarType(), Q.DL);
|
2011-01-25 10:38:29 +01:00
|
|
|
|
|
|
|
// X | Y != 0 if X != 0 or Y != 0.
|
2014-04-15 06:59:12 +02:00
|
|
|
Value *X = nullptr, *Y = nullptr;
|
2011-01-25 10:38:29 +01:00
|
|
|
if (match(V, m_Or(m_Value(X), m_Value(Y))))
|
2016-01-15 23:22:04 +01:00
|
|
|
return isKnownNonZero(X, Depth, Q) || isKnownNonZero(Y, Depth, Q);
|
2011-01-25 10:38:29 +01:00
|
|
|
|
|
|
|
// ext X != 0 if X != 0.
|
|
|
|
if (isa<SExtInst>(V) || isa<ZExtInst>(V))
|
2016-01-15 23:22:04 +01:00
|
|
|
return isKnownNonZero(cast<Instruction>(V)->getOperand(0), Depth, Q);
|
2011-01-25 10:38:29 +01:00
|
|
|
|
2011-01-29 14:27:00 +01:00
|
|
|
// shl X, Y != 0 if X is odd. Note that the value of the shift is undefined
|
2011-01-25 10:38:29 +01:00
|
|
|
// if the lowest bit is shifted off the end.
|
2017-05-04 00:25:19 +02:00
|
|
|
if (match(V, m_Shl(m_Value(X), m_Value(Y)))) {
|
2011-02-28 09:02:21 +01:00
|
|
|
// shl nuw can't remove any non-zero bits.
|
2016-08-13 03:05:32 +02:00
|
|
|
const OverflowingBinaryOperator *BO = cast<OverflowingBinaryOperator>(V);
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
if (Q.IIQ.hasNoUnsignedWrap(BO))
|
2016-01-15 23:22:04 +01:00
|
|
|
return isKnownNonZero(X, Depth, Q);
|
2011-02-28 09:02:21 +01:00
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits Known(BitWidth);
|
|
|
|
computeKnownBits(X, Known, Depth, Q);
|
|
|
|
if (Known.One[0])
|
2011-01-25 10:38:29 +01:00
|
|
|
return true;
|
|
|
|
}
|
2011-01-29 14:27:00 +01:00
|
|
|
// shr X, Y != 0 if X is negative. Note that the value of the shift is not
|
2011-01-25 10:38:29 +01: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 09:02:21 +01:00
|
|
|
// shr exact can only shift out zero bits.
|
2016-08-13 03:05:32 +02:00
|
|
|
const PossiblyExactOperator *BO = cast<PossiblyExactOperator>(V);
|
2011-02-28 09:02:21 +01:00
|
|
|
if (BO->isExact())
|
2016-01-15 23:22:04 +01:00
|
|
|
return isKnownNonZero(X, Depth, Q);
|
2011-02-28 09:02:21 +01:00
|
|
|
|
2017-05-08 18:22:48 +02:00
|
|
|
KnownBits Known = computeKnownBits(X, Depth, Q);
|
|
|
|
if (Known.isNegative())
|
2011-01-25 10:38:29 +01:00
|
|
|
return true;
|
2015-09-24 18:06:32 +02:00
|
|
|
|
|
|
|
// If the shifter operand is a constant, and all of the bits shifted
|
|
|
|
// out are known to be zero, and X is known non-zero then at least one
|
|
|
|
// non-zero bit must remain.
|
|
|
|
if (ConstantInt *Shift = dyn_cast<ConstantInt>(Y)) {
|
|
|
|
auto ShiftVal = Shift->getLimitedValue(BitWidth - 1);
|
|
|
|
// Is there a known one in the portion not shifted out?
|
2017-05-12 19:20:30 +02:00
|
|
|
if (Known.countMaxLeadingZeros() < BitWidth - ShiftVal)
|
2015-09-24 18:06:32 +02:00
|
|
|
return true;
|
|
|
|
// Are all the bits to be shifted out known zero?
|
2017-07-11 04:31:51 +02:00
|
|
|
if (Known.countMinTrailingZeros() >= ShiftVal)
|
2016-01-15 23:22:04 +01:00
|
|
|
return isKnownNonZero(X, Depth, Q);
|
2015-09-24 18:06:32 +02:00
|
|
|
}
|
2011-01-25 10:38:29 +01:00
|
|
|
}
|
2011-02-28 09:02:21 +01:00
|
|
|
// div exact can only produce a zero if the dividend is zero.
|
2012-01-01 18:55:30 +01:00
|
|
|
else if (match(V, m_Exact(m_IDiv(m_Value(X), m_Value())))) {
|
2016-01-15 23:22:04 +01:00
|
|
|
return isKnownNonZero(X, Depth, Q);
|
2011-02-28 09:02:21 +01:00
|
|
|
}
|
2011-01-25 10:38:29 +01:00
|
|
|
// X + Y.
|
|
|
|
else if (match(V, m_Add(m_Value(X), m_Value(Y)))) {
|
2017-05-08 18:22:48 +02:00
|
|
|
KnownBits XKnown = computeKnownBits(X, Depth, Q);
|
|
|
|
KnownBits YKnown = computeKnownBits(Y, Depth, Q);
|
2011-01-25 10:38:29 +01:00
|
|
|
|
|
|
|
// If X and Y are both non-negative (as signed values) then their sum is not
|
2011-01-25 16:14:15 +01:00
|
|
|
// zero unless both X and Y are zero.
|
2017-05-08 18:22:48 +02:00
|
|
|
if (XKnown.isNonNegative() && YKnown.isNonNegative())
|
2016-01-15 23:22:04 +01:00
|
|
|
if (isKnownNonZero(X, Depth, Q) || isKnownNonZero(Y, Depth, Q))
|
2011-01-25 16:14:15 +01:00
|
|
|
return true;
|
2011-01-25 10:38:29 +01: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.
|
2017-05-08 18:22:48 +02:00
|
|
|
if (XKnown.isNegative() && YKnown.isNegative()) {
|
2011-01-25 10:38:29 +01:00
|
|
|
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.
|
2017-05-08 18:22:48 +02:00
|
|
|
if (XKnown.One.intersects(Mask))
|
2011-01-25 10:38:29 +01:00
|
|
|
return true;
|
|
|
|
// The sign bit of Y is set. If some other bit is set then Y is not equal
|
|
|
|
// to INT_MIN.
|
2017-05-08 18:22:48 +02:00
|
|
|
if (YKnown.One.intersects(Mask))
|
2011-01-25 10:38:29 +01:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// The sum of a non-negative number and a power of two is not zero.
|
2017-05-08 18:22:48 +02:00
|
|
|
if (XKnown.isNonNegative() &&
|
2016-01-15 23:22:04 +01:00
|
|
|
isKnownToBeAPowerOfTwo(Y, /*OrZero*/ false, Depth, Q))
|
2011-01-25 10:38:29 +01:00
|
|
|
return true;
|
2017-05-08 18:22:48 +02:00
|
|
|
if (YKnown.isNonNegative() &&
|
2016-01-15 23:22:04 +01:00
|
|
|
isKnownToBeAPowerOfTwo(X, /*OrZero*/ false, Depth, Q))
|
2011-01-25 10:38:29 +01:00
|
|
|
return true;
|
|
|
|
}
|
2011-10-27 21:16:21 +02:00
|
|
|
// X * Y.
|
|
|
|
else if (match(V, m_Mul(m_Value(X), m_Value(Y)))) {
|
2016-08-13 03:05:32 +02:00
|
|
|
const OverflowingBinaryOperator *BO = cast<OverflowingBinaryOperator>(V);
|
2011-10-27 21:16:21 +02:00
|
|
|
// If X and Y are non-zero then so is X * Y as long as the multiplication
|
|
|
|
// does not overflow.
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
if ((Q.IIQ.hasNoSignedWrap(BO) || Q.IIQ.hasNoUnsignedWrap(BO)) &&
|
2016-01-15 23:22:04 +01:00
|
|
|
isKnownNonZero(X, Depth, Q) && isKnownNonZero(Y, Depth, Q))
|
2011-10-27 21:16:21 +02:00
|
|
|
return true;
|
|
|
|
}
|
2011-01-25 10:38:29 +01:00
|
|
|
// (C ? X : Y) != 0 if X != 0 and Y != 0.
|
2016-08-13 03:05:32 +02:00
|
|
|
else if (const SelectInst *SI = dyn_cast<SelectInst>(V)) {
|
2016-01-15 23:22:04 +01:00
|
|
|
if (isKnownNonZero(SI->getTrueValue(), Depth, Q) &&
|
|
|
|
isKnownNonZero(SI->getFalseValue(), Depth, Q))
|
2011-01-25 10:38:29 +01:00
|
|
|
return true;
|
|
|
|
}
|
2015-09-29 16:08:45 +02:00
|
|
|
// PHI
|
2016-08-13 03:05:32 +02:00
|
|
|
else if (const PHINode *PN = dyn_cast<PHINode>(V)) {
|
2015-09-29 16:08:45 +02:00
|
|
|
// Try and detect a recurrence that monotonically increases from a
|
|
|
|
// starting value, as these are common as induction variables.
|
|
|
|
if (PN->getNumIncomingValues() == 2) {
|
|
|
|
Value *Start = PN->getIncomingValue(0);
|
|
|
|
Value *Induction = PN->getIncomingValue(1);
|
|
|
|
if (isa<ConstantInt>(Induction) && !isa<ConstantInt>(Start))
|
|
|
|
std::swap(Start, Induction);
|
|
|
|
if (ConstantInt *C = dyn_cast<ConstantInt>(Start)) {
|
|
|
|
if (!C->isZero() && !C->isNegative()) {
|
|
|
|
ConstantInt *X;
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
if (Q.IIQ.UseInstrInfo &&
|
|
|
|
(match(Induction, m_NSWAdd(m_Specific(PN), m_ConstantInt(X))) ||
|
2015-09-29 16:08:45 +02:00
|
|
|
match(Induction, m_NUWAdd(m_Specific(PN), m_ConstantInt(X)))) &&
|
|
|
|
!X->isNegative())
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2016-02-01 18:03:07 +01:00
|
|
|
// Check if all incoming values are non-zero constant.
|
2017-09-01 23:37:29 +02:00
|
|
|
bool AllNonZeroConstants = llvm::all_of(PN->operands(), [](Value *V) {
|
2017-07-06 20:39:47 +02:00
|
|
|
return isa<ConstantInt>(V) && !cast<ConstantInt>(V)->isZero();
|
2016-02-01 18:03:07 +01:00
|
|
|
});
|
|
|
|
if (AllNonZeroConstants)
|
|
|
|
return true;
|
2015-09-29 16:08:45 +02:00
|
|
|
}
|
2011-01-25 10:38:29 +01:00
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits Known(BitWidth);
|
|
|
|
computeKnownBits(V, Known, Depth, Q);
|
|
|
|
return Known.One != 0;
|
2011-01-25 10:38:29 +01:00
|
|
|
}
|
|
|
|
|
2015-10-22 15:18:42 +02:00
|
|
|
/// Return true if V2 == V1 + X, where X is known non-zero.
|
2016-08-13 03:05:32 +02:00
|
|
|
static bool isAddOfNonZero(const Value *V1, const Value *V2, const Query &Q) {
|
|
|
|
const BinaryOperator *BO = dyn_cast<BinaryOperator>(V1);
|
2015-10-22 15:18:42 +02:00
|
|
|
if (!BO || BO->getOpcode() != Instruction::Add)
|
|
|
|
return false;
|
|
|
|
Value *Op = nullptr;
|
|
|
|
if (V2 == BO->getOperand(0))
|
|
|
|
Op = BO->getOperand(1);
|
|
|
|
else if (V2 == BO->getOperand(1))
|
|
|
|
Op = BO->getOperand(0);
|
|
|
|
else
|
|
|
|
return false;
|
2016-01-15 23:22:04 +01:00
|
|
|
return isKnownNonZero(Op, 0, Q);
|
2015-10-22 15:18:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Return true if it is known that V1 != V2.
|
2016-08-13 03:05:32 +02:00
|
|
|
static bool isKnownNonEqual(const Value *V1, const Value *V2, const Query &Q) {
|
2017-06-06 09:13:15 +02:00
|
|
|
if (V1 == V2)
|
2015-10-22 15:18:42 +02:00
|
|
|
return false;
|
|
|
|
if (V1->getType() != V2->getType())
|
|
|
|
// We can't look through casts yet.
|
|
|
|
return false;
|
2016-01-15 23:22:04 +01:00
|
|
|
if (isAddOfNonZero(V1, V2, Q) || isAddOfNonZero(V2, V1, Q))
|
2015-10-22 15:18:42 +02:00
|
|
|
return true;
|
|
|
|
|
2017-06-06 09:13:15 +02:00
|
|
|
if (V1->getType()->isIntOrIntVectorTy()) {
|
2015-10-22 15:18:42 +02:00
|
|
|
// Are any known bits in V1 contradictory to known bits in V2? If V1
|
|
|
|
// has a known zero where V2 has a known one, they must not be equal.
|
2017-06-06 09:13:11 +02:00
|
|
|
KnownBits Known1 = computeKnownBits(V1, 0, Q);
|
|
|
|
KnownBits Known2 = computeKnownBits(V2, 0, Q);
|
2017-04-26 18:39:58 +02:00
|
|
|
|
2017-06-06 09:13:09 +02:00
|
|
|
if (Known1.Zero.intersects(Known2.One) ||
|
|
|
|
Known2.Zero.intersects(Known1.One))
|
2015-10-22 15:18:42 +02:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-11-04 17:27:42 +01: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 02:06:16 +02:00
|
|
|
///
|
|
|
|
/// This function is defined on values with integer type, values with pointer
|
2015-03-10 03:37:25 +01:00
|
|
|
/// type, and vectors of integers. In the case
|
2009-09-08 02:06:16 +02:00
|
|
|
/// 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.
|
2016-08-13 03:05:32 +02:00
|
|
|
bool MaskedValueIsZero(const Value *V, const APInt &Mask, unsigned Depth,
|
2016-01-15 23:22:04 +01:00
|
|
|
const Query &Q) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits Known(Mask.getBitWidth());
|
|
|
|
computeKnownBits(V, Known, Depth, Q);
|
|
|
|
return Mask.isSubsetOf(Known.Zero);
|
2008-06-02 03:18:21 +02:00
|
|
|
}
|
|
|
|
|
2018-08-23 01:27:50 +02:00
|
|
|
// Match a signed min+max clamp pattern like smax(smin(In, CHigh), CLow).
|
|
|
|
// Returns the input and lower/upper bounds.
|
|
|
|
static bool isSignedMinMaxClamp(const Value *Select, const Value *&In,
|
|
|
|
const APInt *&CLow, const APInt *&CHigh) {
|
2018-08-23 19:15:02 +02:00
|
|
|
assert(isa<Operator>(Select) &&
|
|
|
|
cast<Operator>(Select)->getOpcode() == Instruction::Select &&
|
2018-08-23 19:45:53 +02:00
|
|
|
"Input should be a Select!");
|
2018-08-23 01:27:50 +02:00
|
|
|
|
|
|
|
const Value *LHS, *RHS, *LHS2, *RHS2;
|
|
|
|
SelectPatternFlavor SPF = matchSelectPattern(Select, LHS, RHS).Flavor;
|
|
|
|
if (SPF != SPF_SMAX && SPF != SPF_SMIN)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (!match(RHS, m_APInt(CLow)))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
SelectPatternFlavor SPF2 = matchSelectPattern(LHS, LHS2, RHS2).Flavor;
|
|
|
|
if (getInverseMinMaxFlavor(SPF) != SPF2)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (!match(RHS2, m_APInt(CHigh)))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (SPF == SPF_SMIN)
|
|
|
|
std::swap(CLow, CHigh);
|
|
|
|
|
|
|
|
In = LHS2;
|
|
|
|
return CLow->sle(*CHigh);
|
|
|
|
}
|
|
|
|
|
2016-06-22 21:20:59 +02:00
|
|
|
/// For vector constants, loop over the elements and find the constant with the
|
|
|
|
/// minimum number of sign bits. Return 0 if the value is not a vector constant
|
|
|
|
/// or if any element was not analyzed; otherwise, return the count for the
|
|
|
|
/// element with the minimum number of sign bits.
|
2016-08-13 03:05:32 +02:00
|
|
|
static unsigned computeNumSignBitsVectorConstant(const Value *V,
|
|
|
|
unsigned TyBits) {
|
|
|
|
const auto *CV = dyn_cast<Constant>(V);
|
2016-06-22 21:20:59 +02:00
|
|
|
if (!CV || !CV->getType()->isVectorTy())
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
unsigned MinSignBits = TyBits;
|
|
|
|
unsigned NumElts = CV->getType()->getVectorNumElements();
|
|
|
|
for (unsigned i = 0; i != NumElts; ++i) {
|
|
|
|
// If we find a non-ConstantInt, bail out.
|
|
|
|
auto *Elt = dyn_cast_or_null<ConstantInt>(CV->getAggregateElement(i));
|
|
|
|
if (!Elt)
|
|
|
|
return 0;
|
|
|
|
|
2017-10-21 18:35:41 +02:00
|
|
|
MinSignBits = std::min(MinSignBits, Elt->getValue().getNumSignBits());
|
2016-06-22 21:20:59 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return MinSignBits;
|
|
|
|
}
|
2008-06-02 03:18:21 +02:00
|
|
|
|
2017-02-25 21:30:45 +01:00
|
|
|
static unsigned ComputeNumSignBitsImpl(const Value *V, unsigned Depth,
|
|
|
|
const Query &Q);
|
|
|
|
|
|
|
|
static unsigned ComputeNumSignBits(const Value *V, unsigned Depth,
|
|
|
|
const Query &Q) {
|
|
|
|
unsigned Result = ComputeNumSignBitsImpl(V, Depth, Q);
|
|
|
|
assert(Result > 0 && "At least one sign bit needs to be present!");
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
2014-11-04 17:27:42 +01: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
|
2016-06-22 21:20:59 +02:00
|
|
|
/// other, so we return 3. For vectors, return the number of sign bits for the
|
2018-02-28 20:08:52 +01:00
|
|
|
/// vector element with the minimum number of known sign bits.
|
2017-02-25 21:30:45 +01:00
|
|
|
static unsigned ComputeNumSignBitsImpl(const Value *V, unsigned Depth,
|
|
|
|
const Query &Q) {
|
2017-08-22 00:56:12 +02:00
|
|
|
assert(Depth <= MaxDepth && "Limit Search Depth");
|
2017-02-25 21:30:45 +01:00
|
|
|
|
|
|
|
// We return the minimum number of sign bits that are guaranteed to be present
|
|
|
|
// in V, so for undef we have to conservatively return 1. We don't have the
|
|
|
|
// same behavior for poison though -- that's a FIXME today.
|
|
|
|
|
2018-02-14 07:58:08 +01:00
|
|
|
Type *ScalarTy = V->getType()->getScalarType();
|
|
|
|
unsigned TyBits = ScalarTy->isPointerTy() ?
|
|
|
|
Q.DL.getIndexTypeSizeInBits(ScalarTy) :
|
|
|
|
Q.DL.getTypeSizeInBits(ScalarTy);
|
|
|
|
|
2008-06-02 03:18:21 +02:00
|
|
|
unsigned Tmp, Tmp2;
|
|
|
|
unsigned FirstAnswer = 1;
|
|
|
|
|
2014-05-14 23:14:37 +02:00
|
|
|
// Note that ConstantInt is handled by the general computeKnownBits case
|
2008-06-02 20:39:07 +02:00
|
|
|
// below.
|
|
|
|
|
2016-12-20 20:06:15 +01:00
|
|
|
if (Depth == MaxDepth)
|
2008-06-02 03:18:21 +02:00
|
|
|
return 1; // Limit search depth.
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
const Operator *U = dyn_cast<Operator>(V);
|
2009-07-17 22:47:02 +02:00
|
|
|
switch (Operator::getOpcode(V)) {
|
2008-06-02 03:18:21 +02:00
|
|
|
default: break;
|
|
|
|
case Instruction::SExt:
|
2009-12-02 05:59:58 +01:00
|
|
|
Tmp = TyBits - U->getOperand(0)->getType()->getScalarSizeInBits();
|
2016-01-15 23:22:04 +01:00
|
|
|
return ComputeNumSignBits(U->getOperand(0), Depth + 1, Q) + Tmp;
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2015-03-06 01:23:58 +01:00
|
|
|
case Instruction::SDiv: {
|
2015-03-03 22:39:02 +01:00
|
|
|
const APInt *Denominator;
|
|
|
|
// sdiv X, C -> adds log(C) sign bits.
|
|
|
|
if (match(U->getOperand(1), m_APInt(Denominator))) {
|
|
|
|
|
|
|
|
// Ignore non-positive denominator.
|
|
|
|
if (!Denominator->isStrictlyPositive())
|
|
|
|
break;
|
|
|
|
|
|
|
|
// Calculate the incoming numerator bits.
|
2016-01-15 23:22:04 +01:00
|
|
|
unsigned NumBits = ComputeNumSignBits(U->getOperand(0), Depth + 1, Q);
|
2015-03-03 22:39:02 +01:00
|
|
|
|
|
|
|
// Add floor(log(C)) bits to the numerator bits.
|
|
|
|
return std::min(TyBits, NumBits + Denominator->logBase2());
|
|
|
|
}
|
|
|
|
break;
|
2015-03-06 01:23:58 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
case Instruction::SRem: {
|
|
|
|
const APInt *Denominator;
|
2015-03-25 23:33:53 +01:00
|
|
|
// srem X, C -> we know that the result is within [-C+1,C) when C is a
|
|
|
|
// positive constant. This let us put a lower bound on the number of sign
|
|
|
|
// bits.
|
2015-03-06 01:23:58 +01:00
|
|
|
if (match(U->getOperand(1), m_APInt(Denominator))) {
|
|
|
|
|
|
|
|
// Ignore non-positive denominator.
|
|
|
|
if (!Denominator->isStrictlyPositive())
|
|
|
|
break;
|
|
|
|
|
|
|
|
// Calculate the incoming numerator bits. SRem by a positive constant
|
|
|
|
// can't lower the number of sign bits.
|
2015-03-10 03:37:25 +01:00
|
|
|
unsigned NumrBits =
|
2016-01-15 23:22:04 +01:00
|
|
|
ComputeNumSignBits(U->getOperand(0), Depth + 1, Q);
|
2015-03-06 01:23:58 +01:00
|
|
|
|
|
|
|
// Calculate the leading sign bit constraints by examining the
|
2015-03-25 23:33:53 +01:00
|
|
|
// denominator. Given that the denominator is positive, there are two
|
|
|
|
// cases:
|
|
|
|
//
|
|
|
|
// 1. the numerator is positive. The result range is [0,C) and [0,C) u<
|
|
|
|
// (1 << ceilLogBase2(C)).
|
|
|
|
//
|
|
|
|
// 2. the numerator is negative. Then the result range is (-C,0] and
|
|
|
|
// integers in (-C,0] are either 0 or >u (-1 << ceilLogBase2(C)).
|
|
|
|
//
|
|
|
|
// Thus a lower bound on the number of sign bits is `TyBits -
|
|
|
|
// ceilLogBase2(C)`.
|
|
|
|
|
|
|
|
unsigned ResBits = TyBits - Denominator->ceilLogBase2();
|
2015-03-06 01:23:58 +01:00
|
|
|
return std::max(NumrBits, ResBits);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
2015-03-03 22:39:02 +01:00
|
|
|
|
2012-01-26 22:37:55 +01:00
|
|
|
case Instruction::AShr: {
|
2016-01-15 23:22:04 +01:00
|
|
|
Tmp = ComputeNumSignBits(U->getOperand(0), Depth + 1, Q);
|
2012-01-26 22:37:55 +01:00
|
|
|
// ashr X, C -> adds C sign bits. Vectors too.
|
|
|
|
const APInt *ShAmt;
|
|
|
|
if (match(U->getOperand(1), m_APInt(ShAmt))) {
|
2018-01-01 23:44:59 +01:00
|
|
|
if (ShAmt->uge(TyBits))
|
2017-02-25 21:30:45 +01:00
|
|
|
break; // Bad shift.
|
2018-01-01 23:44:59 +01:00
|
|
|
unsigned ShAmtLimited = ShAmt->getZExtValue();
|
2017-02-25 21:30:45 +01:00
|
|
|
Tmp += ShAmtLimited;
|
2008-06-02 03:18:21 +02:00
|
|
|
if (Tmp > TyBits) Tmp = TyBits;
|
|
|
|
}
|
|
|
|
return Tmp;
|
2012-01-26 22:37:55 +01:00
|
|
|
}
|
|
|
|
case Instruction::Shl: {
|
|
|
|
const APInt *ShAmt;
|
|
|
|
if (match(U->getOperand(1), m_APInt(ShAmt))) {
|
2008-06-02 03:18:21 +02:00
|
|
|
// shl destroys sign bits.
|
2016-01-15 23:22:04 +01:00
|
|
|
Tmp = ComputeNumSignBits(U->getOperand(0), Depth + 1, Q);
|
2018-01-01 23:44:59 +01:00
|
|
|
if (ShAmt->uge(TyBits) || // Bad shift.
|
|
|
|
ShAmt->uge(Tmp)) break; // Shifted all sign bits out.
|
2012-01-26 22:37:55 +01:00
|
|
|
Tmp2 = ShAmt->getZExtValue();
|
|
|
|
return Tmp - Tmp2;
|
2008-06-02 03:18:21 +02:00
|
|
|
}
|
|
|
|
break;
|
2012-01-26 22:37:55 +01:00
|
|
|
}
|
2008-06-02 03:18:21 +02: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.
|
2016-01-15 23:22:04 +01:00
|
|
|
Tmp = ComputeNumSignBits(U->getOperand(0), Depth + 1, Q);
|
2008-06-02 03:18:21 +02:00
|
|
|
if (Tmp != 1) {
|
2016-01-15 23:22:04 +01:00
|
|
|
Tmp2 = ComputeNumSignBits(U->getOperand(1), Depth + 1, Q);
|
2008-06-02 03:18:21 +02: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-14 23:14:37 +02:00
|
|
|
// computeKnownBits, and pick whichever answer is better.
|
2008-06-02 03:18:21 +02:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
2018-08-23 01:27:50 +02:00
|
|
|
case Instruction::Select: {
|
|
|
|
// If we have a clamp pattern, we know that the number of sign bits will be
|
|
|
|
// the minimum of the clamp min/max range.
|
|
|
|
const Value *X;
|
|
|
|
const APInt *CLow, *CHigh;
|
|
|
|
if (isSignedMinMaxClamp(U, X, CLow, CHigh))
|
|
|
|
return std::min(CLow->getNumSignBits(), CHigh->getNumSignBits());
|
|
|
|
|
2016-01-15 23:22:04 +01:00
|
|
|
Tmp = ComputeNumSignBits(U->getOperand(1), Depth + 1, Q);
|
2018-07-25 18:39:24 +02:00
|
|
|
if (Tmp == 1) break;
|
2016-01-15 23:22:04 +01:00
|
|
|
Tmp2 = ComputeNumSignBits(U->getOperand(2), Depth + 1, Q);
|
2008-06-02 03:18:21 +02:00
|
|
|
return std::min(Tmp, Tmp2);
|
2018-08-23 01:27:50 +02:00
|
|
|
}
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2008-06-02 03:18:21 +02: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.
|
2016-01-15 23:22:04 +01:00
|
|
|
Tmp = ComputeNumSignBits(U->getOperand(0), Depth + 1, Q);
|
2018-07-25 18:39:24 +02:00
|
|
|
if (Tmp == 1) break;
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2008-06-02 03:18:21 +02:00
|
|
|
// Special case decrementing a value (ADD X, -1):
|
2014-12-26 10:20:17 +01:00
|
|
|
if (const auto *CRHS = dyn_cast<Constant>(U->getOperand(1)))
|
2008-06-02 03:18:21 +02:00
|
|
|
if (CRHS->isAllOnesValue()) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits Known(TyBits);
|
|
|
|
computeKnownBits(U->getOperand(0), Known, Depth + 1, Q);
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2008-06-02 03:18:21 +02:00
|
|
|
// If the input is known to be 0 or 1, the output is 0/-1, which is all
|
|
|
|
// sign bits set.
|
2017-04-26 18:39:58 +02:00
|
|
|
if ((Known.Zero | 1).isAllOnesValue())
|
2008-06-02 03:18:21 +02:00
|
|
|
return TyBits;
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2008-06-02 03:18:21 +02:00
|
|
|
// If we are subtracting one from a positive number, there is no carry
|
|
|
|
// out of the result.
|
2017-04-29 18:43:11 +02:00
|
|
|
if (Known.isNonNegative())
|
2008-06-02 03:18:21 +02:00
|
|
|
return Tmp;
|
|
|
|
}
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2016-01-15 23:22:04 +01:00
|
|
|
Tmp2 = ComputeNumSignBits(U->getOperand(1), Depth + 1, Q);
|
2018-07-25 18:39:24 +02:00
|
|
|
if (Tmp2 == 1) break;
|
2010-01-08 00:44:37 +01:00
|
|
|
return std::min(Tmp, Tmp2)-1;
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2008-06-02 03:18:21 +02:00
|
|
|
case Instruction::Sub:
|
2016-01-15 23:22:04 +01:00
|
|
|
Tmp2 = ComputeNumSignBits(U->getOperand(1), Depth + 1, Q);
|
2018-07-25 18:39:24 +02:00
|
|
|
if (Tmp2 == 1) break;
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2008-06-02 03:18:21 +02:00
|
|
|
// Handle NEG.
|
2014-12-26 10:20:17 +01:00
|
|
|
if (const auto *CLHS = dyn_cast<Constant>(U->getOperand(0)))
|
2008-06-02 03:18:21 +02:00
|
|
|
if (CLHS->isNullValue()) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits Known(TyBits);
|
|
|
|
computeKnownBits(U->getOperand(1), Known, Depth + 1, Q);
|
2008-06-02 03:18:21 +02:00
|
|
|
// If the input is known to be 0 or 1, the output is 0/-1, which is all
|
|
|
|
// sign bits set.
|
2017-04-26 18:39:58 +02:00
|
|
|
if ((Known.Zero | 1).isAllOnesValue())
|
2008-06-02 03:18:21 +02:00
|
|
|
return TyBits;
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2008-06-02 03:18:21 +02: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.
|
2017-04-29 18:43:11 +02:00
|
|
|
if (Known.isNonNegative())
|
2008-06-02 03:18:21 +02:00
|
|
|
return Tmp2;
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2008-06-02 03:18:21 +02:00
|
|
|
// Otherwise, we treat this like a SUB.
|
|
|
|
}
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2008-06-02 03:18:21 +02:00
|
|
|
// Sub can have at most one carry bit. Thus we know that the output
|
|
|
|
// is, at worst, one more bit than the inputs.
|
2016-01-15 23:22:04 +01:00
|
|
|
Tmp = ComputeNumSignBits(U->getOperand(0), Depth + 1, Q);
|
2018-07-25 18:39:24 +02:00
|
|
|
if (Tmp == 1) break;
|
2010-01-08 00:44:37 +01:00
|
|
|
return std::min(Tmp, Tmp2)-1;
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2017-08-19 00:56:55 +02:00
|
|
|
case Instruction::Mul: {
|
|
|
|
// The output of the Mul can be at most twice the valid bits in the inputs.
|
|
|
|
unsigned SignBitsOp0 = ComputeNumSignBits(U->getOperand(0), Depth + 1, Q);
|
2018-07-25 18:39:24 +02:00
|
|
|
if (SignBitsOp0 == 1) break;
|
2017-08-19 00:56:55 +02:00
|
|
|
unsigned SignBitsOp1 = ComputeNumSignBits(U->getOperand(1), Depth + 1, Q);
|
2018-07-25 18:39:24 +02:00
|
|
|
if (SignBitsOp1 == 1) break;
|
2017-08-19 00:56:55 +02:00
|
|
|
unsigned OutValidBits =
|
|
|
|
(TyBits - SignBitsOp0 + 1) + (TyBits - SignBitsOp1 + 1);
|
|
|
|
return OutValidBits > TyBits ? 1 : TyBits - OutValidBits + 1;
|
|
|
|
}
|
|
|
|
|
2010-01-08 00:44:37 +01:00
|
|
|
case Instruction::PHI: {
|
2016-08-13 03:05:32 +02:00
|
|
|
const PHINode *PN = cast<PHINode>(U);
|
2015-01-04 08:06:53 +01:00
|
|
|
unsigned NumIncomingValues = PN->getNumIncomingValues();
|
2010-01-08 00:44:37 +01:00
|
|
|
// Don't analyze large in-degree PHIs.
|
2015-01-04 08:06:53 +01:00
|
|
|
if (NumIncomingValues > 4) break;
|
|
|
|
// Unreachable blocks may have zero-operand PHI nodes.
|
|
|
|
if (NumIncomingValues == 0) break;
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2010-01-08 00:44:37 +01:00
|
|
|
// Take the minimum of all incoming values. This can't infinitely loop
|
|
|
|
// because of our depth threshold.
|
2016-01-15 23:22:04 +01:00
|
|
|
Tmp = ComputeNumSignBits(PN->getIncomingValue(0), Depth + 1, Q);
|
2015-01-04 08:06:53 +01:00
|
|
|
for (unsigned i = 1, e = NumIncomingValues; i != e; ++i) {
|
2010-01-08 00:44:37 +01:00
|
|
|
if (Tmp == 1) return Tmp;
|
2015-03-10 03:37:25 +01:00
|
|
|
Tmp = std::min(
|
2016-01-15 23:22:04 +01:00
|
|
|
Tmp, ComputeNumSignBits(PN->getIncomingValue(i), Depth + 1, Q));
|
2010-01-08 00:44:37 +01:00
|
|
|
}
|
|
|
|
return Tmp;
|
|
|
|
}
|
|
|
|
|
2008-06-02 03:18:21 +02: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;
|
2016-10-06 11:56:21 +02:00
|
|
|
|
|
|
|
case Instruction::ExtractElement:
|
|
|
|
// Look through extract element. At the moment we keep this simple and skip
|
|
|
|
// tracking the specific element. But at least we might find information
|
|
|
|
// valid for all elements of the vector (for example if vector is sign
|
|
|
|
// extended, shifted, etc).
|
|
|
|
return ComputeNumSignBits(U->getOperand(0), Depth + 1, Q);
|
2018-10-26 23:05:14 +02:00
|
|
|
|
2018-11-02 16:51:47 +01:00
|
|
|
case Instruction::ShuffleVector: {
|
2018-11-03 14:18:55 +01:00
|
|
|
// TODO: This is copied almost directly from the SelectionDAG version of
|
|
|
|
// ComputeNumSignBits. It would be better if we could share common
|
|
|
|
// code. If not, make sure that changes are translated to the DAG.
|
|
|
|
|
|
|
|
// Collect the minimum number of sign bits that are shared by every vector
|
|
|
|
// element referenced by the shuffle.
|
|
|
|
auto *Shuf = cast<ShuffleVectorInst>(U);
|
|
|
|
int NumElts = Shuf->getOperand(0)->getType()->getVectorNumElements();
|
|
|
|
int NumMaskElts = Shuf->getMask()->getType()->getVectorNumElements();
|
|
|
|
APInt DemandedLHS(NumElts, 0), DemandedRHS(NumElts, 0);
|
|
|
|
for (int i = 0; i != NumMaskElts; ++i) {
|
|
|
|
int M = Shuf->getMaskValue(i);
|
|
|
|
assert(M < NumElts * 2 && "Invalid shuffle mask constant");
|
|
|
|
// For undef elements, we don't know anything about the common state of
|
|
|
|
// the shuffle result.
|
|
|
|
if (M == -1)
|
|
|
|
return 1;
|
|
|
|
if (M < NumElts)
|
|
|
|
DemandedLHS.setBit(M % NumElts);
|
|
|
|
else
|
|
|
|
DemandedRHS.setBit(M % NumElts);
|
|
|
|
}
|
|
|
|
Tmp = std::numeric_limits<unsigned>::max();
|
|
|
|
if (!!DemandedLHS)
|
|
|
|
Tmp = ComputeNumSignBits(Shuf->getOperand(0), Depth + 1, Q);
|
|
|
|
if (!!DemandedRHS) {
|
|
|
|
Tmp2 = ComputeNumSignBits(Shuf->getOperand(1), Depth + 1, Q);
|
|
|
|
Tmp = std::min(Tmp, Tmp2);
|
|
|
|
}
|
|
|
|
// If we don't know anything, early out and try computeKnownBits fall-back.
|
|
|
|
if (Tmp == 1)
|
2018-11-02 16:51:47 +01:00
|
|
|
break;
|
2018-11-03 14:18:55 +01:00
|
|
|
assert(Tmp <= V->getType()->getScalarSizeInBits() &&
|
|
|
|
"Failed to determine minimum sign bits");
|
|
|
|
return Tmp;
|
2008-06-02 03:18:21 +02:00
|
|
|
}
|
2018-11-02 16:51:47 +01:00
|
|
|
}
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2008-06-02 03:18:21 +02:00
|
|
|
// Finally, if we can prove that the top bits of the result are 0's or 1's,
|
|
|
|
// use this information.
|
2016-06-22 21:20:59 +02:00
|
|
|
|
|
|
|
// If we can examine all elements of a vector constant successfully, we're
|
|
|
|
// done (we can't do any better than that). If not, keep trying.
|
|
|
|
if (unsigned VecSignBits = computeNumSignBitsVectorConstant(V, TyBits))
|
|
|
|
return VecSignBits;
|
|
|
|
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits Known(TyBits);
|
|
|
|
computeKnownBits(V, Known, Depth, Q);
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2016-06-23 19:41:59 +02:00
|
|
|
// If we know that the sign bit is either zero or one, determine the number of
|
|
|
|
// identical bits in the top of the input value.
|
2017-05-12 19:20:30 +02:00
|
|
|
return std::max(FirstAnswer, Known.countMinSignBits());
|
2008-06-02 03:18:21 +02:00
|
|
|
}
|
2008-06-02 03:29:46 +02:00
|
|
|
|
2014-11-04 17:27:42 +01: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 09:28:35 +01:00
|
|
|
/// through SExt instructions only if LookThroughSExt is true.
|
|
|
|
bool llvm::ComputeMultiple(Value *V, unsigned Base, Value *&Multiple,
|
2009-11-18 01:58:27 +01:00
|
|
|
bool LookThroughSExt, unsigned Depth) {
|
2009-11-10 09:28:35 +01:00
|
|
|
const unsigned MaxDepth = 6;
|
|
|
|
|
2009-11-18 01:58:27 +01:00
|
|
|
assert(V && "No Value?");
|
2009-11-10 09:28:35 +01:00
|
|
|
assert(Depth <= MaxDepth && "Limit Search Depth");
|
2010-02-15 17:12:20 +01:00
|
|
|
assert(V->getType()->isIntegerTy() && "Not integer or pointer type!");
|
2009-11-10 09:28:35 +01:00
|
|
|
|
2011-07-18 06:54:35 +02:00
|
|
|
Type *T = V->getType();
|
2009-11-10 09:28:35 +01:00
|
|
|
|
2009-11-18 01:58:27 +01:00
|
|
|
ConstantInt *CI = dyn_cast<ConstantInt>(V);
|
2009-11-10 09:28:35 +01:00
|
|
|
|
|
|
|
if (Base == 0)
|
|
|
|
return false;
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2009-11-10 09:28:35 +01: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-22 20:15:35 +01:00
|
|
|
return true;
|
2009-11-10 09:28:35 +01:00
|
|
|
}
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2009-11-10 09:28:35 +01:00
|
|
|
if (Depth == MaxDepth) return false; // Limit search depth.
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2009-11-10 09:28:35 +01:00
|
|
|
Operator *I = dyn_cast<Operator>(V);
|
|
|
|
if (!I) return false;
|
|
|
|
|
|
|
|
switch (I->getOpcode()) {
|
|
|
|
default: break;
|
2009-11-26 02:50:12 +01:00
|
|
|
case Instruction::SExt:
|
2009-11-10 09:28:35 +01:00
|
|
|
if (!LookThroughSExt) return false;
|
|
|
|
// otherwise fall through to ZExt
|
2017-06-01 00:16:24 +02:00
|
|
|
LLVM_FALLTHROUGH;
|
2009-11-26 02:50:12 +01:00
|
|
|
case Instruction::ZExt:
|
2009-11-18 01:58:27 +01:00
|
|
|
return ComputeMultiple(I->getOperand(0), Base, Multiple,
|
|
|
|
LookThroughSExt, Depth+1);
|
2009-11-10 09:28:35 +01: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 10:02:01 +01:00
|
|
|
APInt API(Op1Int.getBitWidth(), 0);
|
2010-12-01 09:53:58 +01:00
|
|
|
API.setBit(BitToSet);
|
2010-11-30 10:02:01 +01:00
|
|
|
Op1 = ConstantInt::get(V->getContext(), API);
|
2009-11-10 09:28:35 +01:00
|
|
|
}
|
|
|
|
|
2014-04-15 06:59:12 +02:00
|
|
|
Value *Mul0 = nullptr;
|
2010-09-05 19:20:46 +02: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-22 20:15:35 +01:00
|
|
|
if (Op1C->getType()->getPrimitiveSizeInBits() <
|
2010-09-05 19:20:46 +02:00
|
|
|
MulC->getType()->getPrimitiveSizeInBits())
|
|
|
|
Op1C = ConstantExpr::getZExt(Op1C, MulC->getType());
|
2012-12-22 20:15:35 +01:00
|
|
|
if (Op1C->getType()->getPrimitiveSizeInBits() >
|
2010-09-05 19:20:46 +02:00
|
|
|
MulC->getType()->getPrimitiveSizeInBits())
|
|
|
|
MulC = ConstantExpr::getZExt(MulC, Op1C->getType());
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2010-09-05 19:20:46 +02:00
|
|
|
// V == Base * (Mul0 * Op1), so return (Mul0 * Op1)
|
|
|
|
Multiple = ConstantExpr::getMul(MulC, Op1C);
|
|
|
|
return true;
|
|
|
|
}
|
2009-11-10 09:28:35 +01: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 06:59:12 +02:00
|
|
|
Value *Mul1 = nullptr;
|
2010-09-05 19:20:46 +02: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-22 20:15:35 +01:00
|
|
|
if (Op0C->getType()->getPrimitiveSizeInBits() <
|
2010-09-05 19:20:46 +02:00
|
|
|
MulC->getType()->getPrimitiveSizeInBits())
|
|
|
|
Op0C = ConstantExpr::getZExt(Op0C, MulC->getType());
|
2012-12-22 20:15:35 +01:00
|
|
|
if (Op0C->getType()->getPrimitiveSizeInBits() >
|
2010-09-05 19:20:46 +02:00
|
|
|
MulC->getType()->getPrimitiveSizeInBits())
|
|
|
|
MulC = ConstantExpr::getZExt(MulC, Op0C->getType());
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2010-09-05 19:20:46 +02:00
|
|
|
// V == Base * (Mul1 * Op0), so return (Mul1 * Op0)
|
|
|
|
Multiple = ConstantExpr::getMul(MulC, Op0C);
|
|
|
|
return true;
|
|
|
|
}
|
2009-11-10 09:28:35 +01: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;
|
|
|
|
}
|
|
|
|
|
2016-04-19 21:10:21 +02:00
|
|
|
Intrinsic::ID llvm::getIntrinsicForCallSite(ImmutableCallSite ICS,
|
|
|
|
const TargetLibraryInfo *TLI) {
|
|
|
|
const Function *F = ICS.getCalledFunction();
|
|
|
|
if (!F)
|
|
|
|
return Intrinsic::not_intrinsic;
|
|
|
|
|
|
|
|
if (F->isIntrinsic())
|
|
|
|
return F->getIntrinsicID();
|
|
|
|
|
|
|
|
if (!TLI)
|
|
|
|
return Intrinsic::not_intrinsic;
|
|
|
|
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 00:16:46 +01:00
|
|
|
LibFunc Func;
|
2016-04-19 21:10:21 +02:00
|
|
|
// We're going to make assumptions on the semantics of the functions, check
|
|
|
|
// that the target knows that it's available in this environment and it does
|
|
|
|
// not have local linkage.
|
2016-04-27 21:04:35 +02:00
|
|
|
if (!F || F->hasLocalLinkage() || !TLI->getLibFunc(*F, Func))
|
|
|
|
return Intrinsic::not_intrinsic;
|
|
|
|
|
|
|
|
if (!ICS.onlyReadsMemory())
|
2016-04-19 21:10:21 +02:00
|
|
|
return Intrinsic::not_intrinsic;
|
|
|
|
|
|
|
|
// Otherwise check if we have a call to a function that can be turned into a
|
|
|
|
// vector intrinsic.
|
|
|
|
switch (Func) {
|
|
|
|
default:
|
|
|
|
break;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 00:16:46 +01:00
|
|
|
case LibFunc_sin:
|
|
|
|
case LibFunc_sinf:
|
|
|
|
case LibFunc_sinl:
|
2016-04-27 21:04:35 +02:00
|
|
|
return Intrinsic::sin;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 00:16:46 +01:00
|
|
|
case LibFunc_cos:
|
|
|
|
case LibFunc_cosf:
|
|
|
|
case LibFunc_cosl:
|
2016-04-27 21:04:35 +02:00
|
|
|
return Intrinsic::cos;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 00:16:46 +01:00
|
|
|
case LibFunc_exp:
|
|
|
|
case LibFunc_expf:
|
|
|
|
case LibFunc_expl:
|
2016-04-27 21:04:35 +02:00
|
|
|
return Intrinsic::exp;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 00:16:46 +01:00
|
|
|
case LibFunc_exp2:
|
|
|
|
case LibFunc_exp2f:
|
|
|
|
case LibFunc_exp2l:
|
2016-04-27 21:04:35 +02:00
|
|
|
return Intrinsic::exp2;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 00:16:46 +01:00
|
|
|
case LibFunc_log:
|
|
|
|
case LibFunc_logf:
|
|
|
|
case LibFunc_logl:
|
2016-04-27 21:04:35 +02:00
|
|
|
return Intrinsic::log;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 00:16:46 +01:00
|
|
|
case LibFunc_log10:
|
|
|
|
case LibFunc_log10f:
|
|
|
|
case LibFunc_log10l:
|
2016-04-27 21:04:35 +02:00
|
|
|
return Intrinsic::log10;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 00:16:46 +01:00
|
|
|
case LibFunc_log2:
|
|
|
|
case LibFunc_log2f:
|
|
|
|
case LibFunc_log2l:
|
2016-04-27 21:04:35 +02:00
|
|
|
return Intrinsic::log2;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 00:16:46 +01:00
|
|
|
case LibFunc_fabs:
|
|
|
|
case LibFunc_fabsf:
|
|
|
|
case LibFunc_fabsl:
|
2016-04-27 21:04:35 +02:00
|
|
|
return Intrinsic::fabs;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 00:16:46 +01:00
|
|
|
case LibFunc_fmin:
|
|
|
|
case LibFunc_fminf:
|
|
|
|
case LibFunc_fminl:
|
2016-04-27 21:04:35 +02:00
|
|
|
return Intrinsic::minnum;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 00:16:46 +01:00
|
|
|
case LibFunc_fmax:
|
|
|
|
case LibFunc_fmaxf:
|
|
|
|
case LibFunc_fmaxl:
|
2016-04-27 21:04:35 +02:00
|
|
|
return Intrinsic::maxnum;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 00:16:46 +01:00
|
|
|
case LibFunc_copysign:
|
|
|
|
case LibFunc_copysignf:
|
|
|
|
case LibFunc_copysignl:
|
2016-04-27 21:04:35 +02:00
|
|
|
return Intrinsic::copysign;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 00:16:46 +01:00
|
|
|
case LibFunc_floor:
|
|
|
|
case LibFunc_floorf:
|
|
|
|
case LibFunc_floorl:
|
2016-04-27 21:04:35 +02:00
|
|
|
return Intrinsic::floor;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 00:16:46 +01:00
|
|
|
case LibFunc_ceil:
|
|
|
|
case LibFunc_ceilf:
|
|
|
|
case LibFunc_ceill:
|
2016-04-27 21:04:35 +02:00
|
|
|
return Intrinsic::ceil;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 00:16:46 +01:00
|
|
|
case LibFunc_trunc:
|
|
|
|
case LibFunc_truncf:
|
|
|
|
case LibFunc_truncl:
|
2016-04-27 21:04:35 +02:00
|
|
|
return Intrinsic::trunc;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 00:16:46 +01:00
|
|
|
case LibFunc_rint:
|
|
|
|
case LibFunc_rintf:
|
|
|
|
case LibFunc_rintl:
|
2016-04-27 21:04:35 +02:00
|
|
|
return Intrinsic::rint;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 00:16:46 +01:00
|
|
|
case LibFunc_nearbyint:
|
|
|
|
case LibFunc_nearbyintf:
|
|
|
|
case LibFunc_nearbyintl:
|
2016-04-27 21:04:35 +02:00
|
|
|
return Intrinsic::nearbyint;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 00:16:46 +01:00
|
|
|
case LibFunc_round:
|
|
|
|
case LibFunc_roundf:
|
|
|
|
case LibFunc_roundl:
|
2016-04-27 21:04:35 +02:00
|
|
|
return Intrinsic::round;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 00:16:46 +01:00
|
|
|
case LibFunc_pow:
|
|
|
|
case LibFunc_powf:
|
|
|
|
case LibFunc_powl:
|
2016-04-27 21:04:35 +02:00
|
|
|
return Intrinsic::pow;
|
[Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)
Summary:
The LibFunc::Func enum holds enumerators named for libc functions.
Unfortunately, there are real situations, including libc implementations, where
function names are actually macros (musl uses "#define fopen64 fopen", for
example; any other transitively visible macro would have similar effects).
Strictly speaking, a conforming C++ Standard Library should provide any such
macros as functions instead (via <cstdio>). However, there are some "library"
functions which are not part of the standard, and thus not subject to this
rule (fopen64, for example). So, in order to be both portable and consistent,
the enum should not use the bare function names.
The old enum naming used a namespace LibFunc and an enum Func, with bare
enumerators. This patch changes LibFunc to be an enum with enumerators prefixed
with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override
macros.)
There are additional changes required in clang.
Reviewers: rsmith
Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D28476
llvm-svn: 292848
2017-01-24 00:16:46 +01:00
|
|
|
case LibFunc_sqrt:
|
|
|
|
case LibFunc_sqrtf:
|
|
|
|
case LibFunc_sqrtl:
|
2017-11-06 23:40:09 +01:00
|
|
|
return Intrinsic::sqrt;
|
2016-04-19 21:10:21 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return Intrinsic::not_intrinsic;
|
|
|
|
}
|
|
|
|
|
2014-11-04 17:27:42 +01:00
|
|
|
/// Return true if we can prove that the specified FP value is never equal to
|
|
|
|
/// -0.0.
|
2008-06-02 03:29:46 +02:00
|
|
|
///
|
|
|
|
/// NOTE: this function will need to be revisited when we support non-default
|
|
|
|
/// rounding modes!
|
2016-04-13 08:55:52 +02:00
|
|
|
bool llvm::CannotBeNegativeZero(const Value *V, const TargetLibraryInfo *TLI,
|
|
|
|
unsigned Depth) {
|
2017-11-13 18:56:23 +01:00
|
|
|
if (auto *CFP = dyn_cast<ConstantFP>(V))
|
2008-06-02 03:29:46 +02:00
|
|
|
return !CFP->getValueAPF().isNegZero();
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2017-11-13 18:56:23 +01:00
|
|
|
// Limit search depth.
|
2016-12-20 20:06:15 +01:00
|
|
|
if (Depth == MaxDepth)
|
2017-11-13 18:56:23 +01:00
|
|
|
return false;
|
2008-06-02 03:29:46 +02:00
|
|
|
|
2017-11-13 18:56:23 +01:00
|
|
|
auto *Op = dyn_cast<Operator>(V);
|
|
|
|
if (!Op)
|
|
|
|
return false;
|
2012-12-06 01:07:09 +01:00
|
|
|
|
2017-11-13 18:56:23 +01:00
|
|
|
// Check if the nsz fast-math flag is set.
|
|
|
|
if (auto *FPO = dyn_cast<FPMathOperator>(Op))
|
2012-12-06 01:07:09 +01:00
|
|
|
if (FPO->hasNoSignedZeros())
|
|
|
|
return true;
|
|
|
|
|
2017-11-13 18:40:47 +01:00
|
|
|
// (fadd x, 0.0) is guaranteed to return +0.0, not -0.0.
|
2018-03-25 23:16:33 +02:00
|
|
|
if (match(Op, m_FAdd(m_Value(), m_PosZeroFP())))
|
2017-11-13 18:40:47 +01:00
|
|
|
return true;
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2008-06-02 03:29:46 +02:00
|
|
|
// sitofp and uitofp turn into +0.0 for zero.
|
2017-11-13 18:56:23 +01:00
|
|
|
if (isa<SIToFPInst>(Op) || isa<UIToFPInst>(Op))
|
2008-06-02 03:29:46 +02:00
|
|
|
return true;
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2017-11-13 18:56:23 +01:00
|
|
|
if (auto *Call = dyn_cast<CallInst>(Op)) {
|
|
|
|
Intrinsic::ID IID = getIntrinsicForCallSite(Call, TLI);
|
2016-04-13 08:55:52 +02:00
|
|
|
switch (IID) {
|
|
|
|
default:
|
|
|
|
break;
|
2008-06-02 03:29:46 +02:00
|
|
|
// sqrt(-0.0) = -0.0, no other negative results are possible.
|
2016-04-13 08:55:52 +02:00
|
|
|
case Intrinsic::sqrt:
|
2018-08-06 17:16:26 +02:00
|
|
|
case Intrinsic::canonicalize:
|
2017-11-13 18:56:23 +01:00
|
|
|
return CannotBeNegativeZero(Call->getArgOperand(0), TLI, Depth + 1);
|
2016-04-13 08:55:52 +02:00
|
|
|
// fabs(x) != -0.0
|
|
|
|
case Intrinsic::fabs:
|
|
|
|
return true;
|
2008-06-02 03:29:46 +02:00
|
|
|
}
|
2016-04-13 08:55:52 +02:00
|
|
|
}
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2008-06-02 03:29:46 +02:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2017-01-11 01:33:24 +01:00
|
|
|
/// If \p SignBitOnly is true, test for a known 0 sign bit rather than a
|
|
|
|
/// standard ordered compare. e.g. make -0.0 olt 0.0 be true because of the sign
|
|
|
|
/// bit despite comparing equal.
|
|
|
|
static bool cannotBeOrderedLessThanZeroImpl(const Value *V,
|
|
|
|
const TargetLibraryInfo *TLI,
|
|
|
|
bool SignBitOnly,
|
|
|
|
unsigned Depth) {
|
2017-01-27 01:58:34 +01:00
|
|
|
// TODO: This function does not do the right thing when SignBitOnly is true
|
|
|
|
// and we're lowering to a hypothetical IEEE 754-compliant-but-evil platform
|
|
|
|
// which flips the sign bits of NaNs. See
|
|
|
|
// https://llvm.org/bugs/show_bug.cgi?id=31702.
|
|
|
|
|
2017-01-11 01:33:24 +01:00
|
|
|
if (const ConstantFP *CFP = dyn_cast<ConstantFP>(V)) {
|
|
|
|
return !CFP->getValueAPF().isNegative() ||
|
|
|
|
(!SignBitOnly && CFP->getValueAPF().isZero());
|
|
|
|
}
|
2015-01-28 09:03:58 +01:00
|
|
|
|
2018-02-26 23:33:17 +01:00
|
|
|
// Handle vector of constants.
|
|
|
|
if (auto *CV = dyn_cast<Constant>(V)) {
|
|
|
|
if (CV->getType()->isVectorTy()) {
|
|
|
|
unsigned NumElts = CV->getType()->getVectorNumElements();
|
|
|
|
for (unsigned i = 0; i != NumElts; ++i) {
|
|
|
|
auto *CFP = dyn_cast_or_null<ConstantFP>(CV->getAggregateElement(i));
|
|
|
|
if (!CFP)
|
|
|
|
return false;
|
|
|
|
if (CFP->getValueAPF().isNegative() &&
|
|
|
|
(SignBitOnly || !CFP->getValueAPF().isZero()))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// All non-negative ConstantFPs.
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-12-20 20:06:15 +01:00
|
|
|
if (Depth == MaxDepth)
|
2017-01-11 01:33:24 +01:00
|
|
|
return false; // Limit search depth.
|
2015-01-28 09:03:58 +01:00
|
|
|
|
|
|
|
const Operator *I = dyn_cast<Operator>(V);
|
2017-01-11 01:33:24 +01:00
|
|
|
if (!I)
|
|
|
|
return false;
|
2015-01-28 09:03:58 +01:00
|
|
|
|
|
|
|
switch (I->getOpcode()) {
|
2017-01-11 01:33:24 +01:00
|
|
|
default:
|
|
|
|
break;
|
2016-01-13 00:37:30 +01:00
|
|
|
// Unsigned integers are always nonnegative.
|
|
|
|
case Instruction::UIToFP:
|
|
|
|
return true;
|
2015-01-28 09:03:58 +01:00
|
|
|
case Instruction::FMul:
|
|
|
|
// x*x is always non-negative or a NaN.
|
2017-01-11 01:33:24 +01:00
|
|
|
if (I->getOperand(0) == I->getOperand(1) &&
|
|
|
|
(!SignBitOnly || cast<FPMathOperator>(I)->hasNoNaNs()))
|
2015-01-28 09:03:58 +01:00
|
|
|
return true;
|
2017-01-11 01:33:24 +01:00
|
|
|
|
2016-08-17 22:30:52 +02:00
|
|
|
LLVM_FALLTHROUGH;
|
2015-01-28 09:03:58 +01:00
|
|
|
case Instruction::FAdd:
|
|
|
|
case Instruction::FDiv:
|
|
|
|
case Instruction::FRem:
|
2017-01-11 01:33:24 +01:00
|
|
|
return cannotBeOrderedLessThanZeroImpl(I->getOperand(0), TLI, SignBitOnly,
|
|
|
|
Depth + 1) &&
|
|
|
|
cannotBeOrderedLessThanZeroImpl(I->getOperand(1), TLI, SignBitOnly,
|
|
|
|
Depth + 1);
|
2016-01-13 00:37:30 +01:00
|
|
|
case Instruction::Select:
|
2017-01-11 01:33:24 +01:00
|
|
|
return cannotBeOrderedLessThanZeroImpl(I->getOperand(1), TLI, SignBitOnly,
|
|
|
|
Depth + 1) &&
|
|
|
|
cannotBeOrderedLessThanZeroImpl(I->getOperand(2), TLI, SignBitOnly,
|
|
|
|
Depth + 1);
|
2015-01-28 09:03:58 +01:00
|
|
|
case Instruction::FPExt:
|
|
|
|
case Instruction::FPTrunc:
|
|
|
|
// Widening/narrowing never change sign.
|
2017-01-11 01:33:24 +01:00
|
|
|
return cannotBeOrderedLessThanZeroImpl(I->getOperand(0), TLI, SignBitOnly,
|
|
|
|
Depth + 1);
|
2018-02-27 20:53:45 +01:00
|
|
|
case Instruction::ExtractElement:
|
|
|
|
// Look through extract element. At the moment we keep this simple and skip
|
|
|
|
// tracking the specific element. But at least we might find information
|
|
|
|
// valid for all elements of the vector.
|
|
|
|
return cannotBeOrderedLessThanZeroImpl(I->getOperand(0), TLI, SignBitOnly,
|
|
|
|
Depth + 1);
|
2016-04-13 08:55:52 +02:00
|
|
|
case Instruction::Call:
|
2017-01-26 01:10:26 +01:00
|
|
|
const auto *CI = cast<CallInst>(I);
|
|
|
|
Intrinsic::ID IID = getIntrinsicForCallSite(CI, TLI);
|
2016-04-13 08:55:52 +02:00
|
|
|
switch (IID) {
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
case Intrinsic::maxnum:
|
2018-08-10 00:40:08 +02:00
|
|
|
return (isKnownNeverNaN(I->getOperand(0), TLI) &&
|
2018-08-02 15:46:20 +02:00
|
|
|
cannotBeOrderedLessThanZeroImpl(I->getOperand(0), TLI,
|
|
|
|
SignBitOnly, Depth + 1)) ||
|
2018-08-10 00:40:08 +02:00
|
|
|
(isKnownNeverNaN(I->getOperand(1), TLI) &&
|
2018-08-02 15:46:20 +02:00
|
|
|
cannotBeOrderedLessThanZeroImpl(I->getOperand(1), TLI,
|
|
|
|
SignBitOnly, Depth + 1));
|
|
|
|
|
2018-10-19 21:01:26 +02:00
|
|
|
case Intrinsic::maximum:
|
|
|
|
return cannotBeOrderedLessThanZeroImpl(I->getOperand(0), TLI, SignBitOnly,
|
|
|
|
Depth + 1) ||
|
|
|
|
cannotBeOrderedLessThanZeroImpl(I->getOperand(1), TLI, SignBitOnly,
|
|
|
|
Depth + 1);
|
2016-04-13 08:55:52 +02:00
|
|
|
case Intrinsic::minnum:
|
2018-10-19 21:01:26 +02:00
|
|
|
case Intrinsic::minimum:
|
2017-01-11 01:33:24 +01:00
|
|
|
return cannotBeOrderedLessThanZeroImpl(I->getOperand(0), TLI, SignBitOnly,
|
|
|
|
Depth + 1) &&
|
|
|
|
cannotBeOrderedLessThanZeroImpl(I->getOperand(1), TLI, SignBitOnly,
|
|
|
|
Depth + 1);
|
2016-04-13 08:55:52 +02:00
|
|
|
case Intrinsic::exp:
|
|
|
|
case Intrinsic::exp2:
|
|
|
|
case Intrinsic::fabs:
|
|
|
|
return true;
|
2017-01-26 01:10:26 +01:00
|
|
|
|
|
|
|
case Intrinsic::sqrt:
|
|
|
|
// sqrt(x) is always >= -0 or NaN. Moreover, sqrt(x) == -0 iff x == -0.
|
|
|
|
if (!SignBitOnly)
|
|
|
|
return true;
|
|
|
|
return CI->hasNoNaNs() && (CI->hasNoSignedZeros() ||
|
|
|
|
CannotBeNegativeZero(CI->getOperand(0), TLI));
|
|
|
|
|
2016-04-13 08:55:52 +02:00
|
|
|
case Intrinsic::powi:
|
2017-01-26 01:10:26 +01:00
|
|
|
if (ConstantInt *Exponent = dyn_cast<ConstantInt>(I->getOperand(1))) {
|
2016-04-13 08:55:52 +02:00
|
|
|
// powi(x,n) is non-negative if n is even.
|
2017-01-26 01:10:26 +01:00
|
|
|
if (Exponent->getBitWidth() <= 64 && Exponent->getSExtValue() % 2u == 0)
|
2016-04-13 08:55:52 +02:00
|
|
|
return true;
|
2015-01-28 09:03:58 +01:00
|
|
|
}
|
2017-01-27 01:58:34 +01:00
|
|
|
// TODO: This is not correct. Given that exp is an integer, here are the
|
|
|
|
// ways that pow can return a negative value:
|
|
|
|
//
|
|
|
|
// pow(x, exp) --> negative if exp is odd and x is negative.
|
|
|
|
// pow(-0, exp) --> -inf if exp is negative odd.
|
|
|
|
// pow(-0, exp) --> -0 if exp is positive odd.
|
|
|
|
// pow(-inf, exp) --> -0 if exp is negative odd.
|
|
|
|
// pow(-inf, exp) --> -inf if exp is positive odd.
|
|
|
|
//
|
|
|
|
// Therefore, if !SignBitOnly, we can return true if x >= +0 or x is NaN,
|
|
|
|
// but we must return false if x == -0. Unfortunately we do not currently
|
|
|
|
// have a way of expressing this constraint. See details in
|
|
|
|
// https://llvm.org/bugs/show_bug.cgi?id=31702.
|
2017-01-11 01:33:24 +01:00
|
|
|
return cannotBeOrderedLessThanZeroImpl(I->getOperand(0), TLI, SignBitOnly,
|
|
|
|
Depth + 1);
|
2017-01-27 01:58:34 +01:00
|
|
|
|
2016-04-13 08:55:52 +02:00
|
|
|
case Intrinsic::fma:
|
|
|
|
case Intrinsic::fmuladd:
|
|
|
|
// x*x+y is non-negative if y is non-negative.
|
|
|
|
return I->getOperand(0) == I->getOperand(1) &&
|
2017-01-11 01:33:24 +01:00
|
|
|
(!SignBitOnly || cast<FPMathOperator>(I)->hasNoNaNs()) &&
|
|
|
|
cannotBeOrderedLessThanZeroImpl(I->getOperand(2), TLI, SignBitOnly,
|
|
|
|
Depth + 1);
|
2016-04-13 08:55:52 +02:00
|
|
|
}
|
2015-01-28 09:03:58 +01:00
|
|
|
break;
|
|
|
|
}
|
2016-05-07 04:08:15 +02:00
|
|
|
return false;
|
2015-01-28 09:03:58 +01:00
|
|
|
}
|
|
|
|
|
2017-01-11 01:33:24 +01:00
|
|
|
bool llvm::CannotBeOrderedLessThanZero(const Value *V,
|
|
|
|
const TargetLibraryInfo *TLI) {
|
|
|
|
return cannotBeOrderedLessThanZeroImpl(V, TLI, false, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool llvm::SignBitMustBeZero(const Value *V, const TargetLibraryInfo *TLI) {
|
|
|
|
return cannotBeOrderedLessThanZeroImpl(V, TLI, true, 0);
|
|
|
|
}
|
|
|
|
|
2018-08-10 00:40:08 +02:00
|
|
|
bool llvm::isKnownNeverNaN(const Value *V, const TargetLibraryInfo *TLI,
|
|
|
|
unsigned Depth) {
|
2017-09-06 01:13:13 +02:00
|
|
|
assert(V->getType()->isFPOrFPVectorTy() && "Querying for NaN on non-FP type");
|
|
|
|
|
|
|
|
// If we're told that NaNs won't happen, assume they won't.
|
|
|
|
if (auto *FPMathOp = dyn_cast<FPMathOperator>(V))
|
|
|
|
if (FPMathOp->hasNoNaNs())
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// Handle scalar constants.
|
|
|
|
if (auto *CFP = dyn_cast<ConstantFP>(V))
|
|
|
|
return !CFP->isNaN();
|
|
|
|
|
2018-08-10 00:40:08 +02:00
|
|
|
if (Depth == MaxDepth)
|
|
|
|
return false;
|
|
|
|
|
2018-08-20 18:51:00 +02:00
|
|
|
if (auto *Inst = dyn_cast<Instruction>(V)) {
|
|
|
|
switch (Inst->getOpcode()) {
|
|
|
|
case Instruction::FAdd:
|
|
|
|
case Instruction::FMul:
|
|
|
|
case Instruction::FSub:
|
|
|
|
case Instruction::FDiv:
|
|
|
|
case Instruction::FRem: {
|
|
|
|
// TODO: Need isKnownNeverInfinity
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
case Instruction::Select: {
|
|
|
|
return isKnownNeverNaN(Inst->getOperand(1), TLI, Depth + 1) &&
|
|
|
|
isKnownNeverNaN(Inst->getOperand(2), TLI, Depth + 1);
|
|
|
|
}
|
|
|
|
case Instruction::SIToFP:
|
|
|
|
case Instruction::UIToFP:
|
|
|
|
return true;
|
|
|
|
case Instruction::FPTrunc:
|
|
|
|
case Instruction::FPExt:
|
|
|
|
return isKnownNeverNaN(Inst->getOperand(0), TLI, Depth + 1);
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-08-10 00:40:08 +02:00
|
|
|
if (const auto *II = dyn_cast<IntrinsicInst>(V)) {
|
|
|
|
switch (II->getIntrinsicID()) {
|
|
|
|
case Intrinsic::canonicalize:
|
|
|
|
case Intrinsic::fabs:
|
|
|
|
case Intrinsic::copysign:
|
2018-08-20 18:51:00 +02:00
|
|
|
case Intrinsic::exp:
|
|
|
|
case Intrinsic::exp2:
|
|
|
|
case Intrinsic::floor:
|
|
|
|
case Intrinsic::ceil:
|
|
|
|
case Intrinsic::trunc:
|
|
|
|
case Intrinsic::rint:
|
|
|
|
case Intrinsic::nearbyint:
|
|
|
|
case Intrinsic::round:
|
2018-08-10 00:40:08 +02:00
|
|
|
return isKnownNeverNaN(II->getArgOperand(0), TLI, Depth + 1);
|
|
|
|
case Intrinsic::sqrt:
|
|
|
|
return isKnownNeverNaN(II->getArgOperand(0), TLI, Depth + 1) &&
|
|
|
|
CannotBeOrderedLessThanZero(II->getArgOperand(0), TLI);
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-09-06 01:13:13 +02:00
|
|
|
// Bail out for constant expressions, but try to handle vector constants.
|
|
|
|
if (!V->getType()->isVectorTy() || !isa<Constant>(V))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// For vectors, verify that each element is not NaN.
|
|
|
|
unsigned NumElts = V->getType()->getVectorNumElements();
|
|
|
|
for (unsigned i = 0; i != NumElts; ++i) {
|
|
|
|
Constant *Elt = cast<Constant>(V)->getAggregateElement(i);
|
|
|
|
if (!Elt)
|
|
|
|
return false;
|
|
|
|
if (isa<UndefValue>(Elt))
|
|
|
|
continue;
|
|
|
|
auto *CElt = dyn_cast<ConstantFP>(Elt);
|
|
|
|
if (!CElt || CElt->isNaN())
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
// All elements were confirmed not-NaN or undefined.
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2010-12-26 21:15:01 +01:00
|
|
|
Value *llvm::isBytewiseValue(Value *V) {
|
2018-09-21 07:17:42 +02:00
|
|
|
|
2010-12-26 21:15:01 +01:00
|
|
|
// All byte-wide stores are splatable, even of arbitrary variables.
|
2018-09-21 07:17:42 +02:00
|
|
|
if (V->getType()->isIntegerTy(8))
|
|
|
|
return V;
|
|
|
|
|
|
|
|
LLVMContext &Ctx = V->getContext();
|
|
|
|
|
|
|
|
// Undef don't care.
|
|
|
|
auto *UndefInt8 = UndefValue::get(Type::getInt8Ty(Ctx));
|
|
|
|
if (isa<UndefValue>(V))
|
|
|
|
return UndefInt8;
|
|
|
|
|
|
|
|
Constant *C = dyn_cast<Constant>(V);
|
|
|
|
if (!C) {
|
|
|
|
// 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.
|
|
|
|
return nullptr;
|
|
|
|
}
|
2011-02-19 20:35:49 +01:00
|
|
|
|
|
|
|
// Handle 'null' ConstantArrayZero etc.
|
2018-09-21 07:17:42 +02:00
|
|
|
if (C->isNullValue())
|
|
|
|
return Constant::getNullValue(Type::getInt8Ty(Ctx));
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2018-09-21 07:17:42 +02:00
|
|
|
// Constant floating-point values can be handled as integer values if the
|
2012-12-22 20:15:35 +01:00
|
|
|
// corresponding integer value is "byteable". An important case is 0.0.
|
2018-09-21 07:17:42 +02:00
|
|
|
if (ConstantFP *CFP = dyn_cast<ConstantFP>(C)) {
|
|
|
|
Type *Ty = nullptr;
|
|
|
|
if (CFP->getType()->isHalfTy())
|
|
|
|
Ty = Type::getInt16Ty(Ctx);
|
|
|
|
else if (CFP->getType()->isFloatTy())
|
|
|
|
Ty = Type::getInt32Ty(Ctx);
|
|
|
|
else if (CFP->getType()->isDoubleTy())
|
|
|
|
Ty = Type::getInt64Ty(Ctx);
|
2010-12-26 21:15:01 +01:00
|
|
|
// Don't handle long double formats, which have strange constraints.
|
2018-09-21 07:17:42 +02:00
|
|
|
return Ty ? isBytewiseValue(ConstantExpr::getBitCast(CFP, Ty)) : nullptr;
|
2010-12-26 21:15:01 +01:00
|
|
|
}
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2015-02-07 20:29:02 +01:00
|
|
|
// We can handle constant integers that are multiple of 8 bits.
|
2018-09-21 07:17:42 +02:00
|
|
|
if (ConstantInt *CI = dyn_cast<ConstantInt>(C)) {
|
2015-02-07 20:29:02 +01:00
|
|
|
if (CI->getBitWidth() % 8 == 0) {
|
|
|
|
assert(CI->getBitWidth() > 8 && "8 bits should be handled above!");
|
2015-03-25 17:49:59 +01:00
|
|
|
if (!CI->getValue().isSplat(8))
|
2015-02-07 20:29:02 +01:00
|
|
|
return nullptr;
|
2018-09-21 07:17:42 +02:00
|
|
|
return ConstantInt::get(Ctx, CI->getValue().trunc(8));
|
2010-12-26 21:15:01 +01:00
|
|
|
}
|
|
|
|
}
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2018-09-21 07:17:42 +02:00
|
|
|
auto Merge = [&](Value *LHS, Value *RHS) -> Value * {
|
|
|
|
if (LHS == RHS)
|
|
|
|
return LHS;
|
|
|
|
if (!LHS || !RHS)
|
2014-04-15 06:59:12 +02:00
|
|
|
return nullptr;
|
2018-09-21 07:17:42 +02:00
|
|
|
if (LHS == UndefInt8)
|
|
|
|
return RHS;
|
|
|
|
if (RHS == UndefInt8)
|
|
|
|
return LHS;
|
|
|
|
return nullptr;
|
|
|
|
};
|
|
|
|
|
|
|
|
if (ConstantDataSequential *CA = dyn_cast<ConstantDataSequential>(C)) {
|
|
|
|
Value *Val = UndefInt8;
|
|
|
|
for (unsigned I = 0, E = CA->getNumElements(); I != E; ++I)
|
|
|
|
if (!(Val = Merge(Val, isBytewiseValue(CA->getElementAsConstant(I)))))
|
2014-04-15 06:59:12 +02:00
|
|
|
return nullptr;
|
2018-09-21 07:17:42 +02:00
|
|
|
return Val;
|
|
|
|
}
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2018-09-21 07:17:42 +02:00
|
|
|
if (isa<ConstantVector>(C)) {
|
|
|
|
Constant *Splat = cast<ConstantVector>(C)->getSplatValue();
|
|
|
|
return Splat ? isBytewiseValue(Splat) : nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (isa<ConstantArray>(C) || isa<ConstantStruct>(C)) {
|
|
|
|
Value *Val = UndefInt8;
|
|
|
|
for (unsigned I = 0, E = C->getNumOperands(); I != E; ++I)
|
|
|
|
if (!(Val = Merge(Val, isBytewiseValue(C->getOperand(I)))))
|
|
|
|
return nullptr;
|
2010-12-26 21:15:01 +01:00
|
|
|
return Val;
|
|
|
|
}
|
2011-12-06 01:19:08 +01:00
|
|
|
|
2018-09-21 07:17:42 +02:00
|
|
|
// Don't try to handle the handful of other constants.
|
2014-04-15 06:59:12 +02:00
|
|
|
return nullptr;
|
2010-12-26 21:15:01 +01:00
|
|
|
}
|
|
|
|
|
2008-06-16 14:48:21 +02: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 06:54:35 +02:00
|
|
|
static Value *BuildSubAggregate(Value *From, Value* To, Type *IndexedType,
|
2013-07-11 18:22:38 +02:00
|
|
|
SmallVectorImpl<unsigned> &Idxs,
|
2009-08-07 03:32:21 +02:00
|
|
|
unsigned IdxSkip,
|
|
|
|
Instruction *InsertBefore) {
|
2017-09-01 23:37:29 +02:00
|
|
|
StructType *STy = dyn_cast<StructType>(IndexedType);
|
2008-06-16 14:48:21 +02:00
|
|
|
if (STy) {
|
2008-06-16 16:13:46 +02:00
|
|
|
// Save the original To argument so we can modify it
|
|
|
|
Value *OrigTo = To;
|
2008-06-16 14:48:21 +02: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 16:13:46 +02:00
|
|
|
Value *PrevTo = To;
|
2008-06-16 14:57:37 +02:00
|
|
|
To = BuildSubAggregate(From, To, STy->getElementType(i), Idxs, IdxSkip,
|
2009-11-23 04:29:18 +01:00
|
|
|
InsertBefore);
|
2008-06-16 14:48:21 +02:00
|
|
|
Idxs.pop_back();
|
2008-06-16 16:13:46 +02: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 14:48:21 +02:00
|
|
|
}
|
2011-04-15 07:18:47 +02:00
|
|
|
// If we successfully found a value for each of our subaggregates
|
2008-06-16 16:13:46 +02:00
|
|
|
if (To)
|
|
|
|
return To;
|
2008-06-16 14:48:21 +02:00
|
|
|
}
|
2008-06-16 16:13:46 +02: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-22 20:15:35 +01:00
|
|
|
|
2008-06-16 16:13:46 +02:00
|
|
|
// Find the value that is at that particular spot
|
2011-07-13 12:26:04 +02:00
|
|
|
Value *V = FindInsertedValue(From, Idxs);
|
2008-06-16 16:13:46 +02:00
|
|
|
|
|
|
|
if (!V)
|
2014-04-15 06:59:12 +02:00
|
|
|
return nullptr;
|
2008-06-16 16:13:46 +02:00
|
|
|
|
2018-02-28 20:08:52 +01:00
|
|
|
// Insert the value in the new (sub) aggregate
|
2017-09-01 23:37:29 +02:00
|
|
|
return InsertValueInst::Create(To, V, makeArrayRef(Idxs).slice(IdxSkip),
|
|
|
|
"tmp", InsertBefore);
|
2008-06-16 14:48:21 +02: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 16:13:46 +02: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 14:48:21 +02:00
|
|
|
//
|
2008-06-16 16:13:46 +02:00
|
|
|
// All inserted insertvalue instructions are inserted before InsertBefore
|
2011-07-13 12:26:04 +02:00
|
|
|
static Value *BuildSubAggregate(Value *From, ArrayRef<unsigned> idx_range,
|
2009-08-07 03:32:21 +02:00
|
|
|
Instruction *InsertBefore) {
|
2008-06-16 15:28:31 +02:00
|
|
|
assert(InsertBefore && "Must have someplace to insert!");
|
2011-07-18 06:54:35 +02:00
|
|
|
Type *IndexedType = ExtractValueInst::getIndexedType(From->getType(),
|
2011-07-13 12:26:04 +02:00
|
|
|
idx_range);
|
2009-07-31 01:03:37 +02:00
|
|
|
Value *To = UndefValue::get(IndexedType);
|
2011-07-13 12:26:04 +02:00
|
|
|
SmallVector<unsigned, 10> Idxs(idx_range.begin(), idx_range.end());
|
2008-06-16 14:48:21 +02:00
|
|
|
unsigned IdxSkip = Idxs.size();
|
|
|
|
|
2009-11-23 04:29:18 +01:00
|
|
|
return BuildSubAggregate(From, To, IndexedType, Idxs, IdxSkip, InsertBefore);
|
2008-06-16 14:48:21 +02:00
|
|
|
}
|
|
|
|
|
2018-02-28 20:08:52 +01:00
|
|
|
/// Given an aggregate and a sequence of indices, see if the scalar value
|
|
|
|
/// indexed is already around as a register, for example if it was inserted
|
|
|
|
/// directly into the aggregate.
|
2008-06-16 16:13:46 +02:00
|
|
|
///
|
|
|
|
/// If InsertBefore is not null, this function will duplicate (modified)
|
|
|
|
/// insertvalues when a part of a nested struct is extracted.
|
2011-07-13 12:26:04 +02:00
|
|
|
Value *llvm::FindInsertedValue(Value *V, ArrayRef<unsigned> idx_range,
|
|
|
|
Instruction *InsertBefore) {
|
2008-06-16 14:48:21 +02:00
|
|
|
// Nothing to index? Just return V then (this is useful at the end of our
|
2012-01-24 08:54:10 +01:00
|
|
|
// recursion).
|
2011-07-13 12:26:04 +02:00
|
|
|
if (idx_range.empty())
|
2008-06-16 14:48:21 +02:00
|
|
|
return V;
|
2012-01-24 08:54:10 +01: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 07:48:06 +01:00
|
|
|
|
|
|
|
if (Constant *C = dyn_cast<Constant>(V)) {
|
|
|
|
C = C->getAggregateElement(idx_range[0]);
|
2014-04-15 06:59:12 +02:00
|
|
|
if (!C) return nullptr;
|
2012-01-25 07:48:06 +01:00
|
|
|
return FindInsertedValue(C, idx_range.slice(1), InsertBefore);
|
|
|
|
}
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2012-01-24 08:54:10 +01:00
|
|
|
if (InsertValueInst *I = dyn_cast<InsertValueInst>(V)) {
|
2008-06-16 14:48:21 +02:00
|
|
|
// Loop the indices for the insertvalue instruction in parallel with the
|
|
|
|
// requested indices
|
2011-07-13 12:26:04 +02:00
|
|
|
const unsigned *req_idx = idx_range.begin();
|
2008-06-16 14:57:37 +02:00
|
|
|
for (const unsigned *i = I->idx_begin(), *e = I->idx_end();
|
|
|
|
i != e; ++i, ++req_idx) {
|
2011-07-13 12:26:04 +02:00
|
|
|
if (req_idx == idx_range.end()) {
|
2012-01-24 08:54:10 +01:00
|
|
|
// We can't handle this without inserting insertvalues
|
|
|
|
if (!InsertBefore)
|
2014-04-15 06:59:12 +02:00
|
|
|
return nullptr;
|
2012-01-24 08:54:10 +01: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 10:47:31 +02:00
|
|
|
}
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2008-06-16 14:48:21 +02:00
|
|
|
// This insert value inserts something else than what we are looking for.
|
2015-08-08 20:27:36 +02:00
|
|
|
// See if the (aggregate) value inserted into has the value we are
|
2008-06-16 14:48:21 +02:00
|
|
|
// looking for, then.
|
|
|
|
if (*req_idx != *i)
|
2011-07-13 12:26:04 +02:00
|
|
|
return FindInsertedValue(I->getAggregateOperand(), idx_range,
|
2009-11-23 04:29:18 +01:00
|
|
|
InsertBefore);
|
2008-06-16 14:48:21 +02: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 12:26:04 +02:00
|
|
|
return FindInsertedValue(I->getInsertedValueOperand(),
|
2011-07-18 14:00:32 +02:00
|
|
|
makeArrayRef(req_idx, idx_range.end()),
|
2009-11-23 04:29:18 +01:00
|
|
|
InsertBefore);
|
2012-01-24 08:54:10 +01:00
|
|
|
}
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2012-01-24 08:54:10 +01:00
|
|
|
if (ExtractValueInst *I = dyn_cast<ExtractValueInst>(V)) {
|
2015-08-08 20:27:36 +02:00
|
|
|
// If we're extracting a value from an aggregate that was extracted from
|
2008-06-16 14:48:21 +02:00
|
|
|
// 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-22 20:15:35 +01:00
|
|
|
|
|
|
|
// Calculate the number of indices required
|
2011-07-13 12:26:04 +02:00
|
|
|
unsigned size = I->getNumIndices() + idx_range.size();
|
2008-06-16 14:48:21 +02:00
|
|
|
// Allocate some space to put the new indices in
|
2008-06-17 10:24:37 +02:00
|
|
|
SmallVector<unsigned, 5> Idxs;
|
|
|
|
Idxs.reserve(size);
|
2008-06-16 14:48:21 +02:00
|
|
|
// Add indices from the extract value instruction
|
2011-07-13 12:26:04 +02:00
|
|
|
Idxs.append(I->idx_begin(), I->idx_end());
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2008-06-16 14:48:21 +02:00
|
|
|
// Add requested indices
|
2011-07-13 12:26:04 +02:00
|
|
|
Idxs.append(idx_range.begin(), idx_range.end());
|
2008-06-16 14:48:21 +02:00
|
|
|
|
2012-12-22 20:15:35 +01:00
|
|
|
assert(Idxs.size() == size
|
2008-06-16 14:57:37 +02:00
|
|
|
&& "Number of indices added not correct?");
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2011-07-13 12:26:04 +02:00
|
|
|
return FindInsertedValue(I->getAggregateOperand(), Idxs, InsertBefore);
|
2008-06-16 14:48:21 +02:00
|
|
|
}
|
|
|
|
// Otherwise, we don't know (such as, extracting from a function return value
|
|
|
|
// or load instruction)
|
2014-04-15 06:59:12 +02:00
|
|
|
return nullptr;
|
2008-06-16 14:48:21 +02:00
|
|
|
}
|
2008-06-30 09:31:25 +02:00
|
|
|
|
2014-11-04 17:27:42 +01: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-11-30 23:25:26 +01:00
|
|
|
Value *llvm::GetPointerBaseWithConstantOffset(Value *Ptr, int64_t &Offset,
|
2015-03-10 03:37:25 +01:00
|
|
|
const DataLayout &DL) {
|
2018-02-14 07:58:08 +01:00
|
|
|
unsigned BitWidth = DL.getIndexTypeSizeInBits(Ptr->getType());
|
2012-12-31 21:48:35 +01:00
|
|
|
APInt ByteOffset(BitWidth, 0);
|
2016-01-04 08:23:12 +01:00
|
|
|
|
|
|
|
// We walk up the defs but use a visited set to handle unreachable code. In
|
|
|
|
// that case, we stop after accumulating the cycle once (not that it
|
|
|
|
// matters).
|
|
|
|
SmallPtrSet<Value *, 16> Visited;
|
|
|
|
while (Visited.insert(Ptr).second) {
|
2012-12-31 21:48:35 +01:00
|
|
|
if (Ptr->getType()->isVectorTy())
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (GEPOperator *GEP = dyn_cast<GEPOperator>(Ptr)) {
|
2016-10-07 16:23:29 +02:00
|
|
|
// If one of the values we have visited is an addrspacecast, then
|
|
|
|
// the pointer type of this GEP may be different from the type
|
|
|
|
// of the Ptr parameter which was passed to this function. This
|
|
|
|
// means when we construct GEPOffset, we need to use the size
|
|
|
|
// of GEP's pointer type rather than the size of the original
|
|
|
|
// pointer type.
|
2018-02-14 07:58:08 +01:00
|
|
|
APInt GEPOffset(DL.getIndexTypeSizeInBits(Ptr->getType()), 0);
|
2015-03-10 03:37:25 +01:00
|
|
|
if (!GEP->accumulateConstantOffset(DL, GEPOffset))
|
|
|
|
break;
|
2013-08-10 19:34:08 +02:00
|
|
|
|
2019-01-04 15:53:22 +01:00
|
|
|
APInt OrigByteOffset(ByteOffset);
|
|
|
|
ByteOffset += GEPOffset.sextOrTrunc(ByteOffset.getBitWidth());
|
|
|
|
if (ByteOffset.getMinSignedBits() > 64) {
|
|
|
|
// Stop traversal if the pointer offset wouldn't fit into int64_t
|
|
|
|
// (this should be removed if Offset is updated to an APInt)
|
|
|
|
ByteOffset = OrigByteOffset;
|
|
|
|
break;
|
|
|
|
}
|
2013-08-10 19:34:08 +02:00
|
|
|
|
2012-12-31 21:48:35 +01:00
|
|
|
Ptr = GEP->getPointerOperand();
|
2016-10-07 16:23:29 +02:00
|
|
|
} else if (Operator::getOpcode(Ptr) == Instruction::BitCast ||
|
|
|
|
Operator::getOpcode(Ptr) == Instruction::AddrSpaceCast) {
|
2012-12-31 21:48:35 +01:00
|
|
|
Ptr = cast<Operator>(Ptr)->getOperand(0);
|
|
|
|
} else if (GlobalAlias *GA = dyn_cast<GlobalAlias>(Ptr)) {
|
Don't IPO over functions that can be de-refined
Summary:
Fixes PR26774.
If you're aware of the issue, feel free to skip the "Motivation"
section and jump directly to "This patch".
Motivation:
I define "refinement" as discarding behaviors from a program that the
optimizer has license to discard. So transforming:
```
void f(unsigned x) {
unsigned t = 5 / x;
(void)t;
}
```
to
```
void f(unsigned x) { }
```
is refinement, since the behavior went from "if x == 0 then undefined
else nothing" to "nothing" (the optimizer has license to discard
undefined behavior).
Refinement is a fundamental aspect of many mid-level optimizations done
by LLVM. For instance, transforming `x == (x + 1)` to `false` also
involves refinement since the expression's value went from "if x is
`undef` then { `true` or `false` } else { `false` }" to "`false`" (by
definition, the optimizer has license to fold `undef` to any non-`undef`
value).
Unfortunately, refinement implies that the optimizer cannot assume
that the implementation of a function it can see has all of the
behavior an unoptimized or a differently optimized version of the same
function can have. This is a problem for functions with comdat
linkage, where a function can be replaced by an unoptimized or a
differently optimized version of the same source level function.
For instance, FunctionAttrs cannot assume a comdat function is
actually `readnone` even if it does not have any loads or stores in
it; since there may have been loads and stores in the "original
function" that were refined out in the currently visible variant, and
at the link step the linker may in fact choose an implementation with
a load or a store. As an example, consider a function that does two
atomic loads from the same memory location, and writes to memory only
if the two values are not equal. The optimizer is allowed to refine
this function by first CSE'ing the two loads, and the folding the
comparision to always report that the two values are equal. Such a
refined variant will look like it is `readonly`. However, the
unoptimized version of the function can still write to memory (since
the two loads //can// result in different values), and selecting the
unoptimized version at link time will retroactively invalidate
transforms we may have done under the assumption that the function
does not write to memory.
Note: this is not just a problem with atomics or with linking
differently optimized object files. See PR26774 for more realistic
examples that involved neither.
This patch:
This change introduces a new set of linkage types, predicated as
`GlobalValue::mayBeDerefined` that returns true if the linkage type
allows a function to be replaced by a differently optimized variant at
link time. It then changes a set of IPO passes to bail out if they see
such a function.
Reviewers: chandlerc, hfinkel, dexonsmith, joker.eph, rnk
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D18634
llvm-svn: 265762
2016-04-08 02:48:30 +02:00
|
|
|
if (GA->isInterposable())
|
2012-12-31 21:48:35 +01:00
|
|
|
break;
|
|
|
|
Ptr = GA->getAliasee();
|
2010-11-30 23:25:26 +01:00
|
|
|
} else {
|
2012-12-31 21:48:35 +01:00
|
|
|
break;
|
2010-11-30 23:25:26 +01:00
|
|
|
}
|
|
|
|
}
|
2012-12-31 21:48:35 +01:00
|
|
|
Offset = ByteOffset.getSExtValue();
|
|
|
|
return Ptr;
|
2010-11-30 23:25:26 +01:00
|
|
|
}
|
|
|
|
|
2017-05-20 00:37:09 +02:00
|
|
|
bool llvm::isGEPBasedOnPointerToString(const GEPOperator *GEP,
|
|
|
|
unsigned CharSize) {
|
2016-04-13 16:31:06 +02:00
|
|
|
// Make sure the GEP has exactly three arguments.
|
|
|
|
if (GEP->getNumOperands() != 3)
|
|
|
|
return false;
|
|
|
|
|
2017-05-20 00:37:09 +02:00
|
|
|
// Make sure the index-ee is a pointer to array of \p CharSize integers.
|
|
|
|
// CharSize.
|
2016-04-13 16:31:06 +02:00
|
|
|
ArrayType *AT = dyn_cast<ArrayType>(GEP->getSourceElementType());
|
2017-05-20 00:37:09 +02:00
|
|
|
if (!AT || !AT->getElementType()->isIntegerTy(CharSize))
|
2016-04-13 16:31:06 +02:00
|
|
|
return false;
|
|
|
|
|
|
|
|
// 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.
|
|
|
|
const ConstantInt *FirstIdx = dyn_cast<ConstantInt>(GEP->getOperand(1));
|
|
|
|
if (!FirstIdx || !FirstIdx->isZero())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
2016-05-07 04:08:15 +02:00
|
|
|
}
|
2010-11-30 23:25:26 +01:00
|
|
|
|
2017-05-20 00:37:09 +02:00
|
|
|
bool llvm::getConstantDataArrayInfo(const Value *V,
|
|
|
|
ConstantDataArraySlice &Slice,
|
|
|
|
unsigned ElementSize, uint64_t Offset) {
|
2012-02-05 03:29:43 +01:00
|
|
|
assert(V);
|
|
|
|
|
|
|
|
// Look through bitcast instructions and geps.
|
|
|
|
V = V->stripPointerCasts();
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2015-03-21 16:36:06 +01:00
|
|
|
// If the value is a GEP instruction or constant expression, treat it as an
|
2012-02-05 03:29:43 +01:00
|
|
|
// offset.
|
|
|
|
if (const GEPOperator *GEP = dyn_cast<GEPOperator>(V)) {
|
2016-04-13 16:31:06 +02:00
|
|
|
// The GEP operator should be based on a pointer to string constant, and is
|
|
|
|
// indexing into the string constant.
|
2017-05-20 00:37:09 +02:00
|
|
|
if (!isGEPBasedOnPointerToString(GEP, ElementSize))
|
2009-03-13 05:39:26 +01:00
|
|
|
return false;
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2008-06-30 09:31:25 +02: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 00:20:45 +02:00
|
|
|
if (const ConstantInt *CI = dyn_cast<ConstantInt>(GEP->getOperand(2)))
|
2008-06-30 09:31:25 +02:00
|
|
|
StartIdx = CI->getZExtValue();
|
2009-03-13 05:39:26 +01:00
|
|
|
else
|
|
|
|
return false;
|
2017-05-20 00:37:09 +02:00
|
|
|
return getConstantDataArrayInfo(GEP->getOperand(0), Slice, ElementSize,
|
|
|
|
StartIdx + Offset);
|
2008-06-30 09:31:25 +02:00
|
|
|
}
|
2011-10-20 02:34:35 +02:00
|
|
|
|
2008-06-30 09:31:25 +02: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 03:29:43 +01:00
|
|
|
const GlobalVariable *GV = dyn_cast<GlobalVariable>(V);
|
2009-08-19 20:20:44 +02:00
|
|
|
if (!GV || !GV->isConstant() || !GV->hasDefinitiveInitializer())
|
2009-03-13 05:39:26 +01:00
|
|
|
return false;
|
2012-02-05 03:29:43 +01:00
|
|
|
|
2017-05-20 00:37:09 +02:00
|
|
|
const ConstantDataArray *Array;
|
|
|
|
ArrayType *ArrayTy;
|
2012-02-05 03:29:43 +01:00
|
|
|
if (GV->getInitializer()->isNullValue()) {
|
2017-05-20 00:37:09 +02:00
|
|
|
Type *GVTy = GV->getValueType();
|
|
|
|
if ( (ArrayTy = dyn_cast<ArrayType>(GVTy)) ) {
|
2017-06-13 00:34:37 +02:00
|
|
|
// A zeroinitializer for the array; there is no ConstantDataArray.
|
2017-05-20 00:37:09 +02:00
|
|
|
Array = nullptr;
|
|
|
|
} else {
|
|
|
|
const DataLayout &DL = GV->getParent()->getDataLayout();
|
|
|
|
uint64_t SizeInBytes = DL.getTypeStoreSize(GVTy);
|
|
|
|
uint64_t Length = SizeInBytes / (ElementSize / 8);
|
|
|
|
if (Length <= Offset)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
Slice.Array = nullptr;
|
|
|
|
Slice.Offset = 0;
|
|
|
|
Slice.Length = Length - Offset;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// This must be a ConstantDataArray.
|
|
|
|
Array = dyn_cast<ConstantDataArray>(GV->getInitializer());
|
|
|
|
if (!Array)
|
|
|
|
return false;
|
|
|
|
ArrayTy = Array->getType();
|
2009-03-13 05:39:26 +01:00
|
|
|
}
|
2017-05-20 00:37:09 +02:00
|
|
|
if (!ArrayTy->getElementType()->isIntegerTy(ElementSize))
|
|
|
|
return false;
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2017-05-20 00:37:09 +02:00
|
|
|
uint64_t NumElts = ArrayTy->getArrayNumElements();
|
|
|
|
if (Offset > NumElts)
|
2009-03-13 05:39:26 +01:00
|
|
|
return false;
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2017-05-20 00:37:09 +02:00
|
|
|
Slice.Array = Array;
|
|
|
|
Slice.Offset = Offset;
|
|
|
|
Slice.Length = NumElts - Offset;
|
|
|
|
return true;
|
|
|
|
}
|
2012-02-05 03:29:43 +01:00
|
|
|
|
2017-05-20 00:37:09 +02: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.
|
|
|
|
bool llvm::getConstantStringInfo(const Value *V, StringRef &Str,
|
|
|
|
uint64_t Offset, bool TrimAtNul) {
|
|
|
|
ConstantDataArraySlice Slice;
|
|
|
|
if (!getConstantDataArrayInfo(V, Slice, 8, Offset))
|
|
|
|
return false;
|
2012-02-05 03:29:43 +01:00
|
|
|
|
2017-05-20 00:37:09 +02:00
|
|
|
if (Slice.Array == nullptr) {
|
|
|
|
if (TrimAtNul) {
|
|
|
|
Str = StringRef();
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
if (Slice.Length == 1) {
|
|
|
|
Str = StringRef("", 1);
|
|
|
|
return true;
|
|
|
|
}
|
2017-06-09 16:21:18 +02:00
|
|
|
// We cannot instantiate a StringRef as we do not have an appropriate string
|
2017-05-20 00:37:09 +02:00
|
|
|
// of 0s at hand.
|
2009-03-13 05:39:26 +01:00
|
|
|
return false;
|
2017-05-20 00:37:09 +02:00
|
|
|
}
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2017-05-20 00:37:09 +02:00
|
|
|
// Start out with the entire array in the StringRef.
|
|
|
|
Str = Slice.Array->getAsString();
|
2012-02-05 03:29:43 +01:00
|
|
|
// Skip over 'offset' bytes.
|
2017-05-20 00:37:09 +02:00
|
|
|
Str = Str.substr(Slice.Offset);
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2012-02-05 03:29:43 +01: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 05:39:26 +01:00
|
|
|
return true;
|
2008-06-30 09:31:25 +02:00
|
|
|
}
|
2010-03-05 07:58:57 +01: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-04 17:27:42 +01:00
|
|
|
/// If we can compute the length of the string pointed to by
|
2010-03-05 07:58:57 +01:00
|
|
|
/// the specified pointer, return 'len+1'. If we can't, return 0.
|
2016-08-13 03:05:32 +02:00
|
|
|
static uint64_t GetStringLengthH(const Value *V,
|
2017-05-20 00:37:09 +02:00
|
|
|
SmallPtrSetImpl<const PHINode*> &PHIs,
|
|
|
|
unsigned CharSize) {
|
2010-03-05 07:58:57 +01:00
|
|
|
// Look through noop bitcast instructions.
|
2012-02-05 03:29:43 +01:00
|
|
|
V = V->stripPointerCasts();
|
2010-03-05 07:58:57 +01:00
|
|
|
|
|
|
|
// If this is a PHI node, there are two cases: either we have already seen it
|
|
|
|
// or we haven't.
|
2016-08-13 03:05:32 +02:00
|
|
|
if (const PHINode *PN = dyn_cast<PHINode>(V)) {
|
2014-11-19 08:49:26 +01:00
|
|
|
if (!PHIs.insert(PN).second)
|
2010-03-05 07:58:57 +01: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;
|
2015-05-12 22:05:31 +02:00
|
|
|
for (Value *IncValue : PN->incoming_values()) {
|
2017-05-20 00:37:09 +02:00
|
|
|
uint64_t Len = GetStringLengthH(IncValue, PHIs, CharSize);
|
2010-03-05 07:58:57 +01:00
|
|
|
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)
|
2016-08-13 03:05:32 +02:00
|
|
|
if (const SelectInst *SI = dyn_cast<SelectInst>(V)) {
|
2017-05-20 00:37:09 +02:00
|
|
|
uint64_t Len1 = GetStringLengthH(SI->getTrueValue(), PHIs, CharSize);
|
2010-03-05 07:58:57 +01:00
|
|
|
if (Len1 == 0) return 0;
|
2017-05-20 00:37:09 +02:00
|
|
|
uint64_t Len2 = GetStringLengthH(SI->getFalseValue(), PHIs, CharSize);
|
2010-03-05 07:58:57 +01:00
|
|
|
if (Len2 == 0) return 0;
|
|
|
|
if (Len1 == ~0ULL) return Len2;
|
|
|
|
if (Len2 == ~0ULL) return Len1;
|
|
|
|
if (Len1 != Len2) return 0;
|
|
|
|
return Len1;
|
|
|
|
}
|
2012-12-22 20:15:35 +01:00
|
|
|
|
2012-02-05 03:29:43 +01:00
|
|
|
// Otherwise, see if we can read the string.
|
2017-05-20 00:37:09 +02:00
|
|
|
ConstantDataArraySlice Slice;
|
|
|
|
if (!getConstantDataArrayInfo(V, Slice, CharSize))
|
2012-02-01 05:51:17 +01:00
|
|
|
return 0;
|
2010-03-05 07:58:57 +01:00
|
|
|
|
2017-05-20 00:37:09 +02:00
|
|
|
if (Slice.Array == nullptr)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
// Search for nul characters
|
|
|
|
unsigned NullIndex = 0;
|
|
|
|
for (unsigned E = Slice.Length; NullIndex < E; ++NullIndex) {
|
|
|
|
if (Slice.Array->getElementAsInteger(Slice.Offset + NullIndex) == 0)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NullIndex + 1;
|
2010-03-05 07:58:57 +01:00
|
|
|
}
|
|
|
|
|
2014-11-04 17:27:42 +01:00
|
|
|
/// If we can compute the length of the string pointed to by
|
2010-03-05 07:58:57 +01:00
|
|
|
/// the specified pointer, return 'len+1'. If we can't, return 0.
|
2018-05-22 22:27:36 +02:00
|
|
|
uint64_t llvm::GetStringLength(const Value *V, unsigned CharSize) {
|
2018-05-22 17:41:23 +02:00
|
|
|
if (!V->getType()->isPointerTy())
|
|
|
|
return 0;
|
2010-03-05 07:58:57 +01:00
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
SmallPtrSet<const PHINode*, 32> PHIs;
|
2017-05-20 00:37:09 +02:00
|
|
|
uint64_t Len = GetStringLengthH(V, PHIs, CharSize);
|
2010-03-05 07:58:57 +01:00
|
|
|
// 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-15 21:02:24 +01:00
|
|
|
|
2019-01-07 06:42:51 +01:00
|
|
|
const Value *llvm::getArgumentAliasingToReturnedPointer(const CallBase *Call) {
|
|
|
|
assert(Call &&
|
|
|
|
"getArgumentAliasingToReturnedPointer only works on nonnull calls");
|
|
|
|
if (const Value *RV = Call->getReturnedArgOperand())
|
2018-05-23 11:16:44 +02:00
|
|
|
return RV;
|
|
|
|
// This can be used only as a aliasing property.
|
2019-01-07 06:42:51 +01:00
|
|
|
if (isIntrinsicReturningPointerAliasingArgumentWithoutCapturing(Call))
|
|
|
|
return Call->getArgOperand(0);
|
2018-05-23 11:16:44 +02:00
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool llvm::isIntrinsicReturningPointerAliasingArgumentWithoutCapturing(
|
2019-01-07 06:42:51 +01:00
|
|
|
const CallBase *Call) {
|
|
|
|
return Call->getIntrinsicID() == Intrinsic::launder_invariant_group ||
|
|
|
|
Call->getIntrinsicID() == Intrinsic::strip_invariant_group;
|
2018-05-23 11:16:44 +02:00
|
|
|
}
|
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// \p PN defines a loop-variant pointer to an object. Check if the
|
2015-04-23 22:09:20 +02:00
|
|
|
/// previous iteration of the loop was referring to the same object as \p PN.
|
2016-08-13 03:05:32 +02:00
|
|
|
static bool isSameUnderlyingObjectInLoop(const PHINode *PN,
|
|
|
|
const LoopInfo *LI) {
|
2015-04-23 22:09:20 +02:00
|
|
|
// Find the loop-defined value.
|
|
|
|
Loop *L = LI->getLoopFor(PN->getParent());
|
|
|
|
if (PN->getNumIncomingValues() != 2)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// Find the value from previous iteration.
|
|
|
|
auto *PrevValue = dyn_cast<Instruction>(PN->getIncomingValue(0));
|
|
|
|
if (!PrevValue || LI->getLoopFor(PrevValue->getParent()) != L)
|
|
|
|
PrevValue = dyn_cast<Instruction>(PN->getIncomingValue(1));
|
|
|
|
if (!PrevValue || LI->getLoopFor(PrevValue->getParent()) != L)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// If a new pointer is loaded in the loop, the pointer references a different
|
|
|
|
// object in every iteration. E.g.:
|
|
|
|
// for (i)
|
|
|
|
// int *p = a[i];
|
|
|
|
// ...
|
|
|
|
if (auto *Load = dyn_cast<LoadInst>(PrevValue))
|
|
|
|
if (!L->isLoopInvariant(Load->getPointerOperand()))
|
|
|
|
return false;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-03-10 03:37:25 +01:00
|
|
|
Value *llvm::GetUnderlyingObject(Value *V, const DataLayout &DL,
|
|
|
|
unsigned MaxLookup) {
|
2010-12-15 21:02:24 +01: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 02:56:40 +02:00
|
|
|
} else if (Operator::getOpcode(V) == Instruction::BitCast ||
|
|
|
|
Operator::getOpcode(V) == Instruction::AddrSpaceCast) {
|
2010-12-15 21:02:24 +01:00
|
|
|
V = cast<Operator>(V)->getOperand(0);
|
|
|
|
} else if (GlobalAlias *GA = dyn_cast<GlobalAlias>(V)) {
|
Don't IPO over functions that can be de-refined
Summary:
Fixes PR26774.
If you're aware of the issue, feel free to skip the "Motivation"
section and jump directly to "This patch".
Motivation:
I define "refinement" as discarding behaviors from a program that the
optimizer has license to discard. So transforming:
```
void f(unsigned x) {
unsigned t = 5 / x;
(void)t;
}
```
to
```
void f(unsigned x) { }
```
is refinement, since the behavior went from "if x == 0 then undefined
else nothing" to "nothing" (the optimizer has license to discard
undefined behavior).
Refinement is a fundamental aspect of many mid-level optimizations done
by LLVM. For instance, transforming `x == (x + 1)` to `false` also
involves refinement since the expression's value went from "if x is
`undef` then { `true` or `false` } else { `false` }" to "`false`" (by
definition, the optimizer has license to fold `undef` to any non-`undef`
value).
Unfortunately, refinement implies that the optimizer cannot assume
that the implementation of a function it can see has all of the
behavior an unoptimized or a differently optimized version of the same
function can have. This is a problem for functions with comdat
linkage, where a function can be replaced by an unoptimized or a
differently optimized version of the same source level function.
For instance, FunctionAttrs cannot assume a comdat function is
actually `readnone` even if it does not have any loads or stores in
it; since there may have been loads and stores in the "original
function" that were refined out in the currently visible variant, and
at the link step the linker may in fact choose an implementation with
a load or a store. As an example, consider a function that does two
atomic loads from the same memory location, and writes to memory only
if the two values are not equal. The optimizer is allowed to refine
this function by first CSE'ing the two loads, and the folding the
comparision to always report that the two values are equal. Such a
refined variant will look like it is `readonly`. However, the
unoptimized version of the function can still write to memory (since
the two loads //can// result in different values), and selecting the
unoptimized version at link time will retroactively invalidate
transforms we may have done under the assumption that the function
does not write to memory.
Note: this is not just a problem with atomics or with linking
differently optimized object files. See PR26774 for more realistic
examples that involved neither.
This patch:
This change introduces a new set of linkage types, predicated as
`GlobalValue::mayBeDerefined` that returns true if the linkage type
allows a function to be replaced by a differently optimized variant at
link time. It then changes a set of IPO passes to bail out if they see
such a function.
Reviewers: chandlerc, hfinkel, dexonsmith, joker.eph, rnk
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D18634
llvm-svn: 265762
2016-04-08 02:48:30 +02:00
|
|
|
if (GA->isInterposable())
|
2010-12-15 21:02:24 +01:00
|
|
|
return V;
|
|
|
|
V = GA->getAliasee();
|
2017-04-13 00:29:23 +02:00
|
|
|
} else if (isa<AllocaInst>(V)) {
|
|
|
|
// An alloca can't be further simplified.
|
|
|
|
return V;
|
2010-12-15 21:02:24 +01:00
|
|
|
} else {
|
2019-01-07 06:42:51 +01:00
|
|
|
if (auto *Call = dyn_cast<CallBase>(V)) {
|
Implement strip.invariant.group
Summary:
This patch introduce new intrinsic -
strip.invariant.group that was described in the
RFC: Devirtualization v2
Reviewers: rsmith, hfinkel, nlopes, sanjoy, amharc, kuhar
Subscribers: arsenm, nhaehnle, JDevlieghere, hiraditya, xbolva00, llvm-commits
Differential Revision: https://reviews.llvm.org/D47103
Co-authored-by: Krzysztof Pszeniczny <krzysztof.pszeniczny@gmail.com>
llvm-svn: 336073
2018-07-02 06:49:30 +02:00
|
|
|
// CaptureTracking can know about special capturing properties of some
|
|
|
|
// intrinsics like launder.invariant.group, that can't be expressed with
|
|
|
|
// the attributes, but have properties like returning aliasing pointer.
|
|
|
|
// Because some analysis may assume that nocaptured pointer is not
|
|
|
|
// returned from some special intrinsic (because function would have to
|
|
|
|
// be marked with returns attribute), it is crucial to use this function
|
|
|
|
// because it should be in sync with CaptureTracking. Not using it may
|
|
|
|
// cause weird miscompilations where 2 aliasing pointers are assumed to
|
|
|
|
// noalias.
|
2019-01-07 06:42:51 +01:00
|
|
|
if (auto *RP = getArgumentAliasingToReturnedPointer(Call)) {
|
2018-05-23 11:16:44 +02:00
|
|
|
V = RP;
|
2016-07-11 03:32:20 +02:00
|
|
|
continue;
|
|
|
|
}
|
2018-05-23 11:16:44 +02:00
|
|
|
}
|
2016-07-11 03:32:20 +02:00
|
|
|
|
2010-12-15 21:49:55 +01:00
|
|
|
// See if InstructionSimplify knows any relevant tricks.
|
|
|
|
if (Instruction *I = dyn_cast<Instruction>(V))
|
2016-12-19 09:22:17 +01:00
|
|
|
// TODO: Acquire a DominatorTree and AssumptionCache and use them.
|
2017-04-28 21:55:38 +02:00
|
|
|
if (Value *Simplified = SimplifyInstruction(I, {DL, I})) {
|
2010-12-15 21:49:55 +01:00
|
|
|
V = Simplified;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2010-12-15 21:02:24 +01:00
|
|
|
return V;
|
|
|
|
}
|
|
|
|
assert(V->getType()->isPointerTy() && "Unexpected operand type!");
|
|
|
|
}
|
|
|
|
return V;
|
|
|
|
}
|
2011-06-27 06:20:45 +02:00
|
|
|
|
2015-03-10 03:37:25 +01:00
|
|
|
void llvm::GetUnderlyingObjects(Value *V, SmallVectorImpl<Value *> &Objects,
|
2015-04-23 22:09:20 +02:00
|
|
|
const DataLayout &DL, LoopInfo *LI,
|
|
|
|
unsigned MaxLookup) {
|
2012-05-10 20:57:38 +02:00
|
|
|
SmallPtrSet<Value *, 4> Visited;
|
|
|
|
SmallVector<Value *, 4> Worklist;
|
|
|
|
Worklist.push_back(V);
|
|
|
|
do {
|
|
|
|
Value *P = Worklist.pop_back_val();
|
2015-03-10 03:37:25 +01:00
|
|
|
P = GetUnderlyingObject(P, DL, MaxLookup);
|
2012-05-10 20:57:38 +02:00
|
|
|
|
2014-11-19 08:49:26 +01:00
|
|
|
if (!Visited.insert(P).second)
|
2012-05-10 20:57:38 +02: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)) {
|
2015-04-23 22:09:20 +02:00
|
|
|
// If this PHI changes the underlying object in every iteration of the
|
|
|
|
// loop, don't look through it. Consider:
|
|
|
|
// int **A;
|
|
|
|
// for (i) {
|
|
|
|
// Prev = Curr; // Prev = PHI (Prev_0, Curr)
|
|
|
|
// Curr = A[i];
|
|
|
|
// *Prev, *Curr;
|
|
|
|
//
|
|
|
|
// Prev is tracking Curr one iteration behind so they refer to different
|
|
|
|
// underlying objects.
|
|
|
|
if (!LI || !LI->isLoopHeader(PN->getParent()) ||
|
|
|
|
isSameUnderlyingObjectInLoop(PN, LI))
|
2015-05-12 22:05:31 +02:00
|
|
|
for (Value *IncValue : PN->incoming_values())
|
|
|
|
Worklist.push_back(IncValue);
|
2012-05-10 20:57:38 +02:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
Objects.push_back(P);
|
|
|
|
} while (!Worklist.empty());
|
|
|
|
}
|
|
|
|
|
2017-08-01 05:32:15 +02:00
|
|
|
/// This is the function that does the work of looking through basic
|
|
|
|
/// ptrtoint+arithmetic+inttoptr sequences.
|
|
|
|
static const Value *getUnderlyingObjectFromInt(const Value *V) {
|
|
|
|
do {
|
|
|
|
if (const Operator *U = dyn_cast<Operator>(V)) {
|
|
|
|
// If we find a ptrtoint, we can transfer control back to the
|
|
|
|
// regular getUnderlyingObjectFromInt.
|
|
|
|
if (U->getOpcode() == Instruction::PtrToInt)
|
|
|
|
return U->getOperand(0);
|
|
|
|
// If we find an add of a constant, a multiplied value, or a phi, it's
|
|
|
|
// likely that the other operand will lead us to the base
|
|
|
|
// object. We don't have to worry about the case where the
|
|
|
|
// object address is somehow being computed by the multiply,
|
|
|
|
// because our callers only care when the result is an
|
|
|
|
// identifiable object.
|
|
|
|
if (U->getOpcode() != Instruction::Add ||
|
|
|
|
(!isa<ConstantInt>(U->getOperand(1)) &&
|
|
|
|
Operator::getOpcode(U->getOperand(1)) != Instruction::Mul &&
|
|
|
|
!isa<PHINode>(U->getOperand(1))))
|
|
|
|
return V;
|
|
|
|
V = U->getOperand(0);
|
|
|
|
} else {
|
|
|
|
return V;
|
|
|
|
}
|
|
|
|
assert(V->getType()->isIntegerTy() && "Unexpected operand type!");
|
|
|
|
} while (true);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// This is a wrapper around GetUnderlyingObjects and adds support for basic
|
|
|
|
/// ptrtoint+arithmetic+inttoptr sequences.
|
2017-10-12 08:26:04 +02:00
|
|
|
/// It returns false if unidentified object is found in GetUnderlyingObjects.
|
|
|
|
bool llvm::getUnderlyingObjectsForCodeGen(const Value *V,
|
2017-08-01 05:32:15 +02:00
|
|
|
SmallVectorImpl<Value *> &Objects,
|
|
|
|
const DataLayout &DL) {
|
|
|
|
SmallPtrSet<const Value *, 16> Visited;
|
|
|
|
SmallVector<const Value *, 4> Working(1, V);
|
|
|
|
do {
|
|
|
|
V = Working.pop_back_val();
|
|
|
|
|
|
|
|
SmallVector<Value *, 4> Objs;
|
|
|
|
GetUnderlyingObjects(const_cast<Value *>(V), Objs, DL);
|
|
|
|
|
|
|
|
for (Value *V : Objs) {
|
|
|
|
if (!Visited.insert(V).second)
|
|
|
|
continue;
|
|
|
|
if (Operator::getOpcode(V) == Instruction::IntToPtr) {
|
|
|
|
const Value *O =
|
|
|
|
getUnderlyingObjectFromInt(cast<User>(V)->getOperand(0));
|
|
|
|
if (O->getType()->isPointerTy()) {
|
|
|
|
Working.push_back(O);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
2017-08-02 20:16:32 +02:00
|
|
|
// If GetUnderlyingObjects fails to find an identifiable object,
|
|
|
|
// getUnderlyingObjectsForCodeGen also fails for safety.
|
|
|
|
if (!isIdentifiedObject(V)) {
|
|
|
|
Objects.clear();
|
2017-10-12 08:26:04 +02:00
|
|
|
return false;
|
2017-08-02 20:16:32 +02:00
|
|
|
}
|
2017-08-01 05:32:15 +02:00
|
|
|
Objects.push_back(const_cast<Value *>(V));
|
|
|
|
}
|
|
|
|
} while (!Working.empty());
|
2017-10-12 08:26:04 +02:00
|
|
|
return true;
|
2017-08-01 05:32:15 +02:00
|
|
|
}
|
|
|
|
|
2014-11-04 17:27:42 +01:00
|
|
|
/// Return true if the only users of this pointer are lifetime markers.
|
2011-06-27 06:20:45 +02:00
|
|
|
bool llvm::onlyUsedByLifetimeMarkers(const Value *V) {
|
2014-03-09 04:16:01 +01:00
|
|
|
for (const User *U : V->users()) {
|
|
|
|
const IntrinsicInst *II = dyn_cast<IntrinsicInst>(U);
|
2011-06-27 06:20:45 +02:00
|
|
|
if (!II) return false;
|
|
|
|
|
2018-12-21 22:49:40 +01:00
|
|
|
if (!II->isLifetimeStartOrEnd())
|
2011-06-27 06:20:45 +02:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
2011-12-15 00:49:11 +01:00
|
|
|
|
2015-05-18 20:07:00 +02:00
|
|
|
bool llvm::isSafeToSpeculativelyExecute(const Value *V,
|
|
|
|
const Instruction *CtxI,
|
2016-07-03 01:47:27 +02:00
|
|
|
const DominatorTree *DT) {
|
2012-01-05 00:01:09 +01:00
|
|
|
const Operator *Inst = dyn_cast<Operator>(V);
|
|
|
|
if (!Inst)
|
|
|
|
return false;
|
|
|
|
|
2011-12-15 00:49:11 +01: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 00:49:08 +01: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 00:49:11 +01:00
|
|
|
case Instruction::SDiv:
|
|
|
|
case Instruction::SRem: {
|
2014-11-05 00:49:08 +01:00
|
|
|
// x / y is undefined if y == 0 or x == INT_MIN and y == -1
|
2015-02-01 20:10:19 +01: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 00:49:08 +01:00
|
|
|
return false;
|
2011-12-15 00:49:11 +01:00
|
|
|
}
|
|
|
|
case Instruction::Load: {
|
|
|
|
const LoadInst *LI = cast<LoadInst>(Inst);
|
2013-11-21 08:29:28 +01:00
|
|
|
if (!LI->isUnordered() ||
|
|
|
|
// Speculative load may create a race that did not exist in the source.
|
2016-07-14 22:19:01 +02:00
|
|
|
LI->getFunction()->hasFnAttribute(Attribute::SanitizeThread) ||
|
2015-10-14 02:21:05 +02:00
|
|
|
// Speculative load may load data from dirty regions.
|
2017-12-09 01:21:41 +01:00
|
|
|
LI->getFunction()->hasFnAttribute(Attribute::SanitizeAddress) ||
|
|
|
|
LI->getFunction()->hasFnAttribute(Attribute::SanitizeHWAddress))
|
2011-12-15 00:49:11 +01:00
|
|
|
return false;
|
2015-03-10 03:37:25 +01:00
|
|
|
const DataLayout &DL = LI->getModule()->getDataLayout();
|
2016-07-03 01:47:27 +02:00
|
|
|
return isDereferenceableAndAlignedPointer(LI->getPointerOperand(),
|
|
|
|
LI->getAlignment(), DL, CtxI, DT);
|
2011-12-15 00:49:11 +01:00
|
|
|
}
|
2011-12-21 06:52:02 +01:00
|
|
|
case Instruction::Call: {
|
2017-04-28 23:13:09 +02:00
|
|
|
auto *CI = cast<const CallInst>(Inst);
|
|
|
|
const Function *Callee = CI->getCalledFunction();
|
2015-08-28 23:13:39 +02:00
|
|
|
|
2017-05-03 04:26:10 +02:00
|
|
|
// The called function could have undefined behavior or side-effects, even
|
|
|
|
// if marked readnone nounwind.
|
|
|
|
return Callee && Callee->isSpeculatable();
|
2011-12-21 06:52:02 +01:00
|
|
|
}
|
2011-12-15 00:49:11 +01: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::AtomicRMW:
|
|
|
|
case Instruction::AtomicCmpXchg:
|
2015-07-31 19:58:14 +02:00
|
|
|
case Instruction::LandingPad:
|
2011-12-15 00:49:11 +01:00
|
|
|
case Instruction::Resume:
|
[IR] Reformulate LLVM's EH funclet IR
While we have successfully implemented a funclet-oriented EH scheme on
top of LLVM IR, our scheme has some notable deficiencies:
- catchendpad and cleanupendpad are necessary in the current design
but they are difficult to explain to others, even to seasoned LLVM
experts.
- catchendpad and cleanupendpad are optimization barriers. They cannot
be split and force all potentially throwing call-sites to be invokes.
This has a noticable effect on the quality of our code generation.
- catchpad, while similar in some aspects to invoke, is fairly awkward.
It is unsplittable, starts a funclet, and has control flow to other
funclets.
- The nesting relationship between funclets is currently a property of
control flow edges. Because of this, we are forced to carefully
analyze the flow graph to see if there might potentially exist illegal
nesting among funclets. While we have logic to clone funclets when
they are illegally nested, it would be nicer if we had a
representation which forbade them upfront.
Let's clean this up a bit by doing the following:
- Instead, make catchpad more like cleanuppad and landingpad: no control
flow, just a bunch of simple operands; catchpad would be splittable.
- Introduce catchswitch, a control flow instruction designed to model
the constraints of funclet oriented EH.
- Make funclet scoping explicit by having funclet instructions consume
the token produced by the funclet which contains them.
- Remove catchendpad and cleanupendpad. Their presence can be inferred
implicitly using coloring information.
N.B. The state numbering code for the CLR has been updated but the
veracity of it's output cannot be spoken for. An expert should take a
look to make sure the results are reasonable.
Reviewers: rnk, JosephTremoulet, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D15139
llvm-svn: 255422
2015-12-12 06:38:55 +01:00
|
|
|
case Instruction::CatchSwitch:
|
2015-07-31 19:58:14 +02:00
|
|
|
case Instruction::CatchPad:
|
|
|
|
case Instruction::CatchRet:
|
|
|
|
case Instruction::CleanupPad:
|
|
|
|
case Instruction::CleanupRet:
|
2011-12-15 00:49:11 +01:00
|
|
|
return false; // Misc instructions which have effects
|
|
|
|
}
|
|
|
|
}
|
2013-01-31 03:40:59 +01:00
|
|
|
|
2015-08-06 20:44:34 +02:00
|
|
|
bool llvm::mayBeMemoryDependent(const Instruction &I) {
|
|
|
|
return I.mayReadOrWriteMemory() || !isSafeToSpeculativelyExecute(&I);
|
|
|
|
}
|
|
|
|
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
OverflowResult llvm::computeOverflowForUnsignedMul(
|
|
|
|
const Value *LHS, const Value *RHS, const DataLayout &DL,
|
|
|
|
AssumptionCache *AC, const Instruction *CxtI, const DominatorTree *DT,
|
|
|
|
bool UseInstrInfo) {
|
2015-01-02 08:29:43 +01:00
|
|
|
// 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();
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits LHSKnown(BitWidth);
|
|
|
|
KnownBits RHSKnown(BitWidth);
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
computeKnownBits(LHS, LHSKnown, DL, /*Depth=*/0, AC, CxtI, DT, nullptr,
|
|
|
|
UseInstrInfo);
|
|
|
|
computeKnownBits(RHS, RHSKnown, DL, /*Depth=*/0, AC, CxtI, DT, nullptr,
|
|
|
|
UseInstrInfo);
|
2015-01-02 08:29:43 +01:00
|
|
|
// Note that underestimating the number of zero bits gives a more
|
|
|
|
// conservative answer.
|
2017-05-12 19:20:30 +02:00
|
|
|
unsigned ZeroBits = LHSKnown.countMinLeadingZeros() +
|
|
|
|
RHSKnown.countMinLeadingZeros();
|
2015-01-02 08:29:43 +01:00
|
|
|
// 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.
|
2017-04-26 18:39:58 +02:00
|
|
|
APInt LHSMax = ~LHSKnown.Zero;
|
|
|
|
APInt RHSMax = ~RHSKnown.Zero;
|
2015-01-02 08:29:43 +01:00
|
|
|
|
|
|
|
// 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 08:29:47 +01:00
|
|
|
bool MaxOverflow;
|
2017-04-19 23:09:45 +02:00
|
|
|
(void)LHSMax.umul_ov(RHSMax, MaxOverflow);
|
2015-01-02 08:29:47 +01:00
|
|
|
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;
|
2017-04-26 18:39:58 +02:00
|
|
|
(void)LHSKnown.One.umul_ov(RHSKnown.One, MinOverflow);
|
2015-01-02 08:29:47 +01:00
|
|
|
if (MinOverflow)
|
|
|
|
return OverflowResult::AlwaysOverflows;
|
2015-01-02 08:29:43 +01:00
|
|
|
|
2015-01-02 08:29:47 +01:00
|
|
|
return OverflowResult::MayOverflow;
|
2015-01-02 08:29:43 +01:00
|
|
|
}
|
2015-01-07 01:39:50 +01:00
|
|
|
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
OverflowResult
|
|
|
|
llvm::computeOverflowForSignedMul(const Value *LHS, const Value *RHS,
|
|
|
|
const DataLayout &DL, AssumptionCache *AC,
|
|
|
|
const Instruction *CxtI,
|
|
|
|
const DominatorTree *DT, bool UseInstrInfo) {
|
2018-05-10 21:46:19 +02:00
|
|
|
// 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 sign 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();
|
|
|
|
|
|
|
|
// Note that underestimating the number of sign bits gives a more
|
|
|
|
// conservative answer.
|
|
|
|
unsigned SignBits = ComputeNumSignBits(LHS, DL, 0, AC, CxtI, DT) +
|
|
|
|
ComputeNumSignBits(RHS, DL, 0, AC, CxtI, DT);
|
|
|
|
|
|
|
|
// First handle the easy case: if we have enough sign bits there's
|
|
|
|
// definitely no overflow.
|
|
|
|
if (SignBits > BitWidth + 1)
|
|
|
|
return OverflowResult::NeverOverflows;
|
|
|
|
|
|
|
|
// There are two ambiguous cases where there can be no overflow:
|
|
|
|
// SignBits == BitWidth + 1 and
|
|
|
|
// SignBits == BitWidth
|
|
|
|
// The second case is difficult to check, therefore we only handle the
|
|
|
|
// first case.
|
|
|
|
if (SignBits == BitWidth + 1) {
|
|
|
|
// It overflows only when both arguments are negative and the true
|
|
|
|
// product is exactly the minimum negative number.
|
|
|
|
// E.g. mul i16 with 17 sign bits: 0xff00 * 0xff80 = 0x8000
|
|
|
|
// For simplicity we just check if at least one side is not negative.
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
KnownBits LHSKnown = computeKnownBits(LHS, DL, /*Depth=*/0, AC, CxtI, DT,
|
|
|
|
nullptr, UseInstrInfo);
|
|
|
|
KnownBits RHSKnown = computeKnownBits(RHS, DL, /*Depth=*/0, AC, CxtI, DT,
|
|
|
|
nullptr, UseInstrInfo);
|
2018-05-10 21:46:19 +02:00
|
|
|
if (LHSKnown.isNonNegative() || RHSKnown.isNonNegative())
|
|
|
|
return OverflowResult::NeverOverflows;
|
|
|
|
}
|
|
|
|
return OverflowResult::MayOverflow;
|
|
|
|
}
|
|
|
|
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
OverflowResult llvm::computeOverflowForUnsignedAdd(
|
|
|
|
const Value *LHS, const Value *RHS, const DataLayout &DL,
|
|
|
|
AssumptionCache *AC, const Instruction *CxtI, const DominatorTree *DT,
|
|
|
|
bool UseInstrInfo) {
|
|
|
|
KnownBits LHSKnown = computeKnownBits(LHS, DL, /*Depth=*/0, AC, CxtI, DT,
|
|
|
|
nullptr, UseInstrInfo);
|
2017-05-08 18:22:48 +02:00
|
|
|
if (LHSKnown.isNonNegative() || LHSKnown.isNegative()) {
|
[InstrSimplify,NewGVN] Add option to ignore additional instr info when simplifying.
NewGVN uses InstructionSimplify for simplifications of leaders of
congruence classes. It is not guaranteed that the metadata or other
flags/keywords (like nsw or exact) of the leader is available for all members
in a congruence class, so we cannot use it for simplification.
This patch adds a InstrInfoQuery struct with a boolean field
UseInstrInfo (which defaults to true to keep the current behavior as
default) and a set of helper methods to get metadata/keywords for a
given instruction, if UseInstrInfo is true. The whole thing might need a
better name, to avoid confusion with TargetInstrInfo but I am not sure
what a better name would be.
The current patch threads through InstrInfoQuery to the required
places, which is messier then it would need to be, if
InstructionSimplify and ValueTracking would share the same Query struct.
The reason I added it as a separate struct is that it can be shared
between InstructionSimplify and ValueTracking's query objects. Also,
some places do not need a full query object, just the InstrInfoQuery.
It also updates some interfaces that do not take a Query object, but a
set of optional parameters to take an additional boolean UseInstrInfo.
See https://bugs.llvm.org/show_bug.cgi?id=37540.
Reviewers: dberlin, davide, efriedma, sebpop, hiraditya
Reviewed By: hiraditya
Differential Revision: https://reviews.llvm.org/D47143
llvm-svn: 340031
2018-08-17 16:39:04 +02:00
|
|
|
KnownBits RHSKnown = computeKnownBits(RHS, DL, /*Depth=*/0, AC, CxtI, DT,
|
|
|
|
nullptr, UseInstrInfo);
|
2017-05-08 18:22:48 +02:00
|
|
|
|
|
|
|
if (LHSKnown.isNegative() && RHSKnown.isNegative()) {
|
2015-01-07 01:39:50 +01:00
|
|
|
// The sign bit is set in both cases: this MUST overflow.
|
|
|
|
return OverflowResult::AlwaysOverflows;
|
|
|
|
}
|
|
|
|
|
2017-05-08 18:22:48 +02:00
|
|
|
if (LHSKnown.isNonNegative() && RHSKnown.isNonNegative()) {
|
2015-01-07 01:39:50 +01:00
|
|
|
// The sign bit is clear in both cases: this CANNOT overflow.
|
|
|
|
return OverflowResult::NeverOverflows;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return OverflowResult::MayOverflow;
|
|
|
|
}
|
2015-05-11 16:42:20 +02:00
|
|
|
|
2018-05-01 17:54:18 +02:00
|
|
|
/// Return true if we can prove that adding the two values of the
|
2017-05-15 04:44:08 +02:00
|
|
|
/// knownbits will not overflow.
|
|
|
|
/// Otherwise return false.
|
|
|
|
static bool checkRippleForSignedAdd(const KnownBits &LHSKnown,
|
|
|
|
const KnownBits &RHSKnown) {
|
|
|
|
// Addition of two 2's complement numbers having opposite signs will never
|
|
|
|
// overflow.
|
|
|
|
if ((LHSKnown.isNegative() && RHSKnown.isNonNegative()) ||
|
|
|
|
(LHSKnown.isNonNegative() && RHSKnown.isNegative()))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// If either of the values is known to be non-negative, adding them can only
|
|
|
|
// overflow if the second is also non-negative, so we can assume that.
|
2018-07-30 21:41:25 +02:00
|
|
|
// Two non-negative numbers will only overflow if there is a carry to the
|
2017-05-15 04:44:08 +02:00
|
|
|
// sign bit, so we can check if even when the values are as big as possible
|
|
|
|
// there is no overflow to the sign bit.
|
|
|
|
if (LHSKnown.isNonNegative() || RHSKnown.isNonNegative()) {
|
|
|
|
APInt MaxLHS = ~LHSKnown.Zero;
|
|
|
|
MaxLHS.clearSignBit();
|
|
|
|
APInt MaxRHS = ~RHSKnown.Zero;
|
|
|
|
MaxRHS.clearSignBit();
|
|
|
|
APInt Result = std::move(MaxLHS) + std::move(MaxRHS);
|
|
|
|
return Result.isSignBitClear();
|
|
|
|
}
|
|
|
|
|
|
|
|
// If either of the values is known to be negative, adding them can only
|
|
|
|
// overflow if the second is also negative, so we can assume that.
|
|
|
|
// Two negative number will only overflow if there is no carry to the sign
|
|
|
|
// bit, so we can check if even when the values are as small as possible
|
|
|
|
// there is overflow to the sign bit.
|
|
|
|
if (LHSKnown.isNegative() || RHSKnown.isNegative()) {
|
|
|
|
APInt MinLHS = LHSKnown.One;
|
|
|
|
MinLHS.clearSignBit();
|
|
|
|
APInt MinRHS = RHSKnown.One;
|
|
|
|
MinRHS.clearSignBit();
|
|
|
|
APInt Result = std::move(MinLHS) + std::move(MinRHS);
|
|
|
|
return Result.isSignBitSet();
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we reached here it means that we know nothing about the sign bits.
|
2018-07-30 21:41:25 +02:00
|
|
|
// In this case we can't know if there will be an overflow, since by
|
2017-05-15 04:44:08 +02:00
|
|
|
// changing the sign bits any two values can be made to overflow.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
static OverflowResult computeOverflowForSignedAdd(const Value *LHS,
|
|
|
|
const Value *RHS,
|
|
|
|
const AddOperator *Add,
|
|
|
|
const DataLayout &DL,
|
2016-12-19 09:22:17 +01:00
|
|
|
AssumptionCache *AC,
|
2016-08-13 03:05:32 +02:00
|
|
|
const Instruction *CxtI,
|
|
|
|
const DominatorTree *DT) {
|
2015-08-20 20:27:04 +02:00
|
|
|
if (Add && Add->hasNoSignedWrap()) {
|
|
|
|
return OverflowResult::NeverOverflows;
|
|
|
|
}
|
|
|
|
|
2017-05-15 04:44:08 +02:00
|
|
|
// If LHS and RHS each have at least two sign bits, the addition will look
|
|
|
|
// like
|
|
|
|
//
|
|
|
|
// XX..... +
|
|
|
|
// YY.....
|
|
|
|
//
|
|
|
|
// If the carry into the most significant position is 0, X and Y can't both
|
|
|
|
// be 1 and therefore the carry out of the addition is also 0.
|
|
|
|
//
|
|
|
|
// If the carry into the most significant position is 1, X and Y can't both
|
|
|
|
// be 0 and therefore the carry out of the addition is also 1.
|
|
|
|
//
|
|
|
|
// Since the carry into the most significant position is always equal to
|
|
|
|
// the carry out of the addition, there is no signed overflow.
|
|
|
|
if (ComputeNumSignBits(LHS, DL, 0, AC, CxtI, DT) > 1 &&
|
|
|
|
ComputeNumSignBits(RHS, DL, 0, AC, CxtI, DT) > 1)
|
|
|
|
return OverflowResult::NeverOverflows;
|
|
|
|
|
2017-05-08 18:22:48 +02:00
|
|
|
KnownBits LHSKnown = computeKnownBits(LHS, DL, /*Depth=*/0, AC, CxtI, DT);
|
|
|
|
KnownBits RHSKnown = computeKnownBits(RHS, DL, /*Depth=*/0, AC, CxtI, DT);
|
2015-08-20 20:27:04 +02:00
|
|
|
|
2017-05-15 04:44:08 +02:00
|
|
|
if (checkRippleForSignedAdd(LHSKnown, RHSKnown))
|
2015-08-20 20:27:04 +02:00
|
|
|
return OverflowResult::NeverOverflows;
|
|
|
|
|
|
|
|
// The remaining code needs Add to be available. Early returns if not so.
|
|
|
|
if (!Add)
|
|
|
|
return OverflowResult::MayOverflow;
|
|
|
|
|
|
|
|
// If the sign of Add is the same as at least one of the operands, this add
|
|
|
|
// CANNOT overflow. This is particularly useful when the sum is
|
|
|
|
// @llvm.assume'ed non-negative rather than proved so from analyzing its
|
|
|
|
// operands.
|
|
|
|
bool LHSOrRHSKnownNonNegative =
|
2017-05-08 18:22:48 +02:00
|
|
|
(LHSKnown.isNonNegative() || RHSKnown.isNonNegative());
|
2018-07-30 21:41:25 +02:00
|
|
|
bool LHSOrRHSKnownNegative =
|
2017-05-15 04:44:08 +02:00
|
|
|
(LHSKnown.isNegative() || RHSKnown.isNegative());
|
2015-08-20 20:27:04 +02:00
|
|
|
if (LHSOrRHSKnownNonNegative || LHSOrRHSKnownNegative) {
|
2017-05-08 18:22:48 +02:00
|
|
|
KnownBits AddKnown = computeKnownBits(Add, DL, /*Depth=*/0, AC, CxtI, DT);
|
|
|
|
if ((AddKnown.isNonNegative() && LHSOrRHSKnownNonNegative) ||
|
|
|
|
(AddKnown.isNegative() && LHSOrRHSKnownNegative)) {
|
2015-08-20 20:27:04 +02:00
|
|
|
return OverflowResult::NeverOverflows;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return OverflowResult::MayOverflow;
|
|
|
|
}
|
|
|
|
|
2018-05-10 21:46:19 +02:00
|
|
|
OverflowResult llvm::computeOverflowForUnsignedSub(const Value *LHS,
|
|
|
|
const Value *RHS,
|
|
|
|
const DataLayout &DL,
|
|
|
|
AssumptionCache *AC,
|
|
|
|
const Instruction *CxtI,
|
|
|
|
const DominatorTree *DT) {
|
|
|
|
KnownBits LHSKnown = computeKnownBits(LHS, DL, /*Depth=*/0, AC, CxtI, DT);
|
2018-11-28 17:37:04 +01:00
|
|
|
if (LHSKnown.isNonNegative() || LHSKnown.isNegative()) {
|
|
|
|
KnownBits RHSKnown = computeKnownBits(RHS, DL, /*Depth=*/0, AC, CxtI, DT);
|
|
|
|
|
|
|
|
// If the LHS is negative and the RHS is non-negative, no unsigned wrap.
|
|
|
|
if (LHSKnown.isNegative() && RHSKnown.isNonNegative())
|
|
|
|
return OverflowResult::NeverOverflows;
|
|
|
|
|
|
|
|
// If the LHS is non-negative and the RHS negative, we always wrap.
|
|
|
|
if (LHSKnown.isNonNegative() && RHSKnown.isNegative())
|
|
|
|
return OverflowResult::AlwaysOverflows;
|
|
|
|
}
|
2018-05-10 21:46:19 +02:00
|
|
|
|
|
|
|
return OverflowResult::MayOverflow;
|
|
|
|
}
|
|
|
|
|
|
|
|
OverflowResult llvm::computeOverflowForSignedSub(const Value *LHS,
|
|
|
|
const Value *RHS,
|
|
|
|
const DataLayout &DL,
|
|
|
|
AssumptionCache *AC,
|
|
|
|
const Instruction *CxtI,
|
|
|
|
const DominatorTree *DT) {
|
|
|
|
// If LHS and RHS each have at least two sign bits, the subtraction
|
|
|
|
// cannot overflow.
|
|
|
|
if (ComputeNumSignBits(LHS, DL, 0, AC, CxtI, DT) > 1 &&
|
|
|
|
ComputeNumSignBits(RHS, DL, 0, AC, CxtI, DT) > 1)
|
|
|
|
return OverflowResult::NeverOverflows;
|
|
|
|
|
|
|
|
KnownBits LHSKnown = computeKnownBits(LHS, DL, 0, AC, CxtI, DT);
|
|
|
|
|
|
|
|
KnownBits RHSKnown = computeKnownBits(RHS, DL, 0, AC, CxtI, DT);
|
|
|
|
|
|
|
|
// Subtraction of two 2's complement numbers having identical signs will
|
|
|
|
// never overflow.
|
|
|
|
if ((LHSKnown.isNegative() && RHSKnown.isNegative()) ||
|
|
|
|
(LHSKnown.isNonNegative() && RHSKnown.isNonNegative()))
|
|
|
|
return OverflowResult::NeverOverflows;
|
|
|
|
|
|
|
|
// TODO: implement logic similar to checkRippleForAdd
|
|
|
|
return OverflowResult::MayOverflow;
|
|
|
|
}
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
bool llvm::isOverflowIntrinsicNoWrap(const IntrinsicInst *II,
|
|
|
|
const DominatorTree &DT) {
|
2016-05-29 02:34:42 +02:00
|
|
|
#ifndef NDEBUG
|
|
|
|
auto IID = II->getIntrinsicID();
|
|
|
|
assert((IID == Intrinsic::sadd_with_overflow ||
|
|
|
|
IID == Intrinsic::uadd_with_overflow ||
|
|
|
|
IID == Intrinsic::ssub_with_overflow ||
|
|
|
|
IID == Intrinsic::usub_with_overflow ||
|
|
|
|
IID == Intrinsic::smul_with_overflow ||
|
|
|
|
IID == Intrinsic::umul_with_overflow) &&
|
|
|
|
"Not an overflow intrinsic!");
|
|
|
|
#endif
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
SmallVector<const BranchInst *, 2> GuardingBranches;
|
|
|
|
SmallVector<const ExtractValueInst *, 2> Results;
|
2016-05-29 02:34:42 +02:00
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
for (const User *U : II->users()) {
|
|
|
|
if (const auto *EVI = dyn_cast<ExtractValueInst>(U)) {
|
2016-05-29 02:34:42 +02:00
|
|
|
assert(EVI->getNumIndices() == 1 && "Obvious from CI's type");
|
|
|
|
|
|
|
|
if (EVI->getIndices()[0] == 0)
|
|
|
|
Results.push_back(EVI);
|
|
|
|
else {
|
|
|
|
assert(EVI->getIndices()[0] == 1 && "Obvious from CI's type");
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
for (const auto *U : EVI->users())
|
|
|
|
if (const auto *B = dyn_cast<BranchInst>(U)) {
|
2016-05-29 02:34:42 +02:00
|
|
|
assert(B->isConditional() && "How else is it using an i1?");
|
|
|
|
GuardingBranches.push_back(B);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// We are using the aggregate directly in a way we don't want to analyze
|
|
|
|
// here (storing it to a global, say).
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
auto AllUsesGuardedByBranch = [&](const BranchInst *BI) {
|
2016-05-29 02:34:42 +02:00
|
|
|
BasicBlockEdge NoWrapEdge(BI->getParent(), BI->getSuccessor(1));
|
|
|
|
if (!NoWrapEdge.isSingleEdge())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Check if all users of the add are provably no-wrap.
|
2016-08-13 03:05:32 +02:00
|
|
|
for (const auto *Result : Results) {
|
2016-05-29 02:34:42 +02:00
|
|
|
// If the extractvalue itself is not executed on overflow, the we don't
|
|
|
|
// need to check each use separately, since domination is transitive.
|
|
|
|
if (DT.dominates(NoWrapEdge, Result->getParent()))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
for (auto &RU : Result->uses())
|
|
|
|
if (!DT.dominates(NoWrapEdge, RU))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
};
|
|
|
|
|
2017-09-01 23:37:29 +02:00
|
|
|
return llvm::any_of(GuardingBranches, AllUsesGuardedByBranch);
|
2016-05-29 02:34:42 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
OverflowResult llvm::computeOverflowForSignedAdd(const AddOperator *Add,
|
2015-08-20 20:27:04 +02:00
|
|
|
const DataLayout &DL,
|
2016-12-19 09:22:17 +01:00
|
|
|
AssumptionCache *AC,
|
2015-08-20 20:27:04 +02:00
|
|
|
const Instruction *CxtI,
|
|
|
|
const DominatorTree *DT) {
|
|
|
|
return ::computeOverflowForSignedAdd(Add->getOperand(0), Add->getOperand(1),
|
2016-12-19 09:22:17 +01:00
|
|
|
Add, DL, AC, CxtI, DT);
|
2015-08-20 20:27:04 +02:00
|
|
|
}
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
OverflowResult llvm::computeOverflowForSignedAdd(const Value *LHS,
|
|
|
|
const Value *RHS,
|
2015-08-20 20:27:04 +02:00
|
|
|
const DataLayout &DL,
|
2016-12-19 09:22:17 +01:00
|
|
|
AssumptionCache *AC,
|
2015-08-20 20:27:04 +02:00
|
|
|
const Instruction *CxtI,
|
|
|
|
const DominatorTree *DT) {
|
2016-12-19 09:22:17 +01:00
|
|
|
return ::computeOverflowForSignedAdd(LHS, RHS, nullptr, DL, AC, CxtI, DT);
|
2015-08-20 20:27:04 +02:00
|
|
|
}
|
|
|
|
|
2015-07-28 20:22:40 +02:00
|
|
|
bool llvm::isGuaranteedToTransferExecutionToSuccessor(const Instruction *I) {
|
[LICM] Make isGuaranteedToExecute more accurate.
Summary:
Make isGuaranteedToExecute use the
isGuaranteedToTransferExecutionToSuccessor helper, and make that helper
a bit more accurate.
There's a potential performance impact here from assuming that arbitrary
calls might not return. This probably has little impact on loads and
stores to a pointer because most things alias analysis can reason about
are dereferenceable anyway. The other impacts, like less aggressive
hoisting of sdiv by a variable and less aggressive hoisting around
volatile memory operations, are unlikely to matter for real code.
This also impacts SCEV, which uses the same helper. It's a minor
improvement there because we can tell that, for example, memcpy always
returns normally. Strictly speaking, it's also introducing
a bug, but it's not any worse than everywhere else we assume readonly
functions terminate.
Fixes http://llvm.org/PR27857.
Reviewers: hfinkel, reames, chandlerc, sanjoy
Subscribers: broune, llvm-commits
Differential Revision: http://reviews.llvm.org/D21167
llvm-svn: 272489
2016-06-11 23:48:25 +02:00
|
|
|
// A memory operation returns normally if it isn't volatile. A volatile
|
|
|
|
// operation is allowed to trap.
|
|
|
|
//
|
|
|
|
// An atomic operation isn't guaranteed to return in a reasonable amount of
|
|
|
|
// time because it's possible for another thread to interfere with it for an
|
|
|
|
// arbitrary length of time, but programs aren't allowed to rely on that.
|
|
|
|
if (const LoadInst *LI = dyn_cast<LoadInst>(I))
|
|
|
|
return !LI->isVolatile();
|
|
|
|
if (const StoreInst *SI = dyn_cast<StoreInst>(I))
|
|
|
|
return !SI->isVolatile();
|
|
|
|
if (const AtomicCmpXchgInst *CXI = dyn_cast<AtomicCmpXchgInst>(I))
|
|
|
|
return !CXI->isVolatile();
|
|
|
|
if (const AtomicRMWInst *RMWI = dyn_cast<AtomicRMWInst>(I))
|
|
|
|
return !RMWI->isVolatile();
|
|
|
|
if (const MemIntrinsic *MII = dyn_cast<MemIntrinsic>(I))
|
|
|
|
return !MII->isVolatile();
|
|
|
|
|
|
|
|
// If there is no successor, then execution can't transfer to it.
|
|
|
|
if (const auto *CRI = dyn_cast<CleanupReturnInst>(I))
|
|
|
|
return !CRI->unwindsToCaller();
|
|
|
|
if (const auto *CatchSwitch = dyn_cast<CatchSwitchInst>(I))
|
|
|
|
return !CatchSwitch->unwindsToCaller();
|
|
|
|
if (isa<ResumeInst>(I))
|
|
|
|
return false;
|
|
|
|
if (isa<ReturnInst>(I))
|
|
|
|
return false;
|
2017-03-08 02:54:50 +01:00
|
|
|
if (isa<UnreachableInst>(I))
|
|
|
|
return false;
|
[LICM] Make isGuaranteedToExecute more accurate.
Summary:
Make isGuaranteedToExecute use the
isGuaranteedToTransferExecutionToSuccessor helper, and make that helper
a bit more accurate.
There's a potential performance impact here from assuming that arbitrary
calls might not return. This probably has little impact on loads and
stores to a pointer because most things alias analysis can reason about
are dereferenceable anyway. The other impacts, like less aggressive
hoisting of sdiv by a variable and less aggressive hoisting around
volatile memory operations, are unlikely to matter for real code.
This also impacts SCEV, which uses the same helper. It's a minor
improvement there because we can tell that, for example, memcpy always
returns normally. Strictly speaking, it's also introducing
a bug, but it's not any worse than everywhere else we assume readonly
functions terminate.
Fixes http://llvm.org/PR27857.
Reviewers: hfinkel, reames, chandlerc, sanjoy
Subscribers: broune, llvm-commits
Differential Revision: http://reviews.llvm.org/D21167
llvm-svn: 272489
2016-06-11 23:48:25 +02:00
|
|
|
|
|
|
|
// Calls can throw, or contain an infinite loop, or kill the process.
|
2016-12-31 23:12:31 +01:00
|
|
|
if (auto CS = ImmutableCallSite(I)) {
|
2016-12-31 23:12:34 +01:00
|
|
|
// Call sites that throw have implicit non-local control flow.
|
|
|
|
if (!CS.doesNotThrow())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Non-throwing call sites can loop infinitely, call exit/pthread_exit
|
|
|
|
// etc. and thus not return. However, LLVM already assumes that
|
|
|
|
//
|
|
|
|
// - Thread exiting actions are modeled as writes to memory invisible to
|
|
|
|
// the program.
|
|
|
|
//
|
|
|
|
// - Loops that don't have side effects (side effects are volatile/atomic
|
|
|
|
// stores and IO) always terminate (see http://llvm.org/PR965).
|
|
|
|
// Furthermore IO itself is also modeled as writes to memory invisible to
|
|
|
|
// the program.
|
|
|
|
//
|
|
|
|
// We rely on those assumptions here, and use the memory effects of the call
|
|
|
|
// target as a proxy for checking that it always returns.
|
|
|
|
|
|
|
|
// FIXME: This isn't aggressive enough; a call which only writes to a global
|
|
|
|
// is guaranteed to return.
|
2016-06-14 22:23:16 +02:00
|
|
|
return CS.onlyReadsMemory() || CS.onlyAccessesArgMemory() ||
|
Add an @llvm.sideeffect intrinsic
This patch implements Chandler's idea [0] for supporting languages that
require support for infinite loops with side effects, such as Rust, providing
part of a solution to bug 965 [1].
Specifically, it adds an `llvm.sideeffect()` intrinsic, which has no actual
effect, but which appears to optimization passes to have obscure side effects,
such that they don't optimize away loops containing it. It also teaches
several optimization passes to ignore this intrinsic, so that it doesn't
significantly impact optimization in most cases.
As discussed on llvm-dev [2], this patch is the first of two major parts.
The second part, to change LLVM's semantics to have defined behavior
on infinite loops by default, with a function attribute for opting into
potential-undefined-behavior, will be implemented and posted for review in
a separate patch.
[0] http://lists.llvm.org/pipermail/llvm-dev/2015-July/088103.html
[1] https://bugs.llvm.org/show_bug.cgi?id=965
[2] http://lists.llvm.org/pipermail/llvm-dev/2017-October/118632.html
Differential Revision: https://reviews.llvm.org/D38336
llvm-svn: 317729
2017-11-08 22:59:51 +01:00
|
|
|
match(I, m_Intrinsic<Intrinsic::assume>()) ||
|
|
|
|
match(I, m_Intrinsic<Intrinsic::sideeffect>());
|
[LICM] Make isGuaranteedToExecute more accurate.
Summary:
Make isGuaranteedToExecute use the
isGuaranteedToTransferExecutionToSuccessor helper, and make that helper
a bit more accurate.
There's a potential performance impact here from assuming that arbitrary
calls might not return. This probably has little impact on loads and
stores to a pointer because most things alias analysis can reason about
are dereferenceable anyway. The other impacts, like less aggressive
hoisting of sdiv by a variable and less aggressive hoisting around
volatile memory operations, are unlikely to matter for real code.
This also impacts SCEV, which uses the same helper. It's a minor
improvement there because we can tell that, for example, memcpy always
returns normally. Strictly speaking, it's also introducing
a bug, but it's not any worse than everywhere else we assume readonly
functions terminate.
Fixes http://llvm.org/PR27857.
Reviewers: hfinkel, reames, chandlerc, sanjoy
Subscribers: broune, llvm-commits
Differential Revision: http://reviews.llvm.org/D21167
llvm-svn: 272489
2016-06-11 23:48:25 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
// Other instructions return normally.
|
|
|
|
return true;
|
2015-07-28 20:22:40 +02:00
|
|
|
}
|
|
|
|
|
2018-03-08 22:25:30 +01:00
|
|
|
bool llvm::isGuaranteedToTransferExecutionToSuccessor(const BasicBlock *BB) {
|
|
|
|
// TODO: This is slightly consdervative for invoke instruction since exiting
|
|
|
|
// via an exception *is* normal control for them.
|
|
|
|
for (auto I = BB->begin(), E = BB->end(); I != E; ++I)
|
|
|
|
if (!isGuaranteedToTransferExecutionToSuccessor(&*I))
|
|
|
|
return false;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-07-28 20:22:40 +02:00
|
|
|
bool llvm::isGuaranteedToExecuteForEveryIteration(const Instruction *I,
|
|
|
|
const Loop *L) {
|
|
|
|
// The loop header is guaranteed to be executed for every iteration.
|
|
|
|
//
|
|
|
|
// FIXME: Relax this constraint to cover all basic blocks that are
|
|
|
|
// guaranteed to be executed at every iteration.
|
|
|
|
if (I->getParent() != L->getHeader()) return false;
|
|
|
|
|
|
|
|
for (const Instruction &LI : *L->getHeader()) {
|
|
|
|
if (&LI == I) return true;
|
|
|
|
if (!isGuaranteedToTransferExecutionToSuccessor(&LI)) return false;
|
|
|
|
}
|
|
|
|
llvm_unreachable("Instruction not contained in its own parent basic block.");
|
|
|
|
}
|
|
|
|
|
|
|
|
bool llvm::propagatesFullPoison(const Instruction *I) {
|
|
|
|
switch (I->getOpcode()) {
|
2017-02-21 03:42:42 +01:00
|
|
|
case Instruction::Add:
|
|
|
|
case Instruction::Sub:
|
|
|
|
case Instruction::Xor:
|
|
|
|
case Instruction::Trunc:
|
|
|
|
case Instruction::BitCast:
|
|
|
|
case Instruction::AddrSpaceCast:
|
[ValueTracking] Make poison propagation more aggressive
Summary:
Motivation: fix PR31181 without regression (the actual fix is still in
progress). However, the actual content of PR31181 is not relevant
here.
This change makes poison propagation more aggressive in the following
cases:
1. poision * Val == poison, for any Val. In particular, this changes
existing intentional and documented behavior in these two cases:
a. Val is 0
b. Val is 2^k * N
2. poison << Val == poison, for any Val
3. getelementptr is poison if any input is poison
I think all of these are justified (and are axiomatically true in the
new poison / undef model):
1a: we need poison * 0 to be poison to allow transforms like these:
A * (B + C) ==> A * B + A * C
If poison * 0 were 0 then the above transform could not be allowed
since e.g. we could have A = poison, B = 1, C = -1, making the LHS
poison * (1 + -1) = poison * 0 = 0
and the RHS
poison * 1 + poison * -1 = poison + poison = poison
1b: we need e.g. poison * 4 to be poison since we want to allow
A * 4 ==> A + A + A + A
If poison * 4 were a value with all of their bits poison except the
last four; then we'd not be able to do this transform since then if A
were poison the LHS would only be "partially" poison while the RHS
would be "full" poison.
2: Same reasoning as (1b), we'd like have the following kinds
transforms be legal:
A << 1 ==> A + A
Reviewers: majnemer, efriedma
Subscribers: mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D30185
llvm-svn: 295809
2017-02-22 07:52:32 +01:00
|
|
|
case Instruction::Mul:
|
|
|
|
case Instruction::Shl:
|
|
|
|
case Instruction::GetElementPtr:
|
2017-02-21 03:42:42 +01:00
|
|
|
// These operations all propagate poison unconditionally. Note that poison
|
|
|
|
// is not any particular value, so xor or subtraction of poison with
|
|
|
|
// itself still yields poison, not zero.
|
|
|
|
return true;
|
2015-07-28 20:22:40 +02:00
|
|
|
|
2017-02-21 03:42:42 +01:00
|
|
|
case Instruction::AShr:
|
|
|
|
case Instruction::SExt:
|
|
|
|
// For these operations, one bit of the input is replicated across
|
|
|
|
// multiple output bits. A replicated poison bit is still poison.
|
|
|
|
return true;
|
2015-07-28 20:22:40 +02:00
|
|
|
|
2017-02-21 03:42:42 +01:00
|
|
|
case Instruction::ICmp:
|
|
|
|
// Comparing poison with any value yields poison. This is why, for
|
|
|
|
// instance, x s< (x +nsw 1) can be folded to true.
|
|
|
|
return true;
|
2016-05-29 02:31:18 +02:00
|
|
|
|
2017-02-21 03:42:42 +01:00
|
|
|
default:
|
|
|
|
return false;
|
2015-07-28 20:22:40 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
const Value *llvm::getGuaranteedNonFullPoisonOp(const Instruction *I) {
|
|
|
|
switch (I->getOpcode()) {
|
|
|
|
case Instruction::Store:
|
|
|
|
return cast<StoreInst>(I)->getPointerOperand();
|
|
|
|
|
|
|
|
case Instruction::Load:
|
|
|
|
return cast<LoadInst>(I)->getPointerOperand();
|
|
|
|
|
|
|
|
case Instruction::AtomicCmpXchg:
|
|
|
|
return cast<AtomicCmpXchgInst>(I)->getPointerOperand();
|
|
|
|
|
|
|
|
case Instruction::AtomicRMW:
|
|
|
|
return cast<AtomicRMWInst>(I)->getPointerOperand();
|
|
|
|
|
|
|
|
case Instruction::UDiv:
|
|
|
|
case Instruction::SDiv:
|
|
|
|
case Instruction::URem:
|
|
|
|
case Instruction::SRem:
|
|
|
|
return I->getOperand(1);
|
|
|
|
|
|
|
|
default:
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-04-30 21:41:19 +02:00
|
|
|
bool llvm::programUndefinedIfFullPoison(const Instruction *PoisonI) {
|
2015-07-28 20:22:40 +02:00
|
|
|
// We currently only look for uses of poison values within the same basic
|
|
|
|
// block, as that makes it easier to guarantee that the uses will be
|
|
|
|
// executed given that PoisonI is executed.
|
|
|
|
//
|
|
|
|
// FIXME: Expand this to consider uses beyond the same basic block. To do
|
|
|
|
// this, look out for the distinction between post-dominance and strong
|
|
|
|
// post-dominance.
|
|
|
|
const BasicBlock *BB = PoisonI->getParent();
|
|
|
|
|
|
|
|
// Set of instructions that we have proved will yield poison if PoisonI
|
|
|
|
// does.
|
|
|
|
SmallSet<const Value *, 16> YieldsPoison;
|
2016-04-22 19:41:06 +02:00
|
|
|
SmallSet<const BasicBlock *, 4> Visited;
|
2015-07-28 20:22:40 +02:00
|
|
|
YieldsPoison.insert(PoisonI);
|
2016-04-22 19:41:06 +02:00
|
|
|
Visited.insert(PoisonI->getParent());
|
2015-07-28 20:22:40 +02:00
|
|
|
|
2016-04-22 19:41:06 +02:00
|
|
|
BasicBlock::const_iterator Begin = PoisonI->getIterator(), End = BB->end();
|
|
|
|
|
|
|
|
unsigned Iter = 0;
|
|
|
|
while (Iter++ < MaxDepth) {
|
|
|
|
for (auto &I : make_range(Begin, End)) {
|
|
|
|
if (&I != PoisonI) {
|
|
|
|
const Value *NotPoison = getGuaranteedNonFullPoisonOp(&I);
|
|
|
|
if (NotPoison != nullptr && YieldsPoison.count(NotPoison))
|
|
|
|
return true;
|
|
|
|
if (!isGuaranteedToTransferExecutionToSuccessor(&I))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Mark poison that propagates from I through uses of I.
|
|
|
|
if (YieldsPoison.count(&I)) {
|
|
|
|
for (const User *User : I.users()) {
|
|
|
|
const Instruction *UserI = cast<Instruction>(User);
|
|
|
|
if (propagatesFullPoison(UserI))
|
|
|
|
YieldsPoison.insert(User);
|
|
|
|
}
|
|
|
|
}
|
2015-07-28 20:22:40 +02:00
|
|
|
}
|
|
|
|
|
2016-04-22 19:41:06 +02:00
|
|
|
if (auto *NextBB = BB->getSingleSuccessor()) {
|
|
|
|
if (Visited.insert(NextBB).second) {
|
|
|
|
BB = NextBB;
|
|
|
|
Begin = BB->getFirstNonPHI()->getIterator();
|
|
|
|
End = BB->end();
|
|
|
|
continue;
|
2015-07-28 20:22:40 +02:00
|
|
|
}
|
|
|
|
}
|
2016-04-22 19:41:06 +02:00
|
|
|
|
|
|
|
break;
|
2017-09-01 23:37:29 +02:00
|
|
|
}
|
2015-07-28 20:22:40 +02:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
static bool isKnownNonNaN(const Value *V, FastMathFlags FMF) {
|
2015-08-11 11:12:57 +02:00
|
|
|
if (FMF.noNaNs())
|
|
|
|
return true;
|
|
|
|
|
|
|
|
if (auto *C = dyn_cast<ConstantFP>(V))
|
|
|
|
return !C->isNaN();
|
2018-09-28 23:36:43 +02:00
|
|
|
|
|
|
|
if (auto *C = dyn_cast<ConstantDataVector>(V)) {
|
|
|
|
if (!C->getElementType()->isFloatingPointTy())
|
|
|
|
return false;
|
|
|
|
for (unsigned I = 0, E = C->getNumElements(); I < E; ++I) {
|
|
|
|
if (C->getElementAsAPFloat(I).isNaN())
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-08-11 11:12:57 +02:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
static bool isKnownNonZero(const Value *V) {
|
2015-08-11 11:12:57 +02:00
|
|
|
if (auto *C = dyn_cast<ConstantFP>(V))
|
|
|
|
return !C->isZero();
|
2018-09-28 23:36:43 +02:00
|
|
|
|
|
|
|
if (auto *C = dyn_cast<ConstantDataVector>(V)) {
|
|
|
|
if (!C->getElementType()->isFloatingPointTy())
|
|
|
|
return false;
|
|
|
|
for (unsigned I = 0, E = C->getNumElements(); I < E; ++I) {
|
|
|
|
if (C->getElementAsAPFloat(I).isZero())
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-08-11 11:12:57 +02:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
[InstCombine] Canonicalize clamp of float types to minmax in fast mode.
Summary:
This commit allows matchSelectPattern to recognize clamp of float
arguments in the presence of FMF the same way as already done for
integers.
This case is a little different though. With integers, given the
min/max pattern is recognized, DAGBuilder starts selecting MIN/MAX
"automatically". That is not the case for float, because for them only
full FMINNAN/FMINNUM/FMAXNAN/FMAXNUM ISD nodes exist and they do care
about NaNs. On the other hand, some backends (e.g. X86) have only
FMIN/FMAX nodes that do not care about NaNS and the former NAN/NUM
nodes are illegal thus selection is not happening. So I decided to do
such kind of transformation in IR (InstCombiner) instead of
complicating the logic in the backend.
Reviewers: spatel, jmolloy, majnemer, efriedma, craig.topper
Reviewed By: efriedma
Subscribers: hiraditya, javed.absar, n.bozhenov, llvm-commits
Patch by Andrei Elovikov <andrei.elovikov@intel.com>
Differential Revision: https://reviews.llvm.org/D33186
llvm-svn: 310054
2017-08-04 14:22:17 +02:00
|
|
|
/// Match clamp pattern for float types without care about NaNs or signed zeros.
|
|
|
|
/// Given non-min/max outer cmp/select from the clamp pattern this
|
|
|
|
/// function recognizes if it can be substitued by a "canonical" min/max
|
|
|
|
/// pattern.
|
|
|
|
static SelectPatternResult matchFastFloatClamp(CmpInst::Predicate Pred,
|
|
|
|
Value *CmpLHS, Value *CmpRHS,
|
|
|
|
Value *TrueVal, Value *FalseVal,
|
|
|
|
Value *&LHS, Value *&RHS) {
|
|
|
|
// Try to match
|
|
|
|
// X < C1 ? C1 : Min(X, C2) --> Max(C1, Min(X, C2))
|
|
|
|
// X > C1 ? C1 : Max(X, C2) --> Min(C1, Max(X, C2))
|
|
|
|
// and return description of the outer Max/Min.
|
|
|
|
|
|
|
|
// First, check if select has inverse order:
|
|
|
|
if (CmpRHS == FalseVal) {
|
|
|
|
std::swap(TrueVal, FalseVal);
|
|
|
|
Pred = CmpInst::getInversePredicate(Pred);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Assume success now. If there's no match, callers should not use these anyway.
|
|
|
|
LHS = TrueVal;
|
|
|
|
RHS = FalseVal;
|
|
|
|
|
|
|
|
const APFloat *FC1;
|
|
|
|
if (CmpRHS != TrueVal || !match(CmpRHS, m_APFloat(FC1)) || !FC1->isFinite())
|
|
|
|
return {SPF_UNKNOWN, SPNB_NA, false};
|
|
|
|
|
|
|
|
const APFloat *FC2;
|
|
|
|
switch (Pred) {
|
|
|
|
case CmpInst::FCMP_OLT:
|
|
|
|
case CmpInst::FCMP_OLE:
|
|
|
|
case CmpInst::FCMP_ULT:
|
|
|
|
case CmpInst::FCMP_ULE:
|
|
|
|
if (match(FalseVal,
|
|
|
|
m_CombineOr(m_OrdFMin(m_Specific(CmpLHS), m_APFloat(FC2)),
|
|
|
|
m_UnordFMin(m_Specific(CmpLHS), m_APFloat(FC2)))) &&
|
|
|
|
FC1->compare(*FC2) == APFloat::cmpResult::cmpLessThan)
|
|
|
|
return {SPF_FMAXNUM, SPNB_RETURNS_ANY, false};
|
|
|
|
break;
|
|
|
|
case CmpInst::FCMP_OGT:
|
|
|
|
case CmpInst::FCMP_OGE:
|
|
|
|
case CmpInst::FCMP_UGT:
|
|
|
|
case CmpInst::FCMP_UGE:
|
|
|
|
if (match(FalseVal,
|
|
|
|
m_CombineOr(m_OrdFMax(m_Specific(CmpLHS), m_APFloat(FC2)),
|
|
|
|
m_UnordFMax(m_Specific(CmpLHS), m_APFloat(FC2)))) &&
|
|
|
|
FC1->compare(*FC2) == APFloat::cmpResult::cmpGreaterThan)
|
|
|
|
return {SPF_FMINNUM, SPNB_RETURNS_ANY, false};
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return {SPF_UNKNOWN, SPNB_NA, false};
|
|
|
|
}
|
|
|
|
|
2017-10-27 22:53:41 +02:00
|
|
|
/// Recognize variations of:
|
|
|
|
/// CLAMP(v,l,h) ==> ((v) < (l) ? (l) : ((v) > (h) ? (h) : (v)))
|
|
|
|
static SelectPatternResult matchClamp(CmpInst::Predicate Pred,
|
|
|
|
Value *CmpLHS, Value *CmpRHS,
|
|
|
|
Value *TrueVal, Value *FalseVal) {
|
|
|
|
// Swap the select operands and predicate to match the patterns below.
|
|
|
|
if (CmpRHS != TrueVal) {
|
|
|
|
Pred = ICmpInst::getSwappedPredicate(Pred);
|
|
|
|
std::swap(TrueVal, FalseVal);
|
|
|
|
}
|
[ValueTracking] recognize variations of 'clamp' to improve codegen (PR31693)
By enhancing value tracking, we allow an existing min/max canonicalization to
kick in and improve codegen for several targets that have min/max instructions.
Unfortunately, recognizing min/max in value tracking may cause us to hit
a hack in InstCombiner::visitICmpInst() more often:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/109340.html
...but I'm hoping we can remove that soon.
Correctness proofs based on Alive:
Name: smaxmin
Pre: C1 < C2
%cmp2 = icmp slt i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp slt i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %min
=>
%cmp2 = icmp slt i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp sgt i8 %min, C1
%r = select i1 %cmp1, i8 %min, i8 C1
Name: sminmax
Pre: C1 > C2
%cmp2 = icmp sgt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp sgt i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %max
=>
%cmp2 = icmp sgt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp slt i8 %max, C1
%r = select i1 %cmp1, i8 %max, i8 C1
----------------------------------------
Optimization: smaxmin
Done: 1
Optimization is correct!
----------------------------------------
Optimization: sminmax
Done: 1
Optimization is correct!
Name: umaxmin
Pre: C1 u< C2
%cmp2 = icmp ult i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp ult i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %min
=>
%cmp2 = icmp ult i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp ugt i8 %min, C1
%r = select i1 %cmp1, i8 %min, i8 C1
Name: uminmax
Pre: C1 u> C2
%cmp2 = icmp ugt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp ugt i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %max
=>
%cmp2 = icmp ugt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp ult i8 %max, C1
%r = select i1 %cmp1, i8 %max, i8 C1
----------------------------------------
Optimization: umaxmin
Done: 1
Optimization is correct!
----------------------------------------
Optimization: uminmax
Done: 1
Optimization is correct!
llvm-svn: 292660
2017-01-20 23:18:47 +01:00
|
|
|
const APInt *C1;
|
|
|
|
if (CmpRHS == TrueVal && match(CmpRHS, m_APInt(C1))) {
|
|
|
|
const APInt *C2;
|
|
|
|
// (X <s C1) ? C1 : SMIN(X, C2) ==> SMAX(SMIN(X, C2), C1)
|
|
|
|
if (match(FalseVal, m_SMin(m_Specific(CmpLHS), m_APInt(C2))) &&
|
2017-10-19 17:36:18 +02:00
|
|
|
C1->slt(*C2) && Pred == CmpInst::ICMP_SLT)
|
[ValueTracking] recognize variations of 'clamp' to improve codegen (PR31693)
By enhancing value tracking, we allow an existing min/max canonicalization to
kick in and improve codegen for several targets that have min/max instructions.
Unfortunately, recognizing min/max in value tracking may cause us to hit
a hack in InstCombiner::visitICmpInst() more often:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/109340.html
...but I'm hoping we can remove that soon.
Correctness proofs based on Alive:
Name: smaxmin
Pre: C1 < C2
%cmp2 = icmp slt i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp slt i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %min
=>
%cmp2 = icmp slt i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp sgt i8 %min, C1
%r = select i1 %cmp1, i8 %min, i8 C1
Name: sminmax
Pre: C1 > C2
%cmp2 = icmp sgt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp sgt i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %max
=>
%cmp2 = icmp sgt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp slt i8 %max, C1
%r = select i1 %cmp1, i8 %max, i8 C1
----------------------------------------
Optimization: smaxmin
Done: 1
Optimization is correct!
----------------------------------------
Optimization: sminmax
Done: 1
Optimization is correct!
Name: umaxmin
Pre: C1 u< C2
%cmp2 = icmp ult i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp ult i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %min
=>
%cmp2 = icmp ult i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp ugt i8 %min, C1
%r = select i1 %cmp1, i8 %min, i8 C1
Name: uminmax
Pre: C1 u> C2
%cmp2 = icmp ugt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp ugt i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %max
=>
%cmp2 = icmp ugt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp ult i8 %max, C1
%r = select i1 %cmp1, i8 %max, i8 C1
----------------------------------------
Optimization: umaxmin
Done: 1
Optimization is correct!
----------------------------------------
Optimization: uminmax
Done: 1
Optimization is correct!
llvm-svn: 292660
2017-01-20 23:18:47 +01:00
|
|
|
return {SPF_SMAX, SPNB_NA, false};
|
|
|
|
|
|
|
|
// (X >s C1) ? C1 : SMAX(X, C2) ==> SMIN(SMAX(X, C2), C1)
|
|
|
|
if (match(FalseVal, m_SMax(m_Specific(CmpLHS), m_APInt(C2))) &&
|
2017-10-19 17:36:18 +02:00
|
|
|
C1->sgt(*C2) && Pred == CmpInst::ICMP_SGT)
|
[ValueTracking] recognize variations of 'clamp' to improve codegen (PR31693)
By enhancing value tracking, we allow an existing min/max canonicalization to
kick in and improve codegen for several targets that have min/max instructions.
Unfortunately, recognizing min/max in value tracking may cause us to hit
a hack in InstCombiner::visitICmpInst() more often:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/109340.html
...but I'm hoping we can remove that soon.
Correctness proofs based on Alive:
Name: smaxmin
Pre: C1 < C2
%cmp2 = icmp slt i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp slt i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %min
=>
%cmp2 = icmp slt i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp sgt i8 %min, C1
%r = select i1 %cmp1, i8 %min, i8 C1
Name: sminmax
Pre: C1 > C2
%cmp2 = icmp sgt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp sgt i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %max
=>
%cmp2 = icmp sgt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp slt i8 %max, C1
%r = select i1 %cmp1, i8 %max, i8 C1
----------------------------------------
Optimization: smaxmin
Done: 1
Optimization is correct!
----------------------------------------
Optimization: sminmax
Done: 1
Optimization is correct!
Name: umaxmin
Pre: C1 u< C2
%cmp2 = icmp ult i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp ult i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %min
=>
%cmp2 = icmp ult i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp ugt i8 %min, C1
%r = select i1 %cmp1, i8 %min, i8 C1
Name: uminmax
Pre: C1 u> C2
%cmp2 = icmp ugt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp ugt i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %max
=>
%cmp2 = icmp ugt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp ult i8 %max, C1
%r = select i1 %cmp1, i8 %max, i8 C1
----------------------------------------
Optimization: umaxmin
Done: 1
Optimization is correct!
----------------------------------------
Optimization: uminmax
Done: 1
Optimization is correct!
llvm-svn: 292660
2017-01-20 23:18:47 +01:00
|
|
|
return {SPF_SMIN, SPNB_NA, false};
|
|
|
|
|
|
|
|
// (X <u C1) ? C1 : UMIN(X, C2) ==> UMAX(UMIN(X, C2), C1)
|
|
|
|
if (match(FalseVal, m_UMin(m_Specific(CmpLHS), m_APInt(C2))) &&
|
2017-10-19 17:36:18 +02:00
|
|
|
C1->ult(*C2) && Pred == CmpInst::ICMP_ULT)
|
[ValueTracking] recognize variations of 'clamp' to improve codegen (PR31693)
By enhancing value tracking, we allow an existing min/max canonicalization to
kick in and improve codegen for several targets that have min/max instructions.
Unfortunately, recognizing min/max in value tracking may cause us to hit
a hack in InstCombiner::visitICmpInst() more often:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/109340.html
...but I'm hoping we can remove that soon.
Correctness proofs based on Alive:
Name: smaxmin
Pre: C1 < C2
%cmp2 = icmp slt i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp slt i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %min
=>
%cmp2 = icmp slt i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp sgt i8 %min, C1
%r = select i1 %cmp1, i8 %min, i8 C1
Name: sminmax
Pre: C1 > C2
%cmp2 = icmp sgt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp sgt i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %max
=>
%cmp2 = icmp sgt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp slt i8 %max, C1
%r = select i1 %cmp1, i8 %max, i8 C1
----------------------------------------
Optimization: smaxmin
Done: 1
Optimization is correct!
----------------------------------------
Optimization: sminmax
Done: 1
Optimization is correct!
Name: umaxmin
Pre: C1 u< C2
%cmp2 = icmp ult i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp ult i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %min
=>
%cmp2 = icmp ult i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp ugt i8 %min, C1
%r = select i1 %cmp1, i8 %min, i8 C1
Name: uminmax
Pre: C1 u> C2
%cmp2 = icmp ugt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp ugt i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %max
=>
%cmp2 = icmp ugt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp ult i8 %max, C1
%r = select i1 %cmp1, i8 %max, i8 C1
----------------------------------------
Optimization: umaxmin
Done: 1
Optimization is correct!
----------------------------------------
Optimization: uminmax
Done: 1
Optimization is correct!
llvm-svn: 292660
2017-01-20 23:18:47 +01:00
|
|
|
return {SPF_UMAX, SPNB_NA, false};
|
|
|
|
|
|
|
|
// (X >u C1) ? C1 : UMAX(X, C2) ==> UMIN(UMAX(X, C2), C1)
|
|
|
|
if (match(FalseVal, m_UMax(m_Specific(CmpLHS), m_APInt(C2))) &&
|
2017-10-19 17:36:18 +02:00
|
|
|
C1->ugt(*C2) && Pred == CmpInst::ICMP_UGT)
|
[ValueTracking] recognize variations of 'clamp' to improve codegen (PR31693)
By enhancing value tracking, we allow an existing min/max canonicalization to
kick in and improve codegen for several targets that have min/max instructions.
Unfortunately, recognizing min/max in value tracking may cause us to hit
a hack in InstCombiner::visitICmpInst() more often:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/109340.html
...but I'm hoping we can remove that soon.
Correctness proofs based on Alive:
Name: smaxmin
Pre: C1 < C2
%cmp2 = icmp slt i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp slt i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %min
=>
%cmp2 = icmp slt i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp sgt i8 %min, C1
%r = select i1 %cmp1, i8 %min, i8 C1
Name: sminmax
Pre: C1 > C2
%cmp2 = icmp sgt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp sgt i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %max
=>
%cmp2 = icmp sgt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp slt i8 %max, C1
%r = select i1 %cmp1, i8 %max, i8 C1
----------------------------------------
Optimization: smaxmin
Done: 1
Optimization is correct!
----------------------------------------
Optimization: sminmax
Done: 1
Optimization is correct!
Name: umaxmin
Pre: C1 u< C2
%cmp2 = icmp ult i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp ult i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %min
=>
%cmp2 = icmp ult i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp ugt i8 %min, C1
%r = select i1 %cmp1, i8 %min, i8 C1
Name: uminmax
Pre: C1 u> C2
%cmp2 = icmp ugt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp ugt i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %max
=>
%cmp2 = icmp ugt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp ult i8 %max, C1
%r = select i1 %cmp1, i8 %max, i8 C1
----------------------------------------
Optimization: umaxmin
Done: 1
Optimization is correct!
----------------------------------------
Optimization: uminmax
Done: 1
Optimization is correct!
llvm-svn: 292660
2017-01-20 23:18:47 +01:00
|
|
|
return {SPF_UMIN, SPNB_NA, false};
|
|
|
|
}
|
2017-10-27 22:53:41 +02:00
|
|
|
return {SPF_UNKNOWN, SPNB_NA, false};
|
|
|
|
}
|
|
|
|
|
2018-01-02 21:56:45 +01:00
|
|
|
/// Recognize variations of:
|
|
|
|
/// a < c ? min(a,b) : min(b,c) ==> min(min(a,b),min(b,c))
|
|
|
|
static SelectPatternResult matchMinMaxOfMinMax(CmpInst::Predicate Pred,
|
|
|
|
Value *CmpLHS, Value *CmpRHS,
|
2018-01-24 16:20:37 +01:00
|
|
|
Value *TVal, Value *FVal,
|
|
|
|
unsigned Depth) {
|
2018-01-02 21:56:45 +01:00
|
|
|
// TODO: Allow FP min/max with nnan/nsz.
|
|
|
|
assert(CmpInst::isIntPredicate(Pred) && "Expected integer comparison");
|
|
|
|
|
|
|
|
Value *A, *B;
|
2018-01-24 16:20:37 +01:00
|
|
|
SelectPatternResult L = matchSelectPattern(TVal, A, B, nullptr, Depth + 1);
|
2018-01-02 21:56:45 +01:00
|
|
|
if (!SelectPatternResult::isMinOrMax(L.Flavor))
|
|
|
|
return {SPF_UNKNOWN, SPNB_NA, false};
|
|
|
|
|
|
|
|
Value *C, *D;
|
2018-01-24 16:20:37 +01:00
|
|
|
SelectPatternResult R = matchSelectPattern(FVal, C, D, nullptr, Depth + 1);
|
2018-01-02 21:56:45 +01:00
|
|
|
if (L.Flavor != R.Flavor)
|
|
|
|
return {SPF_UNKNOWN, SPNB_NA, false};
|
|
|
|
|
[ValueTracking] recognize min/max-of-min/max with notted ops (PR35875)
This was originally planned as the fix for:
https://bugs.llvm.org/show_bug.cgi?id=35834
...but simpler transforms handled that case, so I implemented a
lesser solution. It turns out we need to handle the case with 'not'
ops too because the real code example that we are trying to solve:
https://bugs.llvm.org/show_bug.cgi?id=35875
...has extra uses of the intermediate values, so we can't rely on
smaller canonicalizations to get us to the goal.
As with rL321672, I've tried to show every possibility in the
codegen tests because that's the simplest way to prove we're doing
the right thing in the wide variety of permutations of this pattern.
We can also show an InstCombine win because we added a fold for
this case in:
rL321998 / D41603
An Alive proof for one variant of the pattern to show that the
InstCombine and codegen results are correct:
https://rise4fun.com/Alive/vd1
Name: min3_nots
%nx = xor i8 %x, -1
%ny = xor i8 %y, -1
%nz = xor i8 %z, -1
%cmpxz = icmp slt i8 %nx, %nz
%minxz = select i1 %cmpxz, i8 %nx, i8 %nz
%cmpyz = icmp slt i8 %ny, %nz
%minyz = select i1 %cmpyz, i8 %ny, i8 %nz
%cmpyx = icmp slt i8 %y, %x
%r = select i1 %cmpyx, i8 %minxz, i8 %minyz
=>
%cmpxyz = icmp slt i8 %minxz, %ny
%r = select i1 %cmpxyz, i8 %minxz, i8 %ny
Name: min3_nots_alt
%nx = xor i8 %x, -1
%ny = xor i8 %y, -1
%nz = xor i8 %z, -1
%cmpxz = icmp slt i8 %nx, %nz
%minxz = select i1 %cmpxz, i8 %nx, i8 %nz
%cmpyz = icmp slt i8 %ny, %nz
%minyz = select i1 %cmpyz, i8 %ny, i8 %nz
%cmpyx = icmp slt i8 %y, %x
%r = select i1 %cmpyx, i8 %minxz, i8 %minyz
=>
%xz = icmp sgt i8 %x, %z
%maxxz = select i1 %xz, i8 %x, i8 %z
%xyz = icmp sgt i8 %maxxz, %y
%maxxyz = select i1 %xyz, i8 %maxxz, i8 %y
%r = xor i8 %maxxyz, -1
llvm-svn: 322283
2018-01-11 16:13:47 +01:00
|
|
|
// We have something like: x Pred y ? min(a, b) : min(c, d).
|
|
|
|
// Try to match the compare to the min/max operations of the select operands.
|
|
|
|
// First, make sure we have the right compare predicate.
|
2018-01-02 21:56:45 +01:00
|
|
|
switch (L.Flavor) {
|
|
|
|
case SPF_SMIN:
|
|
|
|
if (Pred == ICmpInst::ICMP_SGT || Pred == ICmpInst::ICMP_SGE) {
|
|
|
|
Pred = ICmpInst::getSwappedPredicate(Pred);
|
|
|
|
std::swap(CmpLHS, CmpRHS);
|
|
|
|
}
|
|
|
|
if (Pred == ICmpInst::ICMP_SLT || Pred == ICmpInst::ICMP_SLE)
|
|
|
|
break;
|
|
|
|
return {SPF_UNKNOWN, SPNB_NA, false};
|
|
|
|
case SPF_SMAX:
|
|
|
|
if (Pred == ICmpInst::ICMP_SLT || Pred == ICmpInst::ICMP_SLE) {
|
|
|
|
Pred = ICmpInst::getSwappedPredicate(Pred);
|
|
|
|
std::swap(CmpLHS, CmpRHS);
|
|
|
|
}
|
|
|
|
if (Pred == ICmpInst::ICMP_SGT || Pred == ICmpInst::ICMP_SGE)
|
|
|
|
break;
|
|
|
|
return {SPF_UNKNOWN, SPNB_NA, false};
|
|
|
|
case SPF_UMIN:
|
|
|
|
if (Pred == ICmpInst::ICMP_UGT || Pred == ICmpInst::ICMP_UGE) {
|
|
|
|
Pred = ICmpInst::getSwappedPredicate(Pred);
|
|
|
|
std::swap(CmpLHS, CmpRHS);
|
|
|
|
}
|
|
|
|
if (Pred == ICmpInst::ICMP_ULT || Pred == ICmpInst::ICMP_ULE)
|
|
|
|
break;
|
|
|
|
return {SPF_UNKNOWN, SPNB_NA, false};
|
|
|
|
case SPF_UMAX:
|
|
|
|
if (Pred == ICmpInst::ICMP_ULT || Pred == ICmpInst::ICMP_ULE) {
|
|
|
|
Pred = ICmpInst::getSwappedPredicate(Pred);
|
|
|
|
std::swap(CmpLHS, CmpRHS);
|
|
|
|
}
|
|
|
|
if (Pred == ICmpInst::ICMP_UGT || Pred == ICmpInst::ICMP_UGE)
|
|
|
|
break;
|
|
|
|
return {SPF_UNKNOWN, SPNB_NA, false};
|
|
|
|
default:
|
2018-01-08 19:31:13 +01:00
|
|
|
return {SPF_UNKNOWN, SPNB_NA, false};
|
2018-01-02 21:56:45 +01:00
|
|
|
}
|
|
|
|
|
[ValueTracking] recognize min/max-of-min/max with notted ops (PR35875)
This was originally planned as the fix for:
https://bugs.llvm.org/show_bug.cgi?id=35834
...but simpler transforms handled that case, so I implemented a
lesser solution. It turns out we need to handle the case with 'not'
ops too because the real code example that we are trying to solve:
https://bugs.llvm.org/show_bug.cgi?id=35875
...has extra uses of the intermediate values, so we can't rely on
smaller canonicalizations to get us to the goal.
As with rL321672, I've tried to show every possibility in the
codegen tests because that's the simplest way to prove we're doing
the right thing in the wide variety of permutations of this pattern.
We can also show an InstCombine win because we added a fold for
this case in:
rL321998 / D41603
An Alive proof for one variant of the pattern to show that the
InstCombine and codegen results are correct:
https://rise4fun.com/Alive/vd1
Name: min3_nots
%nx = xor i8 %x, -1
%ny = xor i8 %y, -1
%nz = xor i8 %z, -1
%cmpxz = icmp slt i8 %nx, %nz
%minxz = select i1 %cmpxz, i8 %nx, i8 %nz
%cmpyz = icmp slt i8 %ny, %nz
%minyz = select i1 %cmpyz, i8 %ny, i8 %nz
%cmpyx = icmp slt i8 %y, %x
%r = select i1 %cmpyx, i8 %minxz, i8 %minyz
=>
%cmpxyz = icmp slt i8 %minxz, %ny
%r = select i1 %cmpxyz, i8 %minxz, i8 %ny
Name: min3_nots_alt
%nx = xor i8 %x, -1
%ny = xor i8 %y, -1
%nz = xor i8 %z, -1
%cmpxz = icmp slt i8 %nx, %nz
%minxz = select i1 %cmpxz, i8 %nx, i8 %nz
%cmpyz = icmp slt i8 %ny, %nz
%minyz = select i1 %cmpyz, i8 %ny, i8 %nz
%cmpyx = icmp slt i8 %y, %x
%r = select i1 %cmpyx, i8 %minxz, i8 %minyz
=>
%xz = icmp sgt i8 %x, %z
%maxxz = select i1 %xz, i8 %x, i8 %z
%xyz = icmp sgt i8 %maxxz, %y
%maxxyz = select i1 %xyz, i8 %maxxz, i8 %y
%r = xor i8 %maxxyz, -1
llvm-svn: 322283
2018-01-11 16:13:47 +01:00
|
|
|
// If there is a common operand in the already matched min/max and the other
|
|
|
|
// min/max operands match the compare operands (either directly or inverted),
|
|
|
|
// then this is min/max of the same flavor.
|
2018-01-02 21:56:45 +01:00
|
|
|
|
[ValueTracking] recognize min/max-of-min/max with notted ops (PR35875)
This was originally planned as the fix for:
https://bugs.llvm.org/show_bug.cgi?id=35834
...but simpler transforms handled that case, so I implemented a
lesser solution. It turns out we need to handle the case with 'not'
ops too because the real code example that we are trying to solve:
https://bugs.llvm.org/show_bug.cgi?id=35875
...has extra uses of the intermediate values, so we can't rely on
smaller canonicalizations to get us to the goal.
As with rL321672, I've tried to show every possibility in the
codegen tests because that's the simplest way to prove we're doing
the right thing in the wide variety of permutations of this pattern.
We can also show an InstCombine win because we added a fold for
this case in:
rL321998 / D41603
An Alive proof for one variant of the pattern to show that the
InstCombine and codegen results are correct:
https://rise4fun.com/Alive/vd1
Name: min3_nots
%nx = xor i8 %x, -1
%ny = xor i8 %y, -1
%nz = xor i8 %z, -1
%cmpxz = icmp slt i8 %nx, %nz
%minxz = select i1 %cmpxz, i8 %nx, i8 %nz
%cmpyz = icmp slt i8 %ny, %nz
%minyz = select i1 %cmpyz, i8 %ny, i8 %nz
%cmpyx = icmp slt i8 %y, %x
%r = select i1 %cmpyx, i8 %minxz, i8 %minyz
=>
%cmpxyz = icmp slt i8 %minxz, %ny
%r = select i1 %cmpxyz, i8 %minxz, i8 %ny
Name: min3_nots_alt
%nx = xor i8 %x, -1
%ny = xor i8 %y, -1
%nz = xor i8 %z, -1
%cmpxz = icmp slt i8 %nx, %nz
%minxz = select i1 %cmpxz, i8 %nx, i8 %nz
%cmpyz = icmp slt i8 %ny, %nz
%minyz = select i1 %cmpyz, i8 %ny, i8 %nz
%cmpyx = icmp slt i8 %y, %x
%r = select i1 %cmpyx, i8 %minxz, i8 %minyz
=>
%xz = icmp sgt i8 %x, %z
%maxxz = select i1 %xz, i8 %x, i8 %z
%xyz = icmp sgt i8 %maxxz, %y
%maxxyz = select i1 %xyz, i8 %maxxz, i8 %y
%r = xor i8 %maxxyz, -1
llvm-svn: 322283
2018-01-11 16:13:47 +01:00
|
|
|
// a pred c ? m(a, b) : m(c, b) --> m(m(a, b), m(c, b))
|
|
|
|
// ~c pred ~a ? m(a, b) : m(c, b) --> m(m(a, b), m(c, b))
|
|
|
|
if (D == B) {
|
|
|
|
if ((CmpLHS == A && CmpRHS == C) || (match(C, m_Not(m_Specific(CmpLHS))) &&
|
|
|
|
match(A, m_Not(m_Specific(CmpRHS)))))
|
|
|
|
return {L.Flavor, SPNB_NA, false};
|
|
|
|
}
|
2018-01-02 21:56:45 +01:00
|
|
|
// a pred d ? m(a, b) : m(b, d) --> m(m(a, b), m(b, d))
|
[ValueTracking] recognize min/max-of-min/max with notted ops (PR35875)
This was originally planned as the fix for:
https://bugs.llvm.org/show_bug.cgi?id=35834
...but simpler transforms handled that case, so I implemented a
lesser solution. It turns out we need to handle the case with 'not'
ops too because the real code example that we are trying to solve:
https://bugs.llvm.org/show_bug.cgi?id=35875
...has extra uses of the intermediate values, so we can't rely on
smaller canonicalizations to get us to the goal.
As with rL321672, I've tried to show every possibility in the
codegen tests because that's the simplest way to prove we're doing
the right thing in the wide variety of permutations of this pattern.
We can also show an InstCombine win because we added a fold for
this case in:
rL321998 / D41603
An Alive proof for one variant of the pattern to show that the
InstCombine and codegen results are correct:
https://rise4fun.com/Alive/vd1
Name: min3_nots
%nx = xor i8 %x, -1
%ny = xor i8 %y, -1
%nz = xor i8 %z, -1
%cmpxz = icmp slt i8 %nx, %nz
%minxz = select i1 %cmpxz, i8 %nx, i8 %nz
%cmpyz = icmp slt i8 %ny, %nz
%minyz = select i1 %cmpyz, i8 %ny, i8 %nz
%cmpyx = icmp slt i8 %y, %x
%r = select i1 %cmpyx, i8 %minxz, i8 %minyz
=>
%cmpxyz = icmp slt i8 %minxz, %ny
%r = select i1 %cmpxyz, i8 %minxz, i8 %ny
Name: min3_nots_alt
%nx = xor i8 %x, -1
%ny = xor i8 %y, -1
%nz = xor i8 %z, -1
%cmpxz = icmp slt i8 %nx, %nz
%minxz = select i1 %cmpxz, i8 %nx, i8 %nz
%cmpyz = icmp slt i8 %ny, %nz
%minyz = select i1 %cmpyz, i8 %ny, i8 %nz
%cmpyx = icmp slt i8 %y, %x
%r = select i1 %cmpyx, i8 %minxz, i8 %minyz
=>
%xz = icmp sgt i8 %x, %z
%maxxz = select i1 %xz, i8 %x, i8 %z
%xyz = icmp sgt i8 %maxxz, %y
%maxxyz = select i1 %xyz, i8 %maxxz, i8 %y
%r = xor i8 %maxxyz, -1
llvm-svn: 322283
2018-01-11 16:13:47 +01:00
|
|
|
// ~d pred ~a ? m(a, b) : m(b, d) --> m(m(a, b), m(b, d))
|
|
|
|
if (C == B) {
|
|
|
|
if ((CmpLHS == A && CmpRHS == D) || (match(D, m_Not(m_Specific(CmpLHS))) &&
|
|
|
|
match(A, m_Not(m_Specific(CmpRHS)))))
|
|
|
|
return {L.Flavor, SPNB_NA, false};
|
|
|
|
}
|
2018-01-02 21:56:45 +01:00
|
|
|
// b pred c ? m(a, b) : m(c, a) --> m(m(a, b), m(c, a))
|
[ValueTracking] recognize min/max-of-min/max with notted ops (PR35875)
This was originally planned as the fix for:
https://bugs.llvm.org/show_bug.cgi?id=35834
...but simpler transforms handled that case, so I implemented a
lesser solution. It turns out we need to handle the case with 'not'
ops too because the real code example that we are trying to solve:
https://bugs.llvm.org/show_bug.cgi?id=35875
...has extra uses of the intermediate values, so we can't rely on
smaller canonicalizations to get us to the goal.
As with rL321672, I've tried to show every possibility in the
codegen tests because that's the simplest way to prove we're doing
the right thing in the wide variety of permutations of this pattern.
We can also show an InstCombine win because we added a fold for
this case in:
rL321998 / D41603
An Alive proof for one variant of the pattern to show that the
InstCombine and codegen results are correct:
https://rise4fun.com/Alive/vd1
Name: min3_nots
%nx = xor i8 %x, -1
%ny = xor i8 %y, -1
%nz = xor i8 %z, -1
%cmpxz = icmp slt i8 %nx, %nz
%minxz = select i1 %cmpxz, i8 %nx, i8 %nz
%cmpyz = icmp slt i8 %ny, %nz
%minyz = select i1 %cmpyz, i8 %ny, i8 %nz
%cmpyx = icmp slt i8 %y, %x
%r = select i1 %cmpyx, i8 %minxz, i8 %minyz
=>
%cmpxyz = icmp slt i8 %minxz, %ny
%r = select i1 %cmpxyz, i8 %minxz, i8 %ny
Name: min3_nots_alt
%nx = xor i8 %x, -1
%ny = xor i8 %y, -1
%nz = xor i8 %z, -1
%cmpxz = icmp slt i8 %nx, %nz
%minxz = select i1 %cmpxz, i8 %nx, i8 %nz
%cmpyz = icmp slt i8 %ny, %nz
%minyz = select i1 %cmpyz, i8 %ny, i8 %nz
%cmpyx = icmp slt i8 %y, %x
%r = select i1 %cmpyx, i8 %minxz, i8 %minyz
=>
%xz = icmp sgt i8 %x, %z
%maxxz = select i1 %xz, i8 %x, i8 %z
%xyz = icmp sgt i8 %maxxz, %y
%maxxyz = select i1 %xyz, i8 %maxxz, i8 %y
%r = xor i8 %maxxyz, -1
llvm-svn: 322283
2018-01-11 16:13:47 +01:00
|
|
|
// ~c pred ~b ? m(a, b) : m(c, a) --> m(m(a, b), m(c, a))
|
|
|
|
if (D == A) {
|
|
|
|
if ((CmpLHS == B && CmpRHS == C) || (match(C, m_Not(m_Specific(CmpLHS))) &&
|
|
|
|
match(B, m_Not(m_Specific(CmpRHS)))))
|
|
|
|
return {L.Flavor, SPNB_NA, false};
|
|
|
|
}
|
2018-01-02 21:56:45 +01:00
|
|
|
// b pred d ? m(a, b) : m(a, d) --> m(m(a, b), m(a, d))
|
[ValueTracking] recognize min/max-of-min/max with notted ops (PR35875)
This was originally planned as the fix for:
https://bugs.llvm.org/show_bug.cgi?id=35834
...but simpler transforms handled that case, so I implemented a
lesser solution. It turns out we need to handle the case with 'not'
ops too because the real code example that we are trying to solve:
https://bugs.llvm.org/show_bug.cgi?id=35875
...has extra uses of the intermediate values, so we can't rely on
smaller canonicalizations to get us to the goal.
As with rL321672, I've tried to show every possibility in the
codegen tests because that's the simplest way to prove we're doing
the right thing in the wide variety of permutations of this pattern.
We can also show an InstCombine win because we added a fold for
this case in:
rL321998 / D41603
An Alive proof for one variant of the pattern to show that the
InstCombine and codegen results are correct:
https://rise4fun.com/Alive/vd1
Name: min3_nots
%nx = xor i8 %x, -1
%ny = xor i8 %y, -1
%nz = xor i8 %z, -1
%cmpxz = icmp slt i8 %nx, %nz
%minxz = select i1 %cmpxz, i8 %nx, i8 %nz
%cmpyz = icmp slt i8 %ny, %nz
%minyz = select i1 %cmpyz, i8 %ny, i8 %nz
%cmpyx = icmp slt i8 %y, %x
%r = select i1 %cmpyx, i8 %minxz, i8 %minyz
=>
%cmpxyz = icmp slt i8 %minxz, %ny
%r = select i1 %cmpxyz, i8 %minxz, i8 %ny
Name: min3_nots_alt
%nx = xor i8 %x, -1
%ny = xor i8 %y, -1
%nz = xor i8 %z, -1
%cmpxz = icmp slt i8 %nx, %nz
%minxz = select i1 %cmpxz, i8 %nx, i8 %nz
%cmpyz = icmp slt i8 %ny, %nz
%minyz = select i1 %cmpyz, i8 %ny, i8 %nz
%cmpyx = icmp slt i8 %y, %x
%r = select i1 %cmpyx, i8 %minxz, i8 %minyz
=>
%xz = icmp sgt i8 %x, %z
%maxxz = select i1 %xz, i8 %x, i8 %z
%xyz = icmp sgt i8 %maxxz, %y
%maxxyz = select i1 %xyz, i8 %maxxz, i8 %y
%r = xor i8 %maxxyz, -1
llvm-svn: 322283
2018-01-11 16:13:47 +01:00
|
|
|
// ~d pred ~b ? m(a, b) : m(a, d) --> m(m(a, b), m(a, d))
|
|
|
|
if (C == A) {
|
|
|
|
if ((CmpLHS == B && CmpRHS == D) || (match(D, m_Not(m_Specific(CmpLHS))) &&
|
|
|
|
match(B, m_Not(m_Specific(CmpRHS)))))
|
|
|
|
return {L.Flavor, SPNB_NA, false};
|
|
|
|
}
|
2018-01-02 21:56:45 +01:00
|
|
|
|
|
|
|
return {SPF_UNKNOWN, SPNB_NA, false};
|
|
|
|
}
|
|
|
|
|
2017-10-27 22:53:41 +02:00
|
|
|
/// Match non-obvious integer minimum and maximum sequences.
|
|
|
|
static SelectPatternResult matchMinMax(CmpInst::Predicate Pred,
|
|
|
|
Value *CmpLHS, Value *CmpRHS,
|
|
|
|
Value *TrueVal, Value *FalseVal,
|
2018-01-24 16:20:37 +01:00
|
|
|
Value *&LHS, Value *&RHS,
|
|
|
|
unsigned Depth) {
|
2017-10-27 22:53:41 +02:00
|
|
|
// Assume success. If there's no match, callers should not use these anyway.
|
|
|
|
LHS = TrueVal;
|
|
|
|
RHS = FalseVal;
|
|
|
|
|
|
|
|
SelectPatternResult SPR = matchClamp(Pred, CmpLHS, CmpRHS, TrueVal, FalseVal);
|
|
|
|
if (SPR.Flavor != SelectPatternFlavor::SPF_UNKNOWN)
|
|
|
|
return SPR;
|
[ValueTracking] recognize variations of 'clamp' to improve codegen (PR31693)
By enhancing value tracking, we allow an existing min/max canonicalization to
kick in and improve codegen for several targets that have min/max instructions.
Unfortunately, recognizing min/max in value tracking may cause us to hit
a hack in InstCombiner::visitICmpInst() more often:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/109340.html
...but I'm hoping we can remove that soon.
Correctness proofs based on Alive:
Name: smaxmin
Pre: C1 < C2
%cmp2 = icmp slt i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp slt i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %min
=>
%cmp2 = icmp slt i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp sgt i8 %min, C1
%r = select i1 %cmp1, i8 %min, i8 C1
Name: sminmax
Pre: C1 > C2
%cmp2 = icmp sgt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp sgt i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %max
=>
%cmp2 = icmp sgt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp slt i8 %max, C1
%r = select i1 %cmp1, i8 %max, i8 C1
----------------------------------------
Optimization: smaxmin
Done: 1
Optimization is correct!
----------------------------------------
Optimization: sminmax
Done: 1
Optimization is correct!
Name: umaxmin
Pre: C1 u< C2
%cmp2 = icmp ult i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp ult i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %min
=>
%cmp2 = icmp ult i8 %x, C2
%min = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp ugt i8 %min, C1
%r = select i1 %cmp1, i8 %min, i8 C1
Name: uminmax
Pre: C1 u> C2
%cmp2 = icmp ugt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp3 = icmp ugt i8 %x, C1
%r = select i1 %cmp3, i8 C1, i8 %max
=>
%cmp2 = icmp ugt i8 %x, C2
%max = select i1 %cmp2, i8 %x, i8 C2
%cmp1 = icmp ult i8 %max, C1
%r = select i1 %cmp1, i8 %max, i8 C1
----------------------------------------
Optimization: umaxmin
Done: 1
Optimization is correct!
----------------------------------------
Optimization: uminmax
Done: 1
Optimization is correct!
llvm-svn: 292660
2017-01-20 23:18:47 +01:00
|
|
|
|
2018-01-24 16:20:37 +01:00
|
|
|
SPR = matchMinMaxOfMinMax(Pred, CmpLHS, CmpRHS, TrueVal, FalseVal, Depth);
|
2018-01-02 21:56:45 +01:00
|
|
|
if (SPR.Flavor != SelectPatternFlavor::SPF_UNKNOWN)
|
|
|
|
return SPR;
|
2018-07-30 21:41:25 +02:00
|
|
|
|
2017-10-19 17:36:18 +02:00
|
|
|
if (Pred != CmpInst::ICMP_SGT && Pred != CmpInst::ICMP_SLT)
|
2016-11-13 20:30:19 +01:00
|
|
|
return {SPF_UNKNOWN, SPNB_NA, false};
|
|
|
|
|
2016-11-13 21:04:52 +01:00
|
|
|
// Z = X -nsw Y
|
|
|
|
// (X >s Y) ? 0 : Z ==> (Z >s 0) ? 0 : Z ==> SMIN(Z, 0)
|
|
|
|
// (X <s Y) ? 0 : Z ==> (Z <s 0) ? 0 : Z ==> SMAX(Z, 0)
|
|
|
|
if (match(TrueVal, m_Zero()) &&
|
2017-01-21 18:51:25 +01:00
|
|
|
match(FalseVal, m_NSWSub(m_Specific(CmpLHS), m_Specific(CmpRHS))))
|
2017-10-19 17:36:18 +02:00
|
|
|
return {Pred == CmpInst::ICMP_SGT ? SPF_SMIN : SPF_SMAX, SPNB_NA, false};
|
2016-11-13 21:04:52 +01:00
|
|
|
|
|
|
|
// Z = X -nsw Y
|
|
|
|
// (X >s Y) ? Z : 0 ==> (Z >s 0) ? Z : 0 ==> SMAX(Z, 0)
|
|
|
|
// (X <s Y) ? Z : 0 ==> (Z <s 0) ? Z : 0 ==> SMIN(Z, 0)
|
|
|
|
if (match(FalseVal, m_Zero()) &&
|
2017-01-21 18:51:25 +01:00
|
|
|
match(TrueVal, m_NSWSub(m_Specific(CmpLHS), m_Specific(CmpRHS))))
|
2017-10-19 17:36:18 +02:00
|
|
|
return {Pred == CmpInst::ICMP_SGT ? SPF_SMAX : SPF_SMIN, SPNB_NA, false};
|
2016-11-13 21:04:52 +01:00
|
|
|
|
2017-10-27 22:53:41 +02:00
|
|
|
const APInt *C1;
|
2016-11-13 20:30:19 +01:00
|
|
|
if (!match(CmpRHS, m_APInt(C1)))
|
|
|
|
return {SPF_UNKNOWN, SPNB_NA, false};
|
|
|
|
|
|
|
|
// An unsigned min/max can be written with a signed compare.
|
|
|
|
const APInt *C2;
|
|
|
|
if ((CmpLHS == TrueVal && match(FalseVal, m_APInt(C2))) ||
|
|
|
|
(CmpLHS == FalseVal && match(TrueVal, m_APInt(C2)))) {
|
|
|
|
// Is the sign bit set?
|
|
|
|
// (X <s 0) ? X : MAXVAL ==> (X >u MAXVAL) ? X : MAXVAL ==> UMAX
|
|
|
|
// (X <s 0) ? MAXVAL : X ==> (X >u MAXVAL) ? MAXVAL : X ==> UMIN
|
2017-11-08 20:38:45 +01:00
|
|
|
if (Pred == CmpInst::ICMP_SLT && C1->isNullValue() &&
|
|
|
|
C2->isMaxSignedValue())
|
2016-11-13 20:30:19 +01:00
|
|
|
return {CmpLHS == TrueVal ? SPF_UMAX : SPF_UMIN, SPNB_NA, false};
|
|
|
|
|
|
|
|
// Is the sign bit clear?
|
|
|
|
// (X >s -1) ? MINVAL : X ==> (X <u MINVAL) ? MINVAL : X ==> UMAX
|
|
|
|
// (X >s -1) ? X : MINVAL ==> (X <u MINVAL) ? X : MINVAL ==> UMIN
|
2017-10-19 17:36:18 +02:00
|
|
|
if (Pred == CmpInst::ICMP_SGT && C1->isAllOnesValue() &&
|
|
|
|
C2->isMinSignedValue())
|
2016-11-13 20:30:19 +01:00
|
|
|
return {CmpLHS == FalseVal ? SPF_UMAX : SPF_UMIN, SPNB_NA, false};
|
|
|
|
}
|
|
|
|
|
|
|
|
// Look through 'not' ops to find disguised signed min/max.
|
|
|
|
// (X >s C) ? ~X : ~C ==> (~X <s ~C) ? ~X : ~C ==> SMIN(~X, ~C)
|
|
|
|
// (X <s C) ? ~X : ~C ==> (~X >s ~C) ? ~X : ~C ==> SMAX(~X, ~C)
|
|
|
|
if (match(TrueVal, m_Not(m_Specific(CmpLHS))) &&
|
2017-01-21 18:51:25 +01:00
|
|
|
match(FalseVal, m_APInt(C2)) && ~(*C1) == *C2)
|
2017-10-19 17:36:18 +02:00
|
|
|
return {Pred == CmpInst::ICMP_SGT ? SPF_SMIN : SPF_SMAX, SPNB_NA, false};
|
2016-11-13 20:30:19 +01:00
|
|
|
|
|
|
|
// (X >s C) ? ~C : ~X ==> (~X <s ~C) ? ~C : ~X ==> SMAX(~C, ~X)
|
|
|
|
// (X <s C) ? ~C : ~X ==> (~X >s ~C) ? ~C : ~X ==> SMIN(~C, ~X)
|
|
|
|
if (match(FalseVal, m_Not(m_Specific(CmpLHS))) &&
|
2017-01-21 18:51:25 +01:00
|
|
|
match(TrueVal, m_APInt(C2)) && ~(*C1) == *C2)
|
2017-10-19 17:36:18 +02:00
|
|
|
return {Pred == CmpInst::ICMP_SGT ? SPF_SMAX : SPF_SMIN, SPNB_NA, false};
|
2016-11-13 20:30:19 +01:00
|
|
|
|
|
|
|
return {SPF_UNKNOWN, SPNB_NA, false};
|
|
|
|
}
|
|
|
|
|
2018-07-21 14:27:54 +02:00
|
|
|
bool llvm::isKnownNegation(const Value *X, const Value *Y, bool NeedNSW) {
|
2018-07-12 05:06:04 +02:00
|
|
|
assert(X && Y && "Invalid operand");
|
|
|
|
|
2018-07-21 14:27:54 +02:00
|
|
|
// X = sub (0, Y) || X = sub nsw (0, Y)
|
|
|
|
if ((!NeedNSW && match(X, m_Sub(m_ZeroInt(), m_Specific(Y)))) ||
|
|
|
|
(NeedNSW && match(X, m_NSWSub(m_ZeroInt(), m_Specific(Y)))))
|
2018-07-12 05:06:04 +02:00
|
|
|
return true;
|
|
|
|
|
2018-07-21 14:27:54 +02:00
|
|
|
// Y = sub (0, X) || Y = sub nsw (0, X)
|
|
|
|
if ((!NeedNSW && match(Y, m_Sub(m_ZeroInt(), m_Specific(X)))) ||
|
|
|
|
(NeedNSW && match(Y, m_NSWSub(m_ZeroInt(), m_Specific(X)))))
|
2018-07-12 05:06:04 +02:00
|
|
|
return true;
|
|
|
|
|
2018-07-21 14:27:54 +02:00
|
|
|
// X = sub (A, B), Y = sub (B, A) || X = sub nsw (A, B), Y = sub nsw (B, A)
|
2018-07-12 05:06:04 +02:00
|
|
|
Value *A, *B;
|
2018-07-21 14:27:54 +02:00
|
|
|
return (!NeedNSW && (match(X, m_Sub(m_Value(A), m_Value(B))) &&
|
|
|
|
match(Y, m_Sub(m_Specific(B), m_Specific(A))))) ||
|
|
|
|
(NeedNSW && (match(X, m_NSWSub(m_Value(A), m_Value(B))) &&
|
|
|
|
match(Y, m_NSWSub(m_Specific(B), m_Specific(A)))));
|
2018-07-12 05:06:04 +02:00
|
|
|
}
|
|
|
|
|
2015-08-11 11:12:57 +02:00
|
|
|
static SelectPatternResult matchSelectPattern(CmpInst::Predicate Pred,
|
|
|
|
FastMathFlags FMF,
|
2015-05-15 18:04:50 +02:00
|
|
|
Value *CmpLHS, Value *CmpRHS,
|
|
|
|
Value *TrueVal, Value *FalseVal,
|
2018-01-24 16:20:37 +01:00
|
|
|
Value *&LHS, Value *&RHS,
|
|
|
|
unsigned Depth) {
|
2018-11-04 15:28:48 +01:00
|
|
|
if (CmpInst::isFPPredicate(Pred)) {
|
|
|
|
// IEEE-754 ignores the sign of 0.0 in comparisons. So if the select has one
|
|
|
|
// 0.0 operand, set the compare's 0.0 operands to that same value for the
|
|
|
|
// purpose of identifying min/max. Disregard vector constants with undefined
|
|
|
|
// elements because those can not be back-propagated for analysis.
|
|
|
|
Value *OutputZeroVal = nullptr;
|
|
|
|
if (match(TrueVal, m_AnyZeroFP()) && !match(FalseVal, m_AnyZeroFP()) &&
|
|
|
|
!cast<Constant>(TrueVal)->containsUndefElement())
|
|
|
|
OutputZeroVal = TrueVal;
|
|
|
|
else if (match(FalseVal, m_AnyZeroFP()) && !match(TrueVal, m_AnyZeroFP()) &&
|
|
|
|
!cast<Constant>(FalseVal)->containsUndefElement())
|
|
|
|
OutputZeroVal = FalseVal;
|
|
|
|
|
|
|
|
if (OutputZeroVal) {
|
|
|
|
if (match(CmpLHS, m_AnyZeroFP()))
|
|
|
|
CmpLHS = OutputZeroVal;
|
|
|
|
if (match(CmpRHS, m_AnyZeroFP()))
|
|
|
|
CmpRHS = OutputZeroVal;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-05-11 16:42:20 +02:00
|
|
|
LHS = CmpLHS;
|
|
|
|
RHS = CmpRHS;
|
|
|
|
|
2017-12-26 16:09:19 +01:00
|
|
|
// Signed zero may return inconsistent results between implementations.
|
|
|
|
// (0.0 <= -0.0) ? 0.0 : -0.0 // Returns 0.0
|
|
|
|
// minNum(0.0, -0.0) // May return -0.0 or 0.0 (IEEE 754-2008 5.3.1)
|
|
|
|
// Therefore, we behave conservatively and only proceed if at least one of the
|
|
|
|
// operands is known to not be zero or if we don't care about signed zero.
|
2015-08-11 11:12:57 +02:00
|
|
|
switch (Pred) {
|
|
|
|
default: break;
|
2017-12-26 16:09:19 +01:00
|
|
|
// FIXME: Include OGT/OLT/UGT/ULT.
|
2015-08-11 11:12:57 +02:00
|
|
|
case CmpInst::FCMP_OGE: case CmpInst::FCMP_OLE:
|
|
|
|
case CmpInst::FCMP_UGE: case CmpInst::FCMP_ULE:
|
|
|
|
if (!FMF.noSignedZeros() && !isKnownNonZero(CmpLHS) &&
|
|
|
|
!isKnownNonZero(CmpRHS))
|
|
|
|
return {SPF_UNKNOWN, SPNB_NA, false};
|
|
|
|
}
|
|
|
|
|
|
|
|
SelectPatternNaNBehavior NaNBehavior = SPNB_NA;
|
|
|
|
bool Ordered = false;
|
|
|
|
|
|
|
|
// When given one NaN and one non-NaN input:
|
|
|
|
// - maxnum/minnum (C99 fmaxf()/fminf()) return the non-NaN input.
|
|
|
|
// - A simple C99 (a < b ? a : b) construction will return 'b' (as the
|
|
|
|
// ordered comparison fails), which could be NaN or non-NaN.
|
|
|
|
// so here we discover exactly what NaN behavior is required/accepted.
|
|
|
|
if (CmpInst::isFPPredicate(Pred)) {
|
|
|
|
bool LHSSafe = isKnownNonNaN(CmpLHS, FMF);
|
|
|
|
bool RHSSafe = isKnownNonNaN(CmpRHS, FMF);
|
|
|
|
|
|
|
|
if (LHSSafe && RHSSafe) {
|
|
|
|
// Both operands are known non-NaN.
|
|
|
|
NaNBehavior = SPNB_RETURNS_ANY;
|
|
|
|
} else if (CmpInst::isOrdered(Pred)) {
|
|
|
|
// An ordered comparison will return false when given a NaN, so it
|
|
|
|
// returns the RHS.
|
|
|
|
Ordered = true;
|
|
|
|
if (LHSSafe)
|
2015-08-12 17:11:43 +02:00
|
|
|
// LHS is non-NaN, so if RHS is NaN then NaN will be returned.
|
2015-08-11 11:12:57 +02:00
|
|
|
NaNBehavior = SPNB_RETURNS_NAN;
|
|
|
|
else if (RHSSafe)
|
|
|
|
NaNBehavior = SPNB_RETURNS_OTHER;
|
|
|
|
else
|
|
|
|
// Completely unsafe.
|
|
|
|
return {SPF_UNKNOWN, SPNB_NA, false};
|
|
|
|
} else {
|
|
|
|
Ordered = false;
|
|
|
|
// An unordered comparison will return true when given a NaN, so it
|
|
|
|
// returns the LHS.
|
|
|
|
if (LHSSafe)
|
2015-08-12 17:11:43 +02:00
|
|
|
// LHS is non-NaN, so if RHS is NaN then non-NaN will be returned.
|
2015-08-11 11:12:57 +02:00
|
|
|
NaNBehavior = SPNB_RETURNS_OTHER;
|
|
|
|
else if (RHSSafe)
|
|
|
|
NaNBehavior = SPNB_RETURNS_NAN;
|
|
|
|
else
|
|
|
|
// Completely unsafe.
|
|
|
|
return {SPF_UNKNOWN, SPNB_NA, false};
|
2015-05-11 16:42:20 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (TrueVal == CmpRHS && FalseVal == CmpLHS) {
|
2015-08-11 11:12:57 +02:00
|
|
|
std::swap(CmpLHS, CmpRHS);
|
|
|
|
Pred = CmpInst::getSwappedPredicate(Pred);
|
|
|
|
if (NaNBehavior == SPNB_RETURNS_NAN)
|
|
|
|
NaNBehavior = SPNB_RETURNS_OTHER;
|
|
|
|
else if (NaNBehavior == SPNB_RETURNS_OTHER)
|
|
|
|
NaNBehavior = SPNB_RETURNS_NAN;
|
|
|
|
Ordered = !Ordered;
|
|
|
|
}
|
|
|
|
|
|
|
|
// ([if]cmp X, Y) ? X : Y
|
|
|
|
if (TrueVal == CmpLHS && FalseVal == CmpRHS) {
|
2015-05-11 16:42:20 +02:00
|
|
|
switch (Pred) {
|
2015-08-11 11:12:57 +02:00
|
|
|
default: return {SPF_UNKNOWN, SPNB_NA, false}; // Equality.
|
2015-05-11 16:42:20 +02:00
|
|
|
case ICmpInst::ICMP_UGT:
|
2015-08-11 11:12:57 +02:00
|
|
|
case ICmpInst::ICMP_UGE: return {SPF_UMAX, SPNB_NA, false};
|
2015-05-11 16:42:20 +02:00
|
|
|
case ICmpInst::ICMP_SGT:
|
2015-08-11 11:12:57 +02:00
|
|
|
case ICmpInst::ICMP_SGE: return {SPF_SMAX, SPNB_NA, false};
|
2015-05-11 16:42:20 +02:00
|
|
|
case ICmpInst::ICMP_ULT:
|
2015-08-11 11:12:57 +02:00
|
|
|
case ICmpInst::ICMP_ULE: return {SPF_UMIN, SPNB_NA, false};
|
2015-05-11 16:42:20 +02:00
|
|
|
case ICmpInst::ICMP_SLT:
|
2015-08-11 11:12:57 +02:00
|
|
|
case ICmpInst::ICMP_SLE: return {SPF_SMIN, SPNB_NA, false};
|
|
|
|
case FCmpInst::FCMP_UGT:
|
|
|
|
case FCmpInst::FCMP_UGE:
|
|
|
|
case FCmpInst::FCMP_OGT:
|
|
|
|
case FCmpInst::FCMP_OGE: return {SPF_FMAXNUM, NaNBehavior, Ordered};
|
|
|
|
case FCmpInst::FCMP_ULT:
|
|
|
|
case FCmpInst::FCMP_ULE:
|
|
|
|
case FCmpInst::FCMP_OLT:
|
|
|
|
case FCmpInst::FCMP_OLE: return {SPF_FMINNUM, NaNBehavior, Ordered};
|
2015-05-11 16:42:20 +02:00
|
|
|
}
|
|
|
|
}
|
2018-07-30 21:41:25 +02:00
|
|
|
|
2018-07-16 04:23:00 +02:00
|
|
|
if (isKnownNegation(TrueVal, FalseVal)) {
|
|
|
|
// Sign-extending LHS does not change its sign, so TrueVal/FalseVal can
|
|
|
|
// match against either LHS or sext(LHS).
|
|
|
|
auto MaybeSExtCmpLHS =
|
|
|
|
m_CombineOr(m_Specific(CmpLHS), m_SExt(m_Specific(CmpLHS)));
|
|
|
|
auto ZeroOrAllOnes = m_CombineOr(m_ZeroInt(), m_AllOnes());
|
|
|
|
auto ZeroOrOne = m_CombineOr(m_ZeroInt(), m_One());
|
|
|
|
if (match(TrueVal, MaybeSExtCmpLHS)) {
|
|
|
|
// Set the return values. If the compare uses the negated value (-X >s 0),
|
|
|
|
// swap the return values because the negated value is always 'RHS'.
|
2018-07-02 16:43:40 +02:00
|
|
|
LHS = TrueVal;
|
|
|
|
RHS = FalseVal;
|
2018-07-16 04:23:00 +02:00
|
|
|
if (match(CmpLHS, m_Neg(m_Specific(FalseVal))))
|
|
|
|
std::swap(LHS, RHS);
|
|
|
|
|
|
|
|
// (X >s 0) ? X : -X or (X >s -1) ? X : -X --> ABS(X)
|
|
|
|
// (-X >s 0) ? -X : X or (-X >s -1) ? -X : X --> ABS(X)
|
|
|
|
if (Pred == ICmpInst::ICMP_SGT && match(CmpRHS, ZeroOrAllOnes))
|
|
|
|
return {SPF_ABS, SPNB_NA, false};
|
|
|
|
|
|
|
|
// (X <s 0) ? X : -X or (X <s 1) ? X : -X --> NABS(X)
|
|
|
|
// (-X <s 0) ? -X : X or (-X <s 1) ? -X : X --> NABS(X)
|
|
|
|
if (Pred == ICmpInst::ICMP_SLT && match(CmpRHS, ZeroOrOne))
|
|
|
|
return {SPF_NABS, SPNB_NA, false};
|
|
|
|
}
|
|
|
|
else if (match(FalseVal, MaybeSExtCmpLHS)) {
|
|
|
|
// Set the return values. If the compare uses the negated value (-X >s 0),
|
|
|
|
// swap the return values because the negated value is always 'RHS'.
|
2018-07-02 16:43:40 +02:00
|
|
|
LHS = FalseVal;
|
|
|
|
RHS = TrueVal;
|
2018-07-16 04:23:00 +02:00
|
|
|
if (match(CmpLHS, m_Neg(m_Specific(TrueVal))))
|
|
|
|
std::swap(LHS, RHS);
|
|
|
|
|
|
|
|
// (X >s 0) ? -X : X or (X >s -1) ? -X : X --> NABS(X)
|
|
|
|
// (-X >s 0) ? X : -X or (-X >s -1) ? X : -X --> NABS(X)
|
|
|
|
if (Pred == ICmpInst::ICMP_SGT && match(CmpRHS, ZeroOrAllOnes))
|
|
|
|
return {SPF_NABS, SPNB_NA, false};
|
|
|
|
|
|
|
|
// (X <s 0) ? -X : X or (X <s 1) ? -X : X --> ABS(X)
|
|
|
|
// (-X <s 0) ? X : -X or (-X <s 1) ? X : -X --> ABS(X)
|
|
|
|
if (Pred == ICmpInst::ICMP_SLT && match(CmpRHS, ZeroOrOne))
|
|
|
|
return {SPF_ABS, SPNB_NA, false};
|
2015-05-11 16:42:20 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[InstCombine] Canonicalize clamp of float types to minmax in fast mode.
Summary:
This commit allows matchSelectPattern to recognize clamp of float
arguments in the presence of FMF the same way as already done for
integers.
This case is a little different though. With integers, given the
min/max pattern is recognized, DAGBuilder starts selecting MIN/MAX
"automatically". That is not the case for float, because for them only
full FMINNAN/FMINNUM/FMAXNAN/FMAXNUM ISD nodes exist and they do care
about NaNs. On the other hand, some backends (e.g. X86) have only
FMIN/FMAX nodes that do not care about NaNS and the former NAN/NUM
nodes are illegal thus selection is not happening. So I decided to do
such kind of transformation in IR (InstCombiner) instead of
complicating the logic in the backend.
Reviewers: spatel, jmolloy, majnemer, efriedma, craig.topper
Reviewed By: efriedma
Subscribers: hiraditya, javed.absar, n.bozhenov, llvm-commits
Patch by Andrei Elovikov <andrei.elovikov@intel.com>
Differential Revision: https://reviews.llvm.org/D33186
llvm-svn: 310054
2017-08-04 14:22:17 +02:00
|
|
|
if (CmpInst::isIntPredicate(Pred))
|
2018-01-24 16:20:37 +01:00
|
|
|
return matchMinMax(Pred, CmpLHS, CmpRHS, TrueVal, FalseVal, LHS, RHS, Depth);
|
[InstCombine] Canonicalize clamp of float types to minmax in fast mode.
Summary:
This commit allows matchSelectPattern to recognize clamp of float
arguments in the presence of FMF the same way as already done for
integers.
This case is a little different though. With integers, given the
min/max pattern is recognized, DAGBuilder starts selecting MIN/MAX
"automatically". That is not the case for float, because for them only
full FMINNAN/FMINNUM/FMAXNAN/FMAXNUM ISD nodes exist and they do care
about NaNs. On the other hand, some backends (e.g. X86) have only
FMIN/FMAX nodes that do not care about NaNS and the former NAN/NUM
nodes are illegal thus selection is not happening. So I decided to do
such kind of transformation in IR (InstCombiner) instead of
complicating the logic in the backend.
Reviewers: spatel, jmolloy, majnemer, efriedma, craig.topper
Reviewed By: efriedma
Subscribers: hiraditya, javed.absar, n.bozhenov, llvm-commits
Patch by Andrei Elovikov <andrei.elovikov@intel.com>
Differential Revision: https://reviews.llvm.org/D33186
llvm-svn: 310054
2017-08-04 14:22:17 +02:00
|
|
|
|
|
|
|
// According to (IEEE 754-2008 5.3.1), minNum(0.0, -0.0) and similar
|
|
|
|
// may return either -0.0 or 0.0, so fcmp/select pair has stricter
|
|
|
|
// semantics than minNum. Be conservative in such case.
|
|
|
|
if (NaNBehavior != SPNB_RETURNS_ANY ||
|
|
|
|
(!FMF.noSignedZeros() && !isKnownNonZero(CmpLHS) &&
|
|
|
|
!isKnownNonZero(CmpRHS)))
|
|
|
|
return {SPF_UNKNOWN, SPNB_NA, false};
|
|
|
|
|
|
|
|
return matchFastFloatClamp(Pred, CmpLHS, CmpRHS, TrueVal, FalseVal, LHS, RHS);
|
2015-05-11 16:42:20 +02:00
|
|
|
}
|
2015-05-15 18:04:50 +02:00
|
|
|
|
2017-10-18 11:28:09 +02:00
|
|
|
/// Helps to match a select pattern in case of a type mismatch.
|
|
|
|
///
|
|
|
|
/// The function processes the case when type of true and false values of a
|
|
|
|
/// select instruction differs from type of the cmp instruction operands because
|
2018-03-02 19:57:02 +01:00
|
|
|
/// of a cast instruction. The function checks if it is legal to move the cast
|
2017-10-18 11:28:09 +02:00
|
|
|
/// operation after "select". If yes, it returns the new second value of
|
|
|
|
/// "select" (with the assumption that cast is moved):
|
|
|
|
/// 1. As operand of cast instruction when both values of "select" are same cast
|
|
|
|
/// instructions.
|
|
|
|
/// 2. As restored constant (by applying reverse cast operation) when the first
|
|
|
|
/// value of the "select" is a cast operation and the second value is a
|
|
|
|
/// constant.
|
|
|
|
/// NOTE: We return only the new second value because the first value could be
|
|
|
|
/// accessed as operand of cast instruction.
|
2015-09-02 19:25:25 +02:00
|
|
|
static Value *lookThroughCast(CmpInst *CmpI, Value *V1, Value *V2,
|
|
|
|
Instruction::CastOps *CastOp) {
|
2017-01-29 17:34:57 +01:00
|
|
|
auto *Cast1 = dyn_cast<CastInst>(V1);
|
|
|
|
if (!Cast1)
|
2015-05-15 18:04:50 +02:00
|
|
|
return nullptr;
|
2017-01-29 17:34:57 +01:00
|
|
|
|
|
|
|
*CastOp = Cast1->getOpcode();
|
|
|
|
Type *SrcTy = Cast1->getSrcTy();
|
|
|
|
if (auto *Cast2 = dyn_cast<CastInst>(V2)) {
|
|
|
|
// If V1 and V2 are both the same cast from the same type, look through V1.
|
|
|
|
if (*CastOp == Cast2->getOpcode() && SrcTy == Cast2->getSrcTy())
|
|
|
|
return Cast2->getOperand(0);
|
2015-09-02 19:25:25 +02:00
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
2017-01-29 17:34:57 +01:00
|
|
|
auto *C = dyn_cast<Constant>(V2);
|
|
|
|
if (!C)
|
|
|
|
return nullptr;
|
2015-08-11 11:12:57 +02:00
|
|
|
|
2017-01-29 17:34:57 +01:00
|
|
|
Constant *CastedTo = nullptr;
|
|
|
|
switch (*CastOp) {
|
|
|
|
case Instruction::ZExt:
|
|
|
|
if (CmpI->isUnsigned())
|
|
|
|
CastedTo = ConstantExpr::getTrunc(C, SrcTy);
|
|
|
|
break;
|
|
|
|
case Instruction::SExt:
|
|
|
|
if (CmpI->isSigned())
|
|
|
|
CastedTo = ConstantExpr::getTrunc(C, SrcTy, true);
|
|
|
|
break;
|
|
|
|
case Instruction::Trunc:
|
2017-10-18 11:28:09 +02:00
|
|
|
Constant *CmpConst;
|
2017-10-18 16:24:50 +02:00
|
|
|
if (match(CmpI->getOperand(1), m_Constant(CmpConst)) &&
|
|
|
|
CmpConst->getType() == SrcTy) {
|
2017-10-18 11:28:09 +02:00
|
|
|
// Here we have the following case:
|
|
|
|
//
|
|
|
|
// %cond = cmp iN %x, CmpConst
|
|
|
|
// %tr = trunc iN %x to iK
|
|
|
|
// %narrowsel = select i1 %cond, iK %t, iK C
|
|
|
|
//
|
|
|
|
// We can always move trunc after select operation:
|
|
|
|
//
|
|
|
|
// %cond = cmp iN %x, CmpConst
|
|
|
|
// %widesel = select i1 %cond, iN %x, iN CmpConst
|
|
|
|
// %tr = trunc iN %widesel to iK
|
|
|
|
//
|
|
|
|
// Note that C could be extended in any way because we don't care about
|
|
|
|
// upper bits after truncation. It can't be abs pattern, because it would
|
|
|
|
// look like:
|
|
|
|
//
|
|
|
|
// select i1 %cond, x, -x.
|
|
|
|
//
|
|
|
|
// So only min/max pattern could be matched. Such match requires widened C
|
|
|
|
// == CmpConst. That is why set widened C = CmpConst, condition trunc
|
|
|
|
// CmpConst == C is checked below.
|
|
|
|
CastedTo = CmpConst;
|
|
|
|
} else {
|
|
|
|
CastedTo = ConstantExpr::getIntegerCast(C, SrcTy, CmpI->isSigned());
|
|
|
|
}
|
2017-01-29 17:34:57 +01:00
|
|
|
break;
|
|
|
|
case Instruction::FPTrunc:
|
|
|
|
CastedTo = ConstantExpr::getFPExtend(C, SrcTy, true);
|
|
|
|
break;
|
|
|
|
case Instruction::FPExt:
|
|
|
|
CastedTo = ConstantExpr::getFPTrunc(C, SrcTy, true);
|
|
|
|
break;
|
|
|
|
case Instruction::FPToUI:
|
|
|
|
CastedTo = ConstantExpr::getUIToFP(C, SrcTy, true);
|
|
|
|
break;
|
|
|
|
case Instruction::FPToSI:
|
|
|
|
CastedTo = ConstantExpr::getSIToFP(C, SrcTy, true);
|
|
|
|
break;
|
|
|
|
case Instruction::UIToFP:
|
|
|
|
CastedTo = ConstantExpr::getFPToUI(C, SrcTy, true);
|
|
|
|
break;
|
|
|
|
case Instruction::SIToFP:
|
|
|
|
CastedTo = ConstantExpr::getFPToSI(C, SrcTy, true);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
2015-08-11 11:12:57 +02:00
|
|
|
|
2016-04-29 20:40:34 +02:00
|
|
|
if (!CastedTo)
|
|
|
|
return nullptr;
|
2015-08-11 11:12:57 +02:00
|
|
|
|
2016-04-29 20:40:34 +02:00
|
|
|
// Make sure the cast doesn't lose any information.
|
2017-01-29 17:34:57 +01:00
|
|
|
Constant *CastedBack =
|
|
|
|
ConstantExpr::getCast(*CastOp, CastedTo, C->getType(), true);
|
2016-04-29 20:40:34 +02:00
|
|
|
if (CastedBack != C)
|
|
|
|
return nullptr;
|
2015-08-11 11:12:57 +02:00
|
|
|
|
2016-04-29 20:40:34 +02:00
|
|
|
return CastedTo;
|
2015-05-15 18:04:50 +02:00
|
|
|
}
|
|
|
|
|
2016-05-23 19:57:54 +02:00
|
|
|
SelectPatternResult llvm::matchSelectPattern(Value *V, Value *&LHS, Value *&RHS,
|
2018-01-24 16:20:37 +01:00
|
|
|
Instruction::CastOps *CastOp,
|
|
|
|
unsigned Depth) {
|
|
|
|
if (Depth >= MaxDepth)
|
|
|
|
return {SPF_UNKNOWN, SPNB_NA, false};
|
|
|
|
|
2015-05-15 18:04:50 +02:00
|
|
|
SelectInst *SI = dyn_cast<SelectInst>(V);
|
2015-08-11 11:12:57 +02:00
|
|
|
if (!SI) return {SPF_UNKNOWN, SPNB_NA, false};
|
2015-05-15 18:04:50 +02:00
|
|
|
|
2015-08-11 11:12:57 +02:00
|
|
|
CmpInst *CmpI = dyn_cast<CmpInst>(SI->getCondition());
|
|
|
|
if (!CmpI) return {SPF_UNKNOWN, SPNB_NA, false};
|
2015-05-15 18:04:50 +02:00
|
|
|
|
2015-08-11 11:12:57 +02:00
|
|
|
CmpInst::Predicate Pred = CmpI->getPredicate();
|
2015-05-15 18:04:50 +02:00
|
|
|
Value *CmpLHS = CmpI->getOperand(0);
|
|
|
|
Value *CmpRHS = CmpI->getOperand(1);
|
|
|
|
Value *TrueVal = SI->getTrueValue();
|
|
|
|
Value *FalseVal = SI->getFalseValue();
|
2015-08-11 11:12:57 +02:00
|
|
|
FastMathFlags FMF;
|
|
|
|
if (isa<FPMathOperator>(CmpI))
|
|
|
|
FMF = CmpI->getFastMathFlags();
|
2015-05-15 18:04:50 +02:00
|
|
|
|
|
|
|
// Bail out early.
|
|
|
|
if (CmpI->isEquality())
|
2015-08-11 11:12:57 +02:00
|
|
|
return {SPF_UNKNOWN, SPNB_NA, false};
|
2015-05-15 18:04:50 +02:00
|
|
|
|
|
|
|
// Deal with type mismatches.
|
|
|
|
if (CastOp && CmpLHS->getType() != TrueVal->getType()) {
|
2017-12-26 16:09:19 +01:00
|
|
|
if (Value *C = lookThroughCast(CmpI, TrueVal, FalseVal, CastOp)) {
|
|
|
|
// If this is a potential fmin/fmax with a cast to integer, then ignore
|
|
|
|
// -0.0 because there is no corresponding integer value.
|
|
|
|
if (*CastOp == Instruction::FPToSI || *CastOp == Instruction::FPToUI)
|
|
|
|
FMF.setNoSignedZeros();
|
2015-08-11 11:12:57 +02:00
|
|
|
return ::matchSelectPattern(Pred, FMF, CmpLHS, CmpRHS,
|
2015-05-15 18:04:50 +02:00
|
|
|
cast<CastInst>(TrueVal)->getOperand(0), C,
|
2018-01-24 16:20:37 +01:00
|
|
|
LHS, RHS, Depth);
|
2017-12-26 16:09:19 +01:00
|
|
|
}
|
|
|
|
if (Value *C = lookThroughCast(CmpI, FalseVal, TrueVal, CastOp)) {
|
|
|
|
// If this is a potential fmin/fmax with a cast to integer, then ignore
|
|
|
|
// -0.0 because there is no corresponding integer value.
|
|
|
|
if (*CastOp == Instruction::FPToSI || *CastOp == Instruction::FPToUI)
|
|
|
|
FMF.setNoSignedZeros();
|
2015-08-11 11:12:57 +02:00
|
|
|
return ::matchSelectPattern(Pred, FMF, CmpLHS, CmpRHS,
|
2015-05-15 18:04:50 +02:00
|
|
|
C, cast<CastInst>(FalseVal)->getOperand(0),
|
2018-01-24 16:20:37 +01:00
|
|
|
LHS, RHS, Depth);
|
2017-12-26 16:09:19 +01:00
|
|
|
}
|
2015-05-15 18:04:50 +02:00
|
|
|
}
|
2015-08-11 11:12:57 +02:00
|
|
|
return ::matchSelectPattern(Pred, FMF, CmpLHS, CmpRHS, TrueVal, FalseVal,
|
2018-01-24 16:20:37 +01:00
|
|
|
LHS, RHS, Depth);
|
2015-05-15 18:04:50 +02:00
|
|
|
}
|
2015-10-24 07:37:35 +02:00
|
|
|
|
2018-03-06 17:57:55 +01:00
|
|
|
CmpInst::Predicate llvm::getMinMaxPred(SelectPatternFlavor SPF, bool Ordered) {
|
|
|
|
if (SPF == SPF_SMIN) return ICmpInst::ICMP_SLT;
|
|
|
|
if (SPF == SPF_UMIN) return ICmpInst::ICMP_ULT;
|
|
|
|
if (SPF == SPF_SMAX) return ICmpInst::ICMP_SGT;
|
|
|
|
if (SPF == SPF_UMAX) return ICmpInst::ICMP_UGT;
|
|
|
|
if (SPF == SPF_FMINNUM)
|
|
|
|
return Ordered ? FCmpInst::FCMP_OLT : FCmpInst::FCMP_ULT;
|
|
|
|
if (SPF == SPF_FMAXNUM)
|
|
|
|
return Ordered ? FCmpInst::FCMP_OGT : FCmpInst::FCMP_UGT;
|
|
|
|
llvm_unreachable("unhandled!");
|
|
|
|
}
|
|
|
|
|
|
|
|
SelectPatternFlavor llvm::getInverseMinMaxFlavor(SelectPatternFlavor SPF) {
|
|
|
|
if (SPF == SPF_SMIN) return SPF_SMAX;
|
|
|
|
if (SPF == SPF_UMIN) return SPF_UMAX;
|
|
|
|
if (SPF == SPF_SMAX) return SPF_SMIN;
|
|
|
|
if (SPF == SPF_UMAX) return SPF_UMIN;
|
|
|
|
llvm_unreachable("unhandled!");
|
|
|
|
}
|
|
|
|
|
|
|
|
CmpInst::Predicate llvm::getInverseMinMaxPred(SelectPatternFlavor SPF) {
|
|
|
|
return getMinMaxPred(getInverseMinMaxFlavor(SPF));
|
|
|
|
}
|
|
|
|
|
2015-11-06 20:00:57 +01:00
|
|
|
/// Return true if "icmp Pred LHS RHS" is always true.
|
2017-07-28 16:39:06 +02:00
|
|
|
static bool isTruePredicate(CmpInst::Predicate Pred, const Value *LHS,
|
|
|
|
const Value *RHS, const DataLayout &DL,
|
|
|
|
unsigned Depth) {
|
2015-11-11 00:56:15 +01:00
|
|
|
assert(!LHS->getType()->isVectorTy() && "TODO: extend to handle vectors!");
|
2015-11-06 20:00:57 +01:00
|
|
|
if (ICmpInst::isTrueWhenEqual(Pred) && LHS == RHS)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
switch (Pred) {
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
|
|
|
|
case CmpInst::ICMP_SLE: {
|
2015-11-11 00:56:15 +01:00
|
|
|
const APInt *C;
|
2015-11-06 20:00:57 +01:00
|
|
|
|
|
|
|
// LHS s<= LHS +_{nsw} C if C >= 0
|
2015-11-11 01:16:41 +01:00
|
|
|
if (match(RHS, m_NSWAdd(m_Specific(LHS), m_APInt(C))))
|
2015-11-11 00:56:15 +01:00
|
|
|
return !C->isNegative();
|
2015-11-06 20:00:57 +01:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
case CmpInst::ICMP_ULE: {
|
2015-11-11 00:56:15 +01:00
|
|
|
const APInt *C;
|
2015-11-06 20:00:57 +01:00
|
|
|
|
2015-11-11 01:16:41 +01:00
|
|
|
// LHS u<= LHS +_{nuw} C for any C
|
|
|
|
if (match(RHS, m_NUWAdd(m_Specific(LHS), m_APInt(C))))
|
2015-11-06 20:01:03 +01:00
|
|
|
return true;
|
2015-11-11 00:56:20 +01:00
|
|
|
|
|
|
|
// Match A to (X +_{nuw} CA) and B to (X +_{nuw} CB)
|
2016-08-13 03:05:32 +02:00
|
|
|
auto MatchNUWAddsToSameValue = [&](const Value *A, const Value *B,
|
|
|
|
const Value *&X,
|
2015-11-11 00:56:20 +01:00
|
|
|
const APInt *&CA, const APInt *&CB) {
|
|
|
|
if (match(A, m_NUWAdd(m_Value(X), m_APInt(CA))) &&
|
|
|
|
match(B, m_NUWAdd(m_Specific(X), m_APInt(CB))))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// If X & C == 0 then (X | C) == X +_{nuw} C
|
|
|
|
if (match(A, m_Or(m_Value(X), m_APInt(CA))) &&
|
|
|
|
match(B, m_Or(m_Specific(X), m_APInt(CB)))) {
|
2017-04-26 18:39:58 +02:00
|
|
|
KnownBits Known(CA->getBitWidth());
|
2017-07-28 16:39:06 +02:00
|
|
|
computeKnownBits(X, Known, DL, Depth + 1, /*AC*/ nullptr,
|
|
|
|
/*CxtI*/ nullptr, /*DT*/ nullptr);
|
2017-04-26 18:39:58 +02:00
|
|
|
if (CA->isSubsetOf(Known.Zero) && CB->isSubsetOf(Known.Zero))
|
2015-11-11 00:56:20 +01:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
};
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
const Value *X;
|
2015-11-11 00:56:20 +01:00
|
|
|
const APInt *CLHS, *CRHS;
|
2015-11-11 01:16:41 +01:00
|
|
|
if (MatchNUWAddsToSameValue(LHS, RHS, X, CLHS, CRHS))
|
|
|
|
return CLHS->ule(*CRHS);
|
2015-11-11 00:56:20 +01:00
|
|
|
|
2015-11-06 20:00:57 +01:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Return true if "icmp Pred BLHS BRHS" is true whenever "icmp Pred
|
2016-04-20 21:15:26 +02:00
|
|
|
/// ALHS ARHS" is true. Otherwise, return None.
|
|
|
|
static Optional<bool>
|
2016-08-13 03:05:32 +02:00
|
|
|
isImpliedCondOperands(CmpInst::Predicate Pred, const Value *ALHS,
|
2017-07-28 16:39:06 +02:00
|
|
|
const Value *ARHS, const Value *BLHS, const Value *BRHS,
|
|
|
|
const DataLayout &DL, unsigned Depth) {
|
2015-11-06 20:00:57 +01:00
|
|
|
switch (Pred) {
|
|
|
|
default:
|
2016-04-20 21:15:26 +02:00
|
|
|
return None;
|
2015-11-06 20:00:57 +01:00
|
|
|
|
|
|
|
case CmpInst::ICMP_SLT:
|
|
|
|
case CmpInst::ICMP_SLE:
|
2017-07-28 16:39:06 +02:00
|
|
|
if (isTruePredicate(CmpInst::ICMP_SLE, BLHS, ALHS, DL, Depth) &&
|
|
|
|
isTruePredicate(CmpInst::ICMP_SLE, ARHS, BRHS, DL, Depth))
|
2016-04-20 21:15:26 +02:00
|
|
|
return true;
|
|
|
|
return None;
|
2015-11-06 20:00:57 +01:00
|
|
|
|
|
|
|
case CmpInst::ICMP_ULT:
|
|
|
|
case CmpInst::ICMP_ULE:
|
2017-07-28 16:39:06 +02:00
|
|
|
if (isTruePredicate(CmpInst::ICMP_ULE, BLHS, ALHS, DL, Depth) &&
|
|
|
|
isTruePredicate(CmpInst::ICMP_ULE, ARHS, BRHS, DL, Depth))
|
2016-04-20 21:15:26 +02:00
|
|
|
return true;
|
|
|
|
return None;
|
2015-11-06 20:00:57 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-05 19:41:19 +02:00
|
|
|
/// Return true if the operands of the two compares match. IsSwappedOps is true
|
|
|
|
/// when the operands match, but are swapped.
|
2016-08-13 03:05:32 +02:00
|
|
|
static bool isMatchingOps(const Value *ALHS, const Value *ARHS,
|
|
|
|
const Value *BLHS, const Value *BRHS,
|
2016-05-05 19:41:19 +02:00
|
|
|
bool &IsSwappedOps) {
|
|
|
|
|
|
|
|
bool IsMatchingOps = (ALHS == BLHS && ARHS == BRHS);
|
|
|
|
IsSwappedOps = (ALHS == BRHS && ARHS == BLHS);
|
|
|
|
return IsMatchingOps || IsSwappedOps;
|
|
|
|
}
|
|
|
|
|
2018-12-19 17:49:18 +01:00
|
|
|
/// Return true if "icmp1 APred X, Y" implies "icmp2 BPred X, Y" is true.
|
|
|
|
/// Return false if "icmp1 APred X, Y" implies "icmp2 BPred X, Y" is false.
|
|
|
|
/// Otherwise, return None if we can't infer anything.
|
2016-04-20 21:15:26 +02:00
|
|
|
static Optional<bool> isImpliedCondMatchingOperands(CmpInst::Predicate APred,
|
|
|
|
CmpInst::Predicate BPred,
|
2018-12-19 17:49:18 +01:00
|
|
|
bool AreSwappedOps) {
|
|
|
|
// Canonicalize the predicate as if the operands were not commuted.
|
|
|
|
if (AreSwappedOps)
|
2016-04-19 19:19:14 +02:00
|
|
|
BPred = ICmpInst::getSwappedPredicate(BPred);
|
2018-12-19 17:49:18 +01:00
|
|
|
|
2016-04-21 18:18:02 +02:00
|
|
|
if (CmpInst::isImpliedTrueByMatchingCmp(APred, BPred))
|
2016-04-19 19:19:14 +02:00
|
|
|
return true;
|
2016-04-21 18:18:02 +02:00
|
|
|
if (CmpInst::isImpliedFalseByMatchingCmp(APred, BPred))
|
2016-04-20 21:15:26 +02:00
|
|
|
return false;
|
2016-04-19 19:19:14 +02:00
|
|
|
|
2016-04-20 21:15:26 +02:00
|
|
|
return None;
|
2016-04-19 19:19:14 +02:00
|
|
|
}
|
|
|
|
|
2018-12-19 17:49:18 +01:00
|
|
|
/// Return true if "icmp APred X, C1" implies "icmp BPred X, C2" is true.
|
|
|
|
/// Return false if "icmp APred X, C1" implies "icmp BPred X, C2" is false.
|
|
|
|
/// Otherwise, return None if we can't infer anything.
|
2016-05-05 17:39:18 +02:00
|
|
|
static Optional<bool>
|
2018-12-19 17:49:18 +01:00
|
|
|
isImpliedCondMatchingImmOperands(CmpInst::Predicate APred,
|
2016-08-13 03:05:32 +02:00
|
|
|
const ConstantInt *C1,
|
|
|
|
CmpInst::Predicate BPred,
|
2018-12-19 17:49:18 +01:00
|
|
|
const ConstantInt *C2) {
|
2016-05-05 17:39:18 +02:00
|
|
|
ConstantRange DomCR =
|
|
|
|
ConstantRange::makeExactICmpRegion(APred, C1->getValue());
|
|
|
|
ConstantRange CR =
|
|
|
|
ConstantRange::makeAllowedICmpRegion(BPred, C2->getValue());
|
|
|
|
ConstantRange Intersection = DomCR.intersectWith(CR);
|
|
|
|
ConstantRange Difference = DomCR.difference(CR);
|
|
|
|
if (Intersection.isEmptySet())
|
|
|
|
return false;
|
|
|
|
if (Difference.isEmptySet())
|
|
|
|
return true;
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
|
2017-07-28 20:47:43 +02:00
|
|
|
/// Return true if LHS implies RHS is true. Return false if LHS implies RHS is
|
|
|
|
/// false. Otherwise, return None if we can't infer anything.
|
|
|
|
static Optional<bool> isImpliedCondICmps(const ICmpInst *LHS,
|
|
|
|
const ICmpInst *RHS,
|
2017-08-01 22:18:54 +02:00
|
|
|
const DataLayout &DL, bool LHSIsTrue,
|
2017-07-28 20:47:43 +02:00
|
|
|
unsigned Depth) {
|
|
|
|
Value *ALHS = LHS->getOperand(0);
|
|
|
|
Value *ARHS = LHS->getOperand(1);
|
|
|
|
// The rest of the logic assumes the LHS condition is true. If that's not the
|
|
|
|
// case, invert the predicate to make it so.
|
|
|
|
ICmpInst::Predicate APred =
|
2017-08-01 22:18:54 +02:00
|
|
|
LHSIsTrue ? LHS->getPredicate() : LHS->getInversePredicate();
|
2017-07-28 20:47:43 +02:00
|
|
|
|
|
|
|
Value *BLHS = RHS->getOperand(0);
|
|
|
|
Value *BRHS = RHS->getOperand(1);
|
|
|
|
ICmpInst::Predicate BPred = RHS->getPredicate();
|
|
|
|
|
|
|
|
// Can we infer anything when the two compares have matching operands?
|
2018-12-19 17:49:18 +01:00
|
|
|
bool AreSwappedOps;
|
|
|
|
if (isMatchingOps(ALHS, ARHS, BLHS, BRHS, AreSwappedOps)) {
|
2017-07-28 20:47:43 +02:00
|
|
|
if (Optional<bool> Implication = isImpliedCondMatchingOperands(
|
2018-12-19 17:49:18 +01:00
|
|
|
APred, BPred, AreSwappedOps))
|
2017-07-28 20:47:43 +02:00
|
|
|
return Implication;
|
|
|
|
// No amount of additional analysis will infer the second condition, so
|
|
|
|
// early exit.
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Can we infer anything when the LHS operands match and the RHS operands are
|
|
|
|
// constants (not necessarily matching)?
|
|
|
|
if (ALHS == BLHS && isa<ConstantInt>(ARHS) && isa<ConstantInt>(BRHS)) {
|
|
|
|
if (Optional<bool> Implication = isImpliedCondMatchingImmOperands(
|
2018-12-19 17:49:18 +01:00
|
|
|
APred, cast<ConstantInt>(ARHS), BPred, cast<ConstantInt>(BRHS)))
|
2017-07-28 20:47:43 +02:00
|
|
|
return Implication;
|
|
|
|
// No amount of additional analysis will infer the second condition, so
|
|
|
|
// early exit.
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (APred == BPred)
|
|
|
|
return isImpliedCondOperands(APred, ALHS, ARHS, BLHS, BRHS, DL, Depth);
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
|
2017-08-01 21:22:36 +02:00
|
|
|
/// Return true if LHS implies RHS is true. Return false if LHS implies RHS is
|
|
|
|
/// false. Otherwise, return None if we can't infer anything. We expect the
|
|
|
|
/// RHS to be an icmp and the LHS to be an 'and' or an 'or' instruction.
|
|
|
|
static Optional<bool> isImpliedCondAndOr(const BinaryOperator *LHS,
|
|
|
|
const ICmpInst *RHS,
|
2017-08-01 22:18:54 +02:00
|
|
|
const DataLayout &DL, bool LHSIsTrue,
|
2017-08-01 21:22:36 +02:00
|
|
|
unsigned Depth) {
|
|
|
|
// The LHS must be an 'or' or an 'and' instruction.
|
|
|
|
assert((LHS->getOpcode() == Instruction::And ||
|
|
|
|
LHS->getOpcode() == Instruction::Or) &&
|
|
|
|
"Expected LHS to be 'and' or 'or'.");
|
|
|
|
|
2017-08-09 18:06:54 +02:00
|
|
|
assert(Depth <= MaxDepth && "Hit recursion limit");
|
2017-08-01 21:22:36 +02:00
|
|
|
|
|
|
|
// If the result of an 'or' is false, then we know both legs of the 'or' are
|
|
|
|
// false. Similarly, if the result of an 'and' is true, then we know both
|
|
|
|
// legs of the 'and' are true.
|
|
|
|
Value *ALHS, *ARHS;
|
2017-08-01 22:18:54 +02:00
|
|
|
if ((!LHSIsTrue && match(LHS, m_Or(m_Value(ALHS), m_Value(ARHS)))) ||
|
|
|
|
(LHSIsTrue && match(LHS, m_And(m_Value(ALHS), m_Value(ARHS))))) {
|
2017-08-01 21:22:36 +02:00
|
|
|
// FIXME: Make this non-recursion.
|
|
|
|
if (Optional<bool> Implication =
|
2017-08-01 22:18:54 +02:00
|
|
|
isImpliedCondition(ALHS, RHS, DL, LHSIsTrue, Depth + 1))
|
2017-08-01 21:22:36 +02:00
|
|
|
return Implication;
|
|
|
|
if (Optional<bool> Implication =
|
2017-08-01 22:18:54 +02:00
|
|
|
isImpliedCondition(ARHS, RHS, DL, LHSIsTrue, Depth + 1))
|
2017-08-01 21:22:36 +02:00
|
|
|
return Implication;
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
|
2016-08-13 03:05:32 +02:00
|
|
|
Optional<bool> llvm::isImpliedCondition(const Value *LHS, const Value *RHS,
|
2017-08-01 22:18:54 +02:00
|
|
|
const DataLayout &DL, bool LHSIsTrue,
|
2017-07-28 16:39:06 +02:00
|
|
|
unsigned Depth) {
|
2017-08-09 17:13:50 +02:00
|
|
|
// Bail out when we hit the limit.
|
|
|
|
if (Depth == MaxDepth)
|
|
|
|
return None;
|
|
|
|
|
2017-08-01 21:22:36 +02:00
|
|
|
// A mismatch occurs when we compare a scalar cmp to a vector cmp, for
|
|
|
|
// example.
|
2016-04-29 23:12:31 +02:00
|
|
|
if (LHS->getType() != RHS->getType())
|
|
|
|
return None;
|
|
|
|
|
2015-10-28 04:20:19 +01:00
|
|
|
Type *OpTy = LHS->getType();
|
2017-08-01 21:22:36 +02:00
|
|
|
assert(OpTy->isIntOrIntVectorTy(1) && "Expected integer type only!");
|
2015-10-28 04:20:19 +01:00
|
|
|
|
|
|
|
// LHS ==> RHS by definition
|
2017-07-07 15:55:55 +02:00
|
|
|
if (LHS == RHS)
|
2017-08-01 22:18:54 +02:00
|
|
|
return LHSIsTrue;
|
2015-10-28 04:20:19 +01:00
|
|
|
|
2017-08-01 21:22:36 +02:00
|
|
|
// FIXME: Extending the code below to handle vectors.
|
2015-10-28 04:20:19 +01:00
|
|
|
if (OpTy->isVectorTy())
|
2016-04-20 21:15:26 +02:00
|
|
|
return None;
|
2015-10-28 04:20:19 +01:00
|
|
|
|
2017-08-01 21:22:36 +02:00
|
|
|
assert(OpTy->isIntegerTy(1) && "implied by above");
|
2017-07-28 20:47:43 +02:00
|
|
|
|
|
|
|
// Both LHS and RHS are icmps.
|
2017-08-01 21:22:36 +02:00
|
|
|
const ICmpInst *LHSCmp = dyn_cast<ICmpInst>(LHS);
|
|
|
|
const ICmpInst *RHSCmp = dyn_cast<ICmpInst>(RHS);
|
|
|
|
if (LHSCmp && RHSCmp)
|
2017-08-01 22:18:54 +02:00
|
|
|
return isImpliedCondICmps(LHSCmp, RHSCmp, DL, LHSIsTrue, Depth);
|
2017-08-01 21:22:36 +02:00
|
|
|
|
|
|
|
// The LHS should be an 'or' or an 'and' instruction. We expect the RHS to be
|
|
|
|
// an icmp. FIXME: Add support for and/or on the RHS.
|
|
|
|
const BinaryOperator *LHSBO = dyn_cast<BinaryOperator>(LHS);
|
|
|
|
if (LHSBO && RHSCmp) {
|
|
|
|
if ((LHSBO->getOpcode() == Instruction::And ||
|
|
|
|
LHSBO->getOpcode() == Instruction::Or))
|
2017-08-01 22:18:54 +02:00
|
|
|
return isImpliedCondAndOr(LHSBO, RHSCmp, DL, LHSIsTrue, Depth);
|
2016-05-05 17:39:18 +02:00
|
|
|
}
|
2017-08-01 21:22:36 +02:00
|
|
|
return None;
|
2015-10-28 04:20:19 +01:00
|
|
|
}
|
2018-12-02 14:26:03 +01:00
|
|
|
|
|
|
|
Optional<bool> llvm::isImpliedByDomCondition(const Value *Cond,
|
|
|
|
const Instruction *ContextI,
|
|
|
|
const DataLayout &DL) {
|
|
|
|
assert(Cond->getType()->isIntOrIntVectorTy(1) && "Condition must be bool");
|
|
|
|
if (!ContextI || !ContextI->getParent())
|
|
|
|
return None;
|
|
|
|
|
|
|
|
// TODO: This is a poor/cheap way to determine dominance. Should we use a
|
|
|
|
// dominator tree (eg, from a SimplifyQuery) instead?
|
|
|
|
const BasicBlock *ContextBB = ContextI->getParent();
|
|
|
|
const BasicBlock *PredBB = ContextBB->getSinglePredecessor();
|
|
|
|
if (!PredBB)
|
|
|
|
return None;
|
|
|
|
|
|
|
|
// We need a conditional branch in the predecessor.
|
|
|
|
Value *PredCond;
|
|
|
|
BasicBlock *TrueBB, *FalseBB;
|
|
|
|
if (!match(PredBB->getTerminator(), m_Br(m_Value(PredCond), TrueBB, FalseBB)))
|
|
|
|
return None;
|
|
|
|
|
|
|
|
// The branch should get simplified. Don't bother simplifying this condition.
|
|
|
|
if (TrueBB == FalseBB)
|
|
|
|
return None;
|
|
|
|
|
|
|
|
assert((TrueBB == ContextBB || FalseBB == ContextBB) &&
|
|
|
|
"Predecessor block does not point to successor?");
|
|
|
|
|
|
|
|
// Is this condition implied by the predecessor condition?
|
|
|
|
bool CondIsTrue = TrueBB == ContextBB;
|
|
|
|
return isImpliedCondition(PredCond, Cond, DL, CondIsTrue);
|
|
|
|
}
|