2014-05-24 20:50:23 +08:00
|
|
|
//=- AArch64PromoteConstant.cpp --- Promote constant to global for AArch64 -==//
|
2014-03-29 18:18:08 +08:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2014-05-24 20:50:23 +08:00
|
|
|
// This file implements the AArch64PromoteConstant pass which promotes constants
|
2014-04-08 07:14:38 +08:00
|
|
|
// to global variables when this is likely to be more efficient. Currently only
|
|
|
|
// types related to constant vector (i.e., constant vector, array of constant
|
|
|
|
// vectors, constant structure with a constant vector field, etc.) are promoted
|
|
|
|
// to global variables. Constant vectors are likely to be lowered in target
|
|
|
|
// constant pool during instruction selection already; therefore, the access
|
|
|
|
// will remain the same (memory load), but the structure types are not split
|
|
|
|
// into different constant pool accesses for each field. A bonus side effect is
|
|
|
|
// that created globals may be merged by the global merge pass.
|
2014-03-29 18:18:08 +08:00
|
|
|
//
|
|
|
|
// FIXME: This pass may be useful for other targets too.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-05-24 20:50:23 +08:00
|
|
|
#include "AArch64.h"
|
2014-03-29 18:18:08 +08:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
2015-02-06 22:43:55 +08:00
|
|
|
#include "llvm/ADT/SmallPtrSet.h"
|
2014-03-29 18:18:08 +08:00
|
|
|
#include "llvm/ADT/SmallVector.h"
|
2014-07-25 19:42:14 +08:00
|
|
|
#include "llvm/ADT/Statistic.h"
|
2014-03-29 18:18:08 +08:00
|
|
|
#include "llvm/IR/Constants.h"
|
|
|
|
#include "llvm/IR/Dominators.h"
|
|
|
|
#include "llvm/IR/Function.h"
|
|
|
|
#include "llvm/IR/GlobalVariable.h"
|
2014-07-25 19:42:14 +08:00
|
|
|
#include "llvm/IR/IRBuilder.h"
|
2014-03-29 18:18:08 +08:00
|
|
|
#include "llvm/IR/InlineAsm.h"
|
2015-02-06 22:43:55 +08:00
|
|
|
#include "llvm/IR/InstIterator.h"
|
2014-03-29 18:18:08 +08:00
|
|
|
#include "llvm/IR/Instructions.h"
|
|
|
|
#include "llvm/IR/IntrinsicInst.h"
|
|
|
|
#include "llvm/IR/Module.h"
|
|
|
|
#include "llvm/Pass.h"
|
|
|
|
#include "llvm/Support/CommandLine.h"
|
|
|
|
#include "llvm/Support/Debug.h"
|
2015-03-24 03:32:43 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2014-03-29 18:18:08 +08:00
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
2014-05-24 20:50:23 +08:00
|
|
|
#define DEBUG_TYPE "aarch64-promote-const"
|
2014-04-22 10:41:26 +08:00
|
|
|
|
2014-03-29 18:18:08 +08:00
|
|
|
// Stress testing mode - disable heuristics.
|
2014-05-24 20:50:23 +08:00
|
|
|
static cl::opt<bool> Stress("aarch64-stress-promote-const", cl::Hidden,
|
2014-03-29 18:18:08 +08:00
|
|
|
cl::desc("Promote all vector constants"));
|
|
|
|
|
|
|
|
STATISTIC(NumPromoted, "Number of promoted constants");
|
|
|
|
STATISTIC(NumPromotedUses, "Number of promoted constants uses");
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
2014-05-24 20:50:23 +08:00
|
|
|
// AArch64PromoteConstant
|
2014-03-29 18:18:08 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
/// Promotes interesting constant into global variables.
|
|
|
|
/// The motivating example is:
|
|
|
|
/// static const uint16_t TableA[32] = {
|
|
|
|
/// 41944, 40330, 38837, 37450, 36158, 34953, 33826, 32768,
|
|
|
|
/// 31776, 30841, 29960, 29128, 28340, 27595, 26887, 26215,
|
|
|
|
/// 25576, 24967, 24386, 23832, 23302, 22796, 22311, 21846,
|
|
|
|
/// 21400, 20972, 20561, 20165, 19785, 19419, 19066, 18725,
|
|
|
|
/// };
|
|
|
|
///
|
|
|
|
/// uint8x16x4_t LoadStatic(void) {
|
|
|
|
/// uint8x16x4_t ret;
|
|
|
|
/// ret.val[0] = vld1q_u16(TableA + 0);
|
|
|
|
/// ret.val[1] = vld1q_u16(TableA + 8);
|
|
|
|
/// ret.val[2] = vld1q_u16(TableA + 16);
|
|
|
|
/// ret.val[3] = vld1q_u16(TableA + 24);
|
|
|
|
/// return ret;
|
|
|
|
/// }
|
|
|
|
///
|
2014-04-08 07:47:23 +08:00
|
|
|
/// The constants in this example are folded into the uses. Thus, 4 different
|
2014-03-29 18:18:08 +08:00
|
|
|
/// constants are created.
|
2014-04-08 07:47:23 +08:00
|
|
|
///
|
2014-03-29 18:18:08 +08:00
|
|
|
/// As their type is vector the cheapest way to create them is to load them
|
|
|
|
/// for the memory.
|
2014-04-08 07:47:23 +08:00
|
|
|
///
|
|
|
|
/// Therefore the final assembly final has 4 different loads. With this pass
|
|
|
|
/// enabled, only one load is issued for the constants.
|
2014-05-24 20:50:23 +08:00
|
|
|
class AArch64PromoteConstant : public ModulePass {
|
2014-03-29 18:18:08 +08:00
|
|
|
|
|
|
|
public:
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
struct PromotedConstant {
|
|
|
|
bool ShouldConvert = false;
|
|
|
|
GlobalVariable *GV = nullptr;
|
|
|
|
};
|
|
|
|
typedef SmallDenseMap<Constant *, PromotedConstant, 16> PromotionCacheTy;
|
|
|
|
|
|
|
|
struct UpdateRecord {
|
|
|
|
Constant *C;
|
|
|
|
Instruction *User;
|
|
|
|
unsigned Op;
|
|
|
|
|
|
|
|
UpdateRecord(Constant *C, Instruction *User, unsigned Op)
|
|
|
|
: C(C), User(User), Op(Op) {}
|
|
|
|
};
|
|
|
|
|
2014-03-29 18:18:08 +08:00
|
|
|
static char ID;
|
2016-08-01 13:56:57 +08:00
|
|
|
AArch64PromoteConstant() : ModulePass(ID) {
|
|
|
|
initializeAArch64PromoteConstantPass(*PassRegistry::getPassRegistry());
|
|
|
|
}
|
2014-03-29 18:18:08 +08:00
|
|
|
|
2014-05-24 20:50:23 +08:00
|
|
|
const char *getPassName() const override { return "AArch64 Promote Constant"; }
|
2014-03-29 18:18:08 +08:00
|
|
|
|
|
|
|
/// Iterate over the functions and promote the interesting constants into
|
|
|
|
/// global variables with module scope.
|
2014-04-29 15:58:25 +08:00
|
|
|
bool runOnModule(Module &M) override {
|
2014-03-29 18:18:08 +08:00
|
|
|
DEBUG(dbgs() << getPassName() << '\n');
|
2016-04-26 05:58:52 +08:00
|
|
|
if (skipModule(M))
|
|
|
|
return false;
|
2014-03-29 18:18:08 +08:00
|
|
|
bool Changed = false;
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
PromotionCacheTy PromotionCache;
|
2014-04-04 07:43:26 +08:00
|
|
|
for (auto &MF : M) {
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
Changed |= runOnFunction(MF, PromotionCache);
|
2014-03-29 18:18:08 +08:00
|
|
|
}
|
|
|
|
return Changed;
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
/// Look for interesting constants used within the given function.
|
|
|
|
/// Promote them into global variables, load these global variables within
|
|
|
|
/// the related function, so that the number of inserted load is minimal.
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
bool runOnFunction(Function &F, PromotionCacheTy &PromotionCache);
|
2014-03-29 18:18:08 +08:00
|
|
|
|
|
|
|
// This transformation requires dominator info
|
2014-04-29 15:58:25 +08:00
|
|
|
void getAnalysisUsage(AnalysisUsage &AU) const override {
|
2014-03-29 18:18:08 +08:00
|
|
|
AU.setPreservesCFG();
|
|
|
|
AU.addRequired<DominatorTreeWrapperPass>();
|
|
|
|
AU.addPreserved<DominatorTreeWrapperPass>();
|
|
|
|
}
|
|
|
|
|
2015-02-06 22:43:55 +08:00
|
|
|
/// Type to store a list of Uses.
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
typedef SmallVector<std::pair<Instruction *, unsigned>, 4> Uses;
|
2014-03-29 18:18:08 +08:00
|
|
|
/// Map an insertion point to all the uses it dominates.
|
2015-02-06 22:43:55 +08:00
|
|
|
typedef DenseMap<Instruction *, Uses> InsertionPoints;
|
2014-03-29 18:18:08 +08:00
|
|
|
|
|
|
|
/// Find the closest point that dominates the given Use.
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
Instruction *findInsertionPoint(Instruction &User, unsigned OpNo);
|
2014-03-29 18:18:08 +08:00
|
|
|
|
|
|
|
/// Check if the given insertion point is dominated by an existing
|
|
|
|
/// insertion point.
|
|
|
|
/// If true, the given use is added to the list of dominated uses for
|
|
|
|
/// the related existing point.
|
|
|
|
/// \param NewPt the insertion point to be checked
|
2016-03-22 06:13:44 +08:00
|
|
|
/// \param User the user of the constant
|
|
|
|
/// \param OpNo the operand number of the use
|
2014-03-29 18:18:08 +08:00
|
|
|
/// \param InsertPts existing insertion points
|
|
|
|
/// \pre NewPt and all instruction in InsertPts belong to the same function
|
2014-03-30 03:40:32 +08:00
|
|
|
/// \return true if one of the insertion point in InsertPts dominates NewPt,
|
|
|
|
/// false otherwise
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
bool isDominated(Instruction *NewPt, Instruction *User, unsigned OpNo,
|
|
|
|
InsertionPoints &InsertPts);
|
2014-03-29 18:18:08 +08:00
|
|
|
|
|
|
|
/// Check if the given insertion point can be merged with an existing
|
|
|
|
/// insertion point in a common dominator.
|
|
|
|
/// If true, the given use is added to the list of the created insertion
|
|
|
|
/// point.
|
|
|
|
/// \param NewPt the insertion point to be checked
|
2016-03-22 06:13:44 +08:00
|
|
|
/// \param User the user of the constant
|
|
|
|
/// \param OpNo the operand number of the use
|
2014-03-29 18:18:08 +08:00
|
|
|
/// \param InsertPts existing insertion points
|
|
|
|
/// \pre NewPt and all instruction in InsertPts belong to the same function
|
|
|
|
/// \pre isDominated returns false for the exact same parameters.
|
2014-03-30 03:40:32 +08:00
|
|
|
/// \return true if it exists an insertion point in InsertPts that could
|
|
|
|
/// have been merged with NewPt in a common dominator,
|
|
|
|
/// false otherwise
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
bool tryAndMerge(Instruction *NewPt, Instruction *User, unsigned OpNo,
|
|
|
|
InsertionPoints &InsertPts);
|
2014-03-29 18:18:08 +08:00
|
|
|
|
|
|
|
/// Compute the minimal insertion points to dominates all the interesting
|
|
|
|
/// uses of value.
|
|
|
|
/// Insertion points are group per function and each insertion point
|
|
|
|
/// contains a list of all the uses it dominates within the related function
|
2016-03-22 06:13:44 +08:00
|
|
|
/// \param User the user of the constant
|
|
|
|
/// \param OpNo the operand number of the constant
|
|
|
|
/// \param[out] InsertPts output storage of the analysis
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
void computeInsertionPoint(Instruction *User, unsigned OpNo,
|
|
|
|
InsertionPoints &InsertPts);
|
2014-03-29 18:18:08 +08:00
|
|
|
|
|
|
|
/// Insert a definition of a new global variable at each point contained in
|
|
|
|
/// InsPtsPerFunc and update the related uses (also contained in
|
|
|
|
/// InsPtsPerFunc).
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
void insertDefinitions(Function &F, GlobalVariable &GV,
|
|
|
|
InsertionPoints &InsertPts);
|
|
|
|
|
|
|
|
/// Do the constant promotion indicated by the Updates records, keeping track
|
|
|
|
/// of globals in PromotionCache.
|
|
|
|
void promoteConstants(Function &F, SmallVectorImpl<UpdateRecord> &Updates,
|
|
|
|
PromotionCacheTy &PromotionCache);
|
2014-03-29 18:18:08 +08:00
|
|
|
|
|
|
|
/// Transfer the list of dominated uses of IPI to NewPt in InsertPts.
|
2015-02-06 22:43:55 +08:00
|
|
|
/// Append Use to this list and delete the entry of IPI in InsertPts.
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
static void appendAndTransferDominatedUses(Instruction *NewPt,
|
|
|
|
Instruction *User, unsigned OpNo,
|
2014-03-29 18:18:08 +08:00
|
|
|
InsertionPoints::iterator &IPI,
|
|
|
|
InsertionPoints &InsertPts) {
|
2014-04-08 07:47:23 +08:00
|
|
|
// Record the dominated use.
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
IPI->second.emplace_back(User, OpNo);
|
2014-03-29 18:18:08 +08:00
|
|
|
// Transfer the dominated uses of IPI to NewPt
|
|
|
|
// Inserting into the DenseMap may invalidate existing iterator.
|
2015-03-02 08:17:18 +08:00
|
|
|
// Keep a copy of the key to find the iterator to erase. Keep a copy of the
|
|
|
|
// value so that we don't have to dereference IPI->second.
|
2014-03-29 18:18:08 +08:00
|
|
|
Instruction *OldInstr = IPI->first;
|
2015-03-02 08:17:18 +08:00
|
|
|
Uses OldUses = std::move(IPI->second);
|
|
|
|
InsertPts[NewPt] = std::move(OldUses);
|
2014-04-08 07:47:23 +08:00
|
|
|
// Erase IPI.
|
2015-02-06 22:43:55 +08:00
|
|
|
InsertPts.erase(OldInstr);
|
2014-03-29 18:18:08 +08:00
|
|
|
}
|
|
|
|
};
|
|
|
|
} // end anonymous namespace
|
|
|
|
|
2014-05-24 20:50:23 +08:00
|
|
|
char AArch64PromoteConstant::ID = 0;
|
2014-03-29 18:18:08 +08:00
|
|
|
|
2014-05-24 20:50:23 +08:00
|
|
|
INITIALIZE_PASS_BEGIN(AArch64PromoteConstant, "aarch64-promote-const",
|
|
|
|
"AArch64 Promote Constant Pass", false, false)
|
2014-03-29 18:18:08 +08:00
|
|
|
INITIALIZE_PASS_DEPENDENCY(DominatorTreeWrapperPass)
|
2014-05-24 20:50:23 +08:00
|
|
|
INITIALIZE_PASS_END(AArch64PromoteConstant, "aarch64-promote-const",
|
|
|
|
"AArch64 Promote Constant Pass", false, false)
|
2014-03-29 18:18:08 +08:00
|
|
|
|
2014-05-24 20:50:23 +08:00
|
|
|
ModulePass *llvm::createAArch64PromoteConstantPass() {
|
|
|
|
return new AArch64PromoteConstant();
|
2014-03-29 18:18:08 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Check if the given type uses a vector type.
|
|
|
|
static bool isConstantUsingVectorTy(const Type *CstTy) {
|
|
|
|
if (CstTy->isVectorTy())
|
|
|
|
return true;
|
|
|
|
if (CstTy->isStructTy()) {
|
|
|
|
for (unsigned EltIdx = 0, EndEltIdx = CstTy->getStructNumElements();
|
|
|
|
EltIdx < EndEltIdx; ++EltIdx)
|
|
|
|
if (isConstantUsingVectorTy(CstTy->getStructElementType(EltIdx)))
|
|
|
|
return true;
|
|
|
|
} else if (CstTy->isArrayTy())
|
|
|
|
return isConstantUsingVectorTy(CstTy->getArrayElementType());
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Check if the given use (Instruction + OpIdx) of Cst should be converted into
|
|
|
|
/// a load of a global variable initialized with Cst.
|
|
|
|
/// A use should be converted if it is legal to do so.
|
|
|
|
/// For instance, it is not legal to turn the mask operand of a shuffle vector
|
|
|
|
/// into a load of a global variable.
|
|
|
|
static bool shouldConvertUse(const Constant *Cst, const Instruction *Instr,
|
|
|
|
unsigned OpIdx) {
|
|
|
|
// shufflevector instruction expects a const for the mask argument, i.e., the
|
|
|
|
// third argument. Do not promote this use in that case.
|
|
|
|
if (isa<const ShuffleVectorInst>(Instr) && OpIdx == 2)
|
|
|
|
return false;
|
|
|
|
|
2014-04-08 07:47:23 +08:00
|
|
|
// extractvalue instruction expects a const idx.
|
2014-03-29 18:18:08 +08:00
|
|
|
if (isa<const ExtractValueInst>(Instr) && OpIdx > 0)
|
|
|
|
return false;
|
|
|
|
|
2014-04-08 07:47:23 +08:00
|
|
|
// extractvalue instruction expects a const idx.
|
2014-03-29 18:18:08 +08:00
|
|
|
if (isa<const InsertValueInst>(Instr) && OpIdx > 1)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (isa<const AllocaInst>(Instr) && OpIdx > 0)
|
|
|
|
return false;
|
|
|
|
|
2014-04-08 07:47:23 +08:00
|
|
|
// Alignment argument must be constant.
|
2014-03-29 18:18:08 +08:00
|
|
|
if (isa<const LoadInst>(Instr) && OpIdx > 0)
|
|
|
|
return false;
|
|
|
|
|
2014-04-08 07:47:23 +08:00
|
|
|
// Alignment argument must be constant.
|
2014-03-29 18:18:08 +08:00
|
|
|
if (isa<const StoreInst>(Instr) && OpIdx > 1)
|
|
|
|
return false;
|
|
|
|
|
2014-04-08 07:47:23 +08:00
|
|
|
// Index must be constant.
|
2014-03-29 18:18:08 +08:00
|
|
|
if (isa<const GetElementPtrInst>(Instr) && OpIdx > 0)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Personality function and filters must be constant.
|
|
|
|
// Give up on that instruction.
|
|
|
|
if (isa<const LandingPadInst>(Instr))
|
|
|
|
return false;
|
|
|
|
|
2014-04-08 07:47:23 +08:00
|
|
|
// Switch instruction expects constants to compare to.
|
2014-03-29 18:18:08 +08:00
|
|
|
if (isa<const SwitchInst>(Instr))
|
|
|
|
return false;
|
|
|
|
|
2014-04-08 07:47:23 +08:00
|
|
|
// Expected address must be a constant.
|
2014-03-29 18:18:08 +08:00
|
|
|
if (isa<const IndirectBrInst>(Instr))
|
|
|
|
return false;
|
|
|
|
|
2014-04-08 07:47:23 +08:00
|
|
|
// Do not mess with intrinsics.
|
2014-03-29 18:18:08 +08:00
|
|
|
if (isa<const IntrinsicInst>(Instr))
|
|
|
|
return false;
|
|
|
|
|
2014-04-08 07:47:23 +08:00
|
|
|
// Do not mess with inline asm.
|
2014-03-29 18:18:08 +08:00
|
|
|
const CallInst *CI = dyn_cast<const CallInst>(Instr);
|
2016-03-01 06:50:49 +08:00
|
|
|
return !(CI && isa<const InlineAsm>(CI->getCalledValue()));
|
2014-03-29 18:18:08 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Check if the given Cst should be converted into
|
|
|
|
/// a load of a global variable initialized with Cst.
|
|
|
|
/// A constant should be converted if it is likely that the materialization of
|
|
|
|
/// the constant will be tricky. Thus, we give up on zero or undef values.
|
|
|
|
///
|
|
|
|
/// \todo Currently, accept only vector related types.
|
|
|
|
/// Also we give up on all simple vector type to keep the existing
|
|
|
|
/// behavior. Otherwise, we should push here all the check of the lowering of
|
|
|
|
/// BUILD_VECTOR. By giving up, we lose the potential benefit of merging
|
|
|
|
/// constant via global merge and the fact that the same constant is stored
|
|
|
|
/// only once with this method (versus, as many function that uses the constant
|
|
|
|
/// for the regular approach, even for float).
|
|
|
|
/// Again, the simplest solution would be to promote every
|
|
|
|
/// constant and rematerialize them when they are actually cheap to create.
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
static bool shouldConvertImpl(const Constant *Cst) {
|
2014-03-29 18:18:08 +08:00
|
|
|
if (isa<const UndefValue>(Cst))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// FIXME: In some cases, it may be interesting to promote in memory
|
|
|
|
// a zero initialized constant.
|
|
|
|
// E.g., when the type of Cst require more instructions than the
|
|
|
|
// adrp/add/load sequence or when this sequence can be shared by several
|
|
|
|
// instances of Cst.
|
|
|
|
// Ideally, we could promote this into a global and rematerialize the constant
|
|
|
|
// when it was a bad idea.
|
|
|
|
if (Cst->isZeroValue())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (Stress)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// FIXME: see function \todo
|
|
|
|
if (Cst->getType()->isVectorTy())
|
|
|
|
return false;
|
|
|
|
return isConstantUsingVectorTy(Cst->getType());
|
|
|
|
}
|
|
|
|
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
static bool
|
|
|
|
shouldConvert(Constant &C,
|
|
|
|
AArch64PromoteConstant::PromotionCacheTy &PromotionCache) {
|
|
|
|
auto Converted = PromotionCache.insert(
|
|
|
|
std::make_pair(&C, AArch64PromoteConstant::PromotedConstant()));
|
|
|
|
if (Converted.second)
|
|
|
|
Converted.first->second.ShouldConvert = shouldConvertImpl(&C);
|
|
|
|
return Converted.first->second.ShouldConvert;
|
|
|
|
}
|
2015-02-06 22:43:55 +08:00
|
|
|
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
Instruction *AArch64PromoteConstant::findInsertionPoint(Instruction &User,
|
|
|
|
unsigned OpNo) {
|
2014-03-29 18:18:08 +08:00
|
|
|
// If this user is a phi, the insertion point is in the related
|
2014-04-08 07:47:23 +08:00
|
|
|
// incoming basic block.
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
if (PHINode *PhiInst = dyn_cast<PHINode>(&User))
|
|
|
|
return PhiInst->getIncomingBlock(OpNo)->getTerminator();
|
2015-02-06 22:43:55 +08:00
|
|
|
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
return &User;
|
2014-03-29 18:18:08 +08:00
|
|
|
}
|
|
|
|
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
bool AArch64PromoteConstant::isDominated(Instruction *NewPt, Instruction *User,
|
|
|
|
unsigned OpNo,
|
2014-05-24 20:50:23 +08:00
|
|
|
InsertionPoints &InsertPts) {
|
2014-03-29 18:18:08 +08:00
|
|
|
|
|
|
|
DominatorTree &DT = getAnalysis<DominatorTreeWrapperPass>(
|
|
|
|
*NewPt->getParent()->getParent()).getDomTree();
|
|
|
|
|
2014-04-08 07:47:23 +08:00
|
|
|
// Traverse all the existing insertion points and check if one is dominating
|
|
|
|
// NewPt. If it is, remember that.
|
2014-04-08 07:47:21 +08:00
|
|
|
for (auto &IPI : InsertPts) {
|
|
|
|
if (NewPt == IPI.first || DT.dominates(IPI.first, NewPt) ||
|
|
|
|
// When IPI.first is a terminator instruction, DT may think that
|
2014-03-29 18:18:08 +08:00
|
|
|
// the result is defined on the edge.
|
|
|
|
// Here we are testing the insertion point, not the definition.
|
2014-04-08 07:47:21 +08:00
|
|
|
(IPI.first->getParent() != NewPt->getParent() &&
|
|
|
|
DT.dominates(IPI.first->getParent(), NewPt->getParent()))) {
|
2014-04-08 07:47:23 +08:00
|
|
|
// No need to insert this point. Just record the dominated use.
|
2014-03-29 18:18:08 +08:00
|
|
|
DEBUG(dbgs() << "Insertion point dominated by:\n");
|
2014-04-08 07:47:21 +08:00
|
|
|
DEBUG(IPI.first->print(dbgs()));
|
2014-03-29 18:18:08 +08:00
|
|
|
DEBUG(dbgs() << '\n');
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
IPI.second.emplace_back(User, OpNo);
|
2014-03-29 18:18:08 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
bool AArch64PromoteConstant::tryAndMerge(Instruction *NewPt, Instruction *User,
|
|
|
|
unsigned OpNo,
|
2014-05-24 20:50:23 +08:00
|
|
|
InsertionPoints &InsertPts) {
|
2014-03-29 18:18:08 +08:00
|
|
|
DominatorTree &DT = getAnalysis<DominatorTreeWrapperPass>(
|
|
|
|
*NewPt->getParent()->getParent()).getDomTree();
|
|
|
|
BasicBlock *NewBB = NewPt->getParent();
|
|
|
|
|
|
|
|
// Traverse all the existing insertion point and check if one is dominated by
|
|
|
|
// NewPt and thus useless or can be combined with NewPt into a common
|
2014-04-08 07:47:23 +08:00
|
|
|
// dominator.
|
2014-03-29 18:18:08 +08:00
|
|
|
for (InsertionPoints::iterator IPI = InsertPts.begin(),
|
|
|
|
EndIPI = InsertPts.end();
|
|
|
|
IPI != EndIPI; ++IPI) {
|
|
|
|
BasicBlock *CurBB = IPI->first->getParent();
|
|
|
|
if (NewBB == CurBB) {
|
|
|
|
// Instructions are in the same block.
|
|
|
|
// By construction, NewPt is dominating the other.
|
|
|
|
// Indeed, isDominated returned false with the exact same arguments.
|
|
|
|
DEBUG(dbgs() << "Merge insertion point with:\n");
|
|
|
|
DEBUG(IPI->first->print(dbgs()));
|
|
|
|
DEBUG(dbgs() << "\nat considered insertion point.\n");
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
appendAndTransferDominatedUses(NewPt, User, OpNo, IPI, InsertPts);
|
2014-03-29 18:18:08 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Look for a common dominator
|
|
|
|
BasicBlock *CommonDominator = DT.findNearestCommonDominator(NewBB, CurBB);
|
2014-04-08 07:47:23 +08:00
|
|
|
// If none exists, we cannot merge these two points.
|
2014-03-29 18:18:08 +08:00
|
|
|
if (!CommonDominator)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (CommonDominator != NewBB) {
|
2014-04-08 07:47:23 +08:00
|
|
|
// By construction, the CommonDominator cannot be CurBB.
|
2014-03-29 18:18:08 +08:00
|
|
|
assert(CommonDominator != CurBB &&
|
|
|
|
"Instruction has not been rejected during isDominated check!");
|
|
|
|
// Take the last instruction of the CommonDominator as insertion point
|
|
|
|
NewPt = CommonDominator->getTerminator();
|
|
|
|
}
|
|
|
|
// else, CommonDominator is the block of NewBB, hence NewBB is the last
|
2014-04-08 07:47:23 +08:00
|
|
|
// possible insertion point in that block.
|
2014-03-29 18:18:08 +08:00
|
|
|
DEBUG(dbgs() << "Merge insertion point with:\n");
|
|
|
|
DEBUG(IPI->first->print(dbgs()));
|
|
|
|
DEBUG(dbgs() << '\n');
|
|
|
|
DEBUG(NewPt->print(dbgs()));
|
|
|
|
DEBUG(dbgs() << '\n');
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
appendAndTransferDominatedUses(NewPt, User, OpNo, IPI, InsertPts);
|
2014-03-29 18:18:08 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
void AArch64PromoteConstant::computeInsertionPoint(
|
|
|
|
Instruction *User, unsigned OpNo, InsertionPoints &InsertPts) {
|
|
|
|
DEBUG(dbgs() << "Considered use, opidx " << OpNo << ":\n");
|
|
|
|
DEBUG(User->print(dbgs()));
|
|
|
|
DEBUG(dbgs() << '\n');
|
2014-03-29 18:18:08 +08:00
|
|
|
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
Instruction *InsertionPoint = findInsertionPoint(*User, OpNo);
|
2014-03-29 18:18:08 +08:00
|
|
|
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
DEBUG(dbgs() << "Considered insertion point:\n");
|
|
|
|
DEBUG(InsertionPoint->print(dbgs()));
|
|
|
|
DEBUG(dbgs() << '\n');
|
2014-03-29 18:18:08 +08:00
|
|
|
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
if (isDominated(InsertionPoint, User, OpNo, InsertPts))
|
|
|
|
return;
|
|
|
|
// This insertion point is useful, check if we can merge some insertion
|
|
|
|
// point in a common dominator or if NewPt dominates an existing one.
|
|
|
|
if (tryAndMerge(InsertionPoint, User, OpNo, InsertPts))
|
|
|
|
return;
|
2014-03-29 18:18:08 +08:00
|
|
|
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
DEBUG(dbgs() << "Keep considered insertion point\n");
|
2014-03-29 18:18:08 +08:00
|
|
|
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
// It is definitely useful by its own
|
|
|
|
InsertPts[InsertionPoint].emplace_back(User, OpNo);
|
2014-03-29 18:18:08 +08:00
|
|
|
}
|
|
|
|
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
static void ensurePromotedGV(Function &F, Constant &C,
|
|
|
|
AArch64PromoteConstant::PromotedConstant &PC) {
|
|
|
|
assert(PC.ShouldConvert &&
|
|
|
|
"Expected that we should convert this to a global");
|
|
|
|
if (PC.GV)
|
|
|
|
return;
|
|
|
|
PC.GV = new GlobalVariable(
|
|
|
|
*F.getParent(), C.getType(), true, GlobalValue::InternalLinkage, nullptr,
|
|
|
|
"_PromotedConst", nullptr, GlobalVariable::NotThreadLocal);
|
|
|
|
PC.GV->setInitializer(&C);
|
|
|
|
DEBUG(dbgs() << "Global replacement: ");
|
|
|
|
DEBUG(PC.GV->print(dbgs()));
|
|
|
|
DEBUG(dbgs() << '\n');
|
|
|
|
++NumPromoted;
|
|
|
|
}
|
2014-03-29 18:18:08 +08:00
|
|
|
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
void AArch64PromoteConstant::insertDefinitions(Function &F,
|
|
|
|
GlobalVariable &PromotedGV,
|
|
|
|
InsertionPoints &InsertPts) {
|
2014-03-29 18:18:08 +08:00
|
|
|
#ifndef NDEBUG
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
// Do more checking for debug purposes.
|
|
|
|
DominatorTree &DT = getAnalysis<DominatorTreeWrapperPass>(F).getDomTree();
|
2014-03-29 18:18:08 +08:00
|
|
|
#endif
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
assert(!InsertPts.empty() && "Empty uses does not need a definition");
|
|
|
|
|
|
|
|
for (const auto &IPI : InsertPts) {
|
|
|
|
// Create the load of the global variable.
|
|
|
|
IRBuilder<> Builder(IPI.first);
|
|
|
|
LoadInst *LoadedCst = Builder.CreateLoad(&PromotedGV);
|
|
|
|
DEBUG(dbgs() << "**********\n");
|
|
|
|
DEBUG(dbgs() << "New def: ");
|
|
|
|
DEBUG(LoadedCst->print(dbgs()));
|
|
|
|
DEBUG(dbgs() << '\n');
|
2014-03-29 18:18:08 +08:00
|
|
|
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
// Update the dominated uses.
|
|
|
|
for (auto Use : IPI.second) {
|
2014-03-29 18:18:08 +08:00
|
|
|
#ifndef NDEBUG
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
assert(DT.dominates(LoadedCst,
|
|
|
|
findInsertionPoint(*Use.first, Use.second)) &&
|
|
|
|
"Inserted definition does not dominate all its uses!");
|
2014-03-29 18:18:08 +08:00
|
|
|
#endif
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
DEBUG({
|
|
|
|
dbgs() << "Use to update " << Use.second << ":";
|
|
|
|
Use.first->print(dbgs());
|
|
|
|
dbgs() << '\n';
|
|
|
|
});
|
|
|
|
Use.first->setOperand(Use.second, LoadedCst);
|
|
|
|
++NumPromotedUses;
|
2014-03-29 18:18:08 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
void AArch64PromoteConstant::promoteConstants(
|
|
|
|
Function &F, SmallVectorImpl<UpdateRecord> &Updates,
|
|
|
|
PromotionCacheTy &PromotionCache) {
|
|
|
|
// Promote the constants.
|
|
|
|
for (auto U = Updates.begin(), E = Updates.end(); U != E;) {
|
|
|
|
DEBUG(dbgs() << "** Compute insertion points **\n");
|
|
|
|
auto First = U;
|
|
|
|
Constant *C = First->C;
|
|
|
|
InsertionPoints InsertPts;
|
|
|
|
do {
|
|
|
|
computeInsertionPoint(U->User, U->Op, InsertPts);
|
|
|
|
} while (++U != E && U->C == C);
|
|
|
|
|
|
|
|
auto &Promotion = PromotionCache[C];
|
|
|
|
ensurePromotedGV(F, *C, Promotion);
|
|
|
|
insertDefinitions(F, *Promotion.GV, InsertPts);
|
|
|
|
}
|
2014-03-29 18:18:08 +08:00
|
|
|
}
|
|
|
|
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
bool AArch64PromoteConstant::runOnFunction(Function &F,
|
|
|
|
PromotionCacheTy &PromotionCache) {
|
2014-04-08 07:47:23 +08:00
|
|
|
// Look for instructions using constant vector. Promote that constant to a
|
|
|
|
// global variable. Create as few loads of this variable as possible and
|
|
|
|
// update the uses accordingly.
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
SmallVector<UpdateRecord, 64> Updates;
|
2015-08-07 03:10:45 +08:00
|
|
|
for (Instruction &I : instructions(&F)) {
|
2015-02-06 22:43:55 +08:00
|
|
|
// Traverse the operand, looking for constant vectors. Replace them by a
|
|
|
|
// load of a global variable of constant vector type.
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
for (Use &U : I.operands()) {
|
|
|
|
Constant *Cst = dyn_cast<Constant>(U);
|
2015-02-06 22:43:55 +08:00
|
|
|
// There is no point in promoting global values as they are already
|
|
|
|
// global. Do not promote constant expressions either, as they may
|
|
|
|
// require some code expansion.
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
if (!Cst || isa<GlobalValue>(Cst) || isa<ConstantExpr>(Cst))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Check if this constant is worth promoting.
|
|
|
|
if (!shouldConvert(*Cst, PromotionCache))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Check if this use should be promoted.
|
|
|
|
unsigned OpNo = &U - I.op_begin();
|
|
|
|
if (!shouldConvertUse(Cst, &I, OpNo))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
Updates.emplace_back(Cst, &I, OpNo);
|
2014-03-29 18:18:08 +08:00
|
|
|
}
|
|
|
|
}
|
AArch64: Don't modify other modules in AArch64PromoteConstant
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
2016-03-19 07:30:54 +08:00
|
|
|
|
|
|
|
if (Updates.empty())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
promoteConstants(F, Updates, PromotionCache);
|
|
|
|
return true;
|
2014-03-29 18:18:08 +08:00
|
|
|
}
|