2014-08-04 05:35:39 +08:00
|
|
|
//===---- MachineCombiner.cpp - Instcombining on SSA form machine code ----===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// The machine combiner pass uses machine trace metrics to ensure the combined
|
2017-03-16 05:50:46 +08:00
|
|
|
// instructions do not lengthen the critical path or the resource depth.
|
2014-08-04 05:35:39 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2015-10-07 07:24:35 +08:00
|
|
|
|
2014-08-04 05:35:39 +08:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
2016-04-18 17:17:29 +08:00
|
|
|
#include "llvm/ADT/Statistic.h"
|
2014-08-04 05:35:39 +08:00
|
|
|
#include "llvm/CodeGen/MachineDominators.h"
|
|
|
|
#include "llvm/CodeGen/MachineFunction.h"
|
|
|
|
#include "llvm/CodeGen/MachineFunctionPass.h"
|
|
|
|
#include "llvm/CodeGen/MachineLoopInfo.h"
|
|
|
|
#include "llvm/CodeGen/MachineRegisterInfo.h"
|
|
|
|
#include "llvm/CodeGen/MachineTraceMetrics.h"
|
|
|
|
#include "llvm/CodeGen/Passes.h"
|
2017-11-08 09:01:31 +08:00
|
|
|
#include "llvm/CodeGen/TargetInstrInfo.h"
|
2017-11-17 09:07:10 +08:00
|
|
|
#include "llvm/CodeGen/TargetRegisterInfo.h"
|
2014-08-04 05:35:39 +08:00
|
|
|
#include "llvm/CodeGen/TargetSchedule.h"
|
2017-11-17 09:07:10 +08:00
|
|
|
#include "llvm/CodeGen/TargetSubtargetInfo.h"
|
Recommit [MachineCombiner] Update instruction depths incrementally for large BBs.
This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.
Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.
> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619
llvm-svn: 313751
2017-09-20 19:54:37 +08:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
2014-08-04 05:35:39 +08:00
|
|
|
#include "llvm/Support/Debug.h"
|
|
|
|
#include "llvm/Support/raw_ostream.h"
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
2017-07-14 03:30:52 +08:00
|
|
|
#define DEBUG_TYPE "machine-combiner"
|
|
|
|
|
2014-08-04 05:35:39 +08:00
|
|
|
STATISTIC(NumInstCombined, "Number of machineinst combined");
|
|
|
|
|
Recommit [MachineCombiner] Update instruction depths incrementally for large BBs.
This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.
Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.
> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619
llvm-svn: 313751
2017-09-20 19:54:37 +08:00
|
|
|
static cl::opt<unsigned>
|
|
|
|
inc_threshold("machine-combiner-inc-threshold", cl::Hidden,
|
|
|
|
cl::desc("Incremental depth computation will be used for basic "
|
|
|
|
"blocks with more instructions."), cl::init(500));
|
|
|
|
|
2018-02-15 15:55:02 +08:00
|
|
|
static cl::opt<bool> dump_intrs("machine-combiner-dump-subst-intrs", cl::Hidden,
|
|
|
|
cl::desc("Dump all substituted intrs"),
|
|
|
|
cl::init(false));
|
|
|
|
|
2018-01-31 21:54:30 +08:00
|
|
|
#ifdef EXPENSIVE_CHECKS
|
|
|
|
static cl::opt<bool> VerifyPatternOrder(
|
|
|
|
"machine-combiner-verify-pattern-order", cl::Hidden,
|
|
|
|
cl::desc(
|
|
|
|
"Verify that the generated patterns are ordered by increasing latency"),
|
|
|
|
cl::init(true));
|
|
|
|
#else
|
|
|
|
static cl::opt<bool> VerifyPatternOrder(
|
|
|
|
"machine-combiner-verify-pattern-order", cl::Hidden,
|
|
|
|
cl::desc(
|
|
|
|
"Verify that the generated patterns are ordered by increasing latency"),
|
|
|
|
cl::init(false));
|
|
|
|
#endif
|
|
|
|
|
2014-08-04 05:35:39 +08:00
|
|
|
namespace {
|
|
|
|
class MachineCombiner : public MachineFunctionPass {
|
2018-02-15 15:55:02 +08:00
|
|
|
const TargetSubtargetInfo *STI;
|
2014-08-04 05:35:39 +08:00
|
|
|
const TargetInstrInfo *TII;
|
|
|
|
const TargetRegisterInfo *TRI;
|
2014-09-03 01:43:54 +08:00
|
|
|
MCSchedModel SchedModel;
|
2014-08-04 05:35:39 +08:00
|
|
|
MachineRegisterInfo *MRI;
|
2016-04-24 13:14:01 +08:00
|
|
|
MachineLoopInfo *MLI; // Current MachineLoopInfo
|
2014-08-04 05:35:39 +08:00
|
|
|
MachineTraceMetrics *Traces;
|
|
|
|
MachineTraceMetrics::Ensemble *MinInstr;
|
|
|
|
|
|
|
|
TargetSchedModel TSchedModel;
|
|
|
|
|
2015-01-28 06:26:56 +08:00
|
|
|
/// True if optimizing for code size.
|
2014-08-04 05:35:39 +08:00
|
|
|
bool OptSize;
|
|
|
|
|
|
|
|
public:
|
|
|
|
static char ID;
|
|
|
|
MachineCombiner() : MachineFunctionPass(ID) {
|
|
|
|
initializeMachineCombinerPass(*PassRegistry::getPassRegistry());
|
|
|
|
}
|
|
|
|
void getAnalysisUsage(AnalysisUsage &AU) const override;
|
|
|
|
bool runOnMachineFunction(MachineFunction &MF) override;
|
2016-10-01 10:56:57 +08:00
|
|
|
StringRef getPassName() const override { return "Machine InstCombiner"; }
|
2014-08-04 05:35:39 +08:00
|
|
|
|
|
|
|
private:
|
|
|
|
bool doSubstitute(unsigned NewSize, unsigned OldSize);
|
|
|
|
bool combineInstructions(MachineBasicBlock *);
|
|
|
|
MachineInstr *getOperandDef(const MachineOperand &MO);
|
|
|
|
unsigned getDepth(SmallVectorImpl<MachineInstr *> &InsInstrs,
|
|
|
|
DenseMap<unsigned, unsigned> &InstrIdxForVirtReg,
|
|
|
|
MachineTraceMetrics::Trace BlockTrace);
|
|
|
|
unsigned getLatency(MachineInstr *Root, MachineInstr *NewRoot,
|
|
|
|
MachineTraceMetrics::Trace BlockTrace);
|
|
|
|
bool
|
2015-06-23 08:39:40 +08:00
|
|
|
improvesCriticalPathLen(MachineBasicBlock *MBB, MachineInstr *Root,
|
2015-11-11 00:48:53 +08:00
|
|
|
MachineTraceMetrics::Trace BlockTrace,
|
|
|
|
SmallVectorImpl<MachineInstr *> &InsInstrs,
|
2016-12-12 03:39:32 +08:00
|
|
|
SmallVectorImpl<MachineInstr *> &DelInstrs,
|
2015-11-11 00:48:53 +08:00
|
|
|
DenseMap<unsigned, unsigned> &InstrIdxForVirtReg,
|
Recommit [MachineCombiner] Update instruction depths incrementally for large BBs.
This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.
Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.
> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619
llvm-svn: 313751
2017-09-20 19:54:37 +08:00
|
|
|
MachineCombinerPattern Pattern, bool SlackIsAccurate);
|
2014-08-04 05:35:39 +08:00
|
|
|
bool preservesResourceLen(MachineBasicBlock *MBB,
|
|
|
|
MachineTraceMetrics::Trace BlockTrace,
|
|
|
|
SmallVectorImpl<MachineInstr *> &InsInstrs,
|
|
|
|
SmallVectorImpl<MachineInstr *> &DelInstrs);
|
|
|
|
void instr2instrSC(SmallVectorImpl<MachineInstr *> &Instrs,
|
|
|
|
SmallVectorImpl<const MCSchedClassDesc *> &InstrsSC);
|
2018-01-31 21:54:30 +08:00
|
|
|
std::pair<unsigned, unsigned>
|
|
|
|
getLatenciesForInstrSequences(MachineInstr &MI,
|
|
|
|
SmallVectorImpl<MachineInstr *> &InsInstrs,
|
|
|
|
SmallVectorImpl<MachineInstr *> &DelInstrs,
|
|
|
|
MachineTraceMetrics::Trace BlockTrace);
|
|
|
|
|
|
|
|
void verifyPatternOrder(MachineBasicBlock *MBB, MachineInstr &Root,
|
|
|
|
SmallVector<MachineCombinerPattern, 16> &Patterns);
|
2014-08-04 05:35:39 +08:00
|
|
|
};
|
2015-06-23 17:49:53 +08:00
|
|
|
}
|
2014-08-04 05:35:39 +08:00
|
|
|
|
|
|
|
char MachineCombiner::ID = 0;
|
|
|
|
char &llvm::MachineCombinerID = MachineCombiner::ID;
|
|
|
|
|
2017-05-26 05:26:32 +08:00
|
|
|
INITIALIZE_PASS_BEGIN(MachineCombiner, DEBUG_TYPE,
|
2014-08-04 05:35:39 +08:00
|
|
|
"Machine InstCombiner", false, false)
|
2016-04-24 13:14:01 +08:00
|
|
|
INITIALIZE_PASS_DEPENDENCY(MachineLoopInfo)
|
2014-08-04 05:35:39 +08:00
|
|
|
INITIALIZE_PASS_DEPENDENCY(MachineTraceMetrics)
|
2017-05-26 05:26:32 +08:00
|
|
|
INITIALIZE_PASS_END(MachineCombiner, DEBUG_TYPE, "Machine InstCombiner",
|
2014-08-04 05:35:39 +08:00
|
|
|
false, false)
|
|
|
|
|
|
|
|
void MachineCombiner::getAnalysisUsage(AnalysisUsage &AU) const {
|
|
|
|
AU.setPreservesCFG();
|
|
|
|
AU.addPreserved<MachineDominatorTree>();
|
2016-04-24 13:14:01 +08:00
|
|
|
AU.addRequired<MachineLoopInfo>();
|
2014-08-04 05:35:39 +08:00
|
|
|
AU.addPreserved<MachineLoopInfo>();
|
|
|
|
AU.addRequired<MachineTraceMetrics>();
|
|
|
|
AU.addPreserved<MachineTraceMetrics>();
|
|
|
|
MachineFunctionPass::getAnalysisUsage(AU);
|
|
|
|
}
|
|
|
|
|
|
|
|
MachineInstr *MachineCombiner::getOperandDef(const MachineOperand &MO) {
|
|
|
|
MachineInstr *DefInstr = nullptr;
|
|
|
|
// We need a virtual register definition.
|
|
|
|
if (MO.isReg() && TargetRegisterInfo::isVirtualRegister(MO.getReg()))
|
|
|
|
DefInstr = MRI->getUniqueVRegDef(MO.getReg());
|
|
|
|
// PHI's have no depth etc.
|
|
|
|
if (DefInstr && DefInstr->isPHI())
|
|
|
|
DefInstr = nullptr;
|
|
|
|
return DefInstr;
|
|
|
|
}
|
|
|
|
|
2015-01-28 06:26:56 +08:00
|
|
|
/// Computes depth of instructions in vector \InsInstr.
|
2014-08-04 05:35:39 +08:00
|
|
|
///
|
|
|
|
/// \param InsInstrs is a vector of machine instructions
|
|
|
|
/// \param InstrIdxForVirtReg is a dense map of virtual register to index
|
|
|
|
/// of defining machine instruction in \p InsInstrs
|
|
|
|
/// \param BlockTrace is a trace of machine instructions
|
|
|
|
///
|
|
|
|
/// \returns Depth of last instruction in \InsInstrs ("NewRoot")
|
|
|
|
unsigned
|
|
|
|
MachineCombiner::getDepth(SmallVectorImpl<MachineInstr *> &InsInstrs,
|
|
|
|
DenseMap<unsigned, unsigned> &InstrIdxForVirtReg,
|
|
|
|
MachineTraceMetrics::Trace BlockTrace) {
|
|
|
|
SmallVector<unsigned, 16> InstrDepth;
|
2015-07-15 16:22:23 +08:00
|
|
|
assert(TSchedModel.hasInstrSchedModelOrItineraries() &&
|
|
|
|
"Missing machine model\n");
|
2014-08-04 05:35:39 +08:00
|
|
|
|
2015-01-28 06:16:52 +08:00
|
|
|
// For each instruction in the new sequence compute the depth based on the
|
2014-08-04 05:35:39 +08:00
|
|
|
// operands. Use the trace information when possible. For new operands which
|
|
|
|
// are tracked in the InstrIdxForVirtReg map depth is looked up in InstrDepth
|
|
|
|
for (auto *InstrPtr : InsInstrs) { // for each Use
|
|
|
|
unsigned IDepth = 0;
|
2015-05-22 01:43:26 +08:00
|
|
|
for (const MachineOperand &MO : InstrPtr->operands()) {
|
2014-08-04 05:35:39 +08:00
|
|
|
// Check for virtual register operand.
|
|
|
|
if (!(MO.isReg() && TargetRegisterInfo::isVirtualRegister(MO.getReg())))
|
|
|
|
continue;
|
|
|
|
if (!MO.isUse())
|
|
|
|
continue;
|
|
|
|
unsigned DepthOp = 0;
|
|
|
|
unsigned LatencyOp = 0;
|
|
|
|
DenseMap<unsigned, unsigned>::iterator II =
|
|
|
|
InstrIdxForVirtReg.find(MO.getReg());
|
|
|
|
if (II != InstrIdxForVirtReg.end()) {
|
|
|
|
// Operand is new virtual register not in trace
|
2014-08-04 07:00:38 +08:00
|
|
|
assert(II->second < InstrDepth.size() && "Bad Index");
|
2014-08-04 05:35:39 +08:00
|
|
|
MachineInstr *DefInstr = InsInstrs[II->second];
|
|
|
|
assert(DefInstr &&
|
|
|
|
"There must be a definition for a new virtual register");
|
|
|
|
DepthOp = InstrDepth[II->second];
|
2017-10-31 01:24:40 +08:00
|
|
|
int DefIdx = DefInstr->findRegisterDefOperandIdx(MO.getReg());
|
|
|
|
int UseIdx = InstrPtr->findRegisterUseOperandIdx(MO.getReg());
|
|
|
|
LatencyOp = TSchedModel.computeOperandLatency(DefInstr, DefIdx,
|
|
|
|
InstrPtr, UseIdx);
|
2014-08-04 05:35:39 +08:00
|
|
|
} else {
|
|
|
|
MachineInstr *DefInstr = getOperandDef(MO);
|
|
|
|
if (DefInstr) {
|
2016-02-22 11:33:28 +08:00
|
|
|
DepthOp = BlockTrace.getInstrCycles(*DefInstr).Depth;
|
2014-08-04 05:35:39 +08:00
|
|
|
LatencyOp = TSchedModel.computeOperandLatency(
|
|
|
|
DefInstr, DefInstr->findRegisterDefOperandIdx(MO.getReg()),
|
|
|
|
InstrPtr, InstrPtr->findRegisterUseOperandIdx(MO.getReg()));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
IDepth = std::max(IDepth, DepthOp + LatencyOp);
|
|
|
|
}
|
|
|
|
InstrDepth.push_back(IDepth);
|
|
|
|
}
|
|
|
|
unsigned NewRootIdx = InsInstrs.size() - 1;
|
|
|
|
return InstrDepth[NewRootIdx];
|
|
|
|
}
|
|
|
|
|
2015-01-28 06:26:56 +08:00
|
|
|
/// Computes instruction latency as max of latency of defined operands.
|
2014-08-04 05:35:39 +08:00
|
|
|
///
|
|
|
|
/// \param Root is a machine instruction that could be replaced by NewRoot.
|
|
|
|
/// It is used to compute a more accurate latency information for NewRoot in
|
|
|
|
/// case there is a dependent instruction in the same trace (\p BlockTrace)
|
|
|
|
/// \param NewRoot is the instruction for which the latency is computed
|
|
|
|
/// \param BlockTrace is a trace of machine instructions
|
|
|
|
///
|
|
|
|
/// \returns Latency of \p NewRoot
|
|
|
|
unsigned MachineCombiner::getLatency(MachineInstr *Root, MachineInstr *NewRoot,
|
|
|
|
MachineTraceMetrics::Trace BlockTrace) {
|
2015-07-15 16:22:23 +08:00
|
|
|
assert(TSchedModel.hasInstrSchedModelOrItineraries() &&
|
|
|
|
"Missing machine model\n");
|
2014-08-04 05:35:39 +08:00
|
|
|
|
|
|
|
// Check each definition in NewRoot and compute the latency
|
|
|
|
unsigned NewRootLatency = 0;
|
|
|
|
|
2015-05-22 01:43:26 +08:00
|
|
|
for (const MachineOperand &MO : NewRoot->operands()) {
|
2014-08-04 05:35:39 +08:00
|
|
|
// Check for virtual register operand.
|
|
|
|
if (!(MO.isReg() && TargetRegisterInfo::isVirtualRegister(MO.getReg())))
|
|
|
|
continue;
|
|
|
|
if (!MO.isDef())
|
|
|
|
continue;
|
|
|
|
// Get the first instruction that uses MO
|
|
|
|
MachineRegisterInfo::reg_iterator RI = MRI->reg_begin(MO.getReg());
|
|
|
|
RI++;
|
|
|
|
MachineInstr *UseMO = RI->getParent();
|
|
|
|
unsigned LatencyOp = 0;
|
2016-02-22 11:33:28 +08:00
|
|
|
if (UseMO && BlockTrace.isDepInTrace(*Root, *UseMO)) {
|
2014-08-04 05:35:39 +08:00
|
|
|
LatencyOp = TSchedModel.computeOperandLatency(
|
|
|
|
NewRoot, NewRoot->findRegisterDefOperandIdx(MO.getReg()), UseMO,
|
|
|
|
UseMO->findRegisterUseOperandIdx(MO.getReg()));
|
|
|
|
} else {
|
2015-08-05 15:45:28 +08:00
|
|
|
LatencyOp = TSchedModel.computeInstrLatency(NewRoot);
|
2014-08-04 05:35:39 +08:00
|
|
|
}
|
|
|
|
NewRootLatency = std::max(NewRootLatency, LatencyOp);
|
|
|
|
}
|
|
|
|
return NewRootLatency;
|
|
|
|
}
|
|
|
|
|
2015-11-11 00:48:53 +08:00
|
|
|
/// The combiner's goal may differ based on which pattern it is attempting
|
|
|
|
/// to optimize.
|
|
|
|
enum class CombinerObjective {
|
|
|
|
MustReduceDepth, // The data dependency chain must be improved.
|
|
|
|
Default // The critical path must not be lengthened.
|
|
|
|
};
|
|
|
|
|
|
|
|
static CombinerObjective getCombinerObjective(MachineCombinerPattern P) {
|
|
|
|
// TODO: If C++ ever gets a real enum class, make this part of the
|
|
|
|
// MachineCombinerPattern class.
|
|
|
|
switch (P) {
|
|
|
|
case MachineCombinerPattern::REASSOC_AX_BY:
|
|
|
|
case MachineCombinerPattern::REASSOC_AX_YB:
|
|
|
|
case MachineCombinerPattern::REASSOC_XA_BY:
|
|
|
|
case MachineCombinerPattern::REASSOC_XA_YB:
|
|
|
|
return CombinerObjective::MustReduceDepth;
|
|
|
|
default:
|
|
|
|
return CombinerObjective::Default;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-01-31 21:54:30 +08:00
|
|
|
/// Estimate the latency of the new and original instruction sequence by summing
|
|
|
|
/// up the latencies of the inserted and deleted instructions. This assumes
|
|
|
|
/// that the inserted and deleted instructions are dependent instruction chains,
|
|
|
|
/// which might not hold in all cases.
|
|
|
|
std::pair<unsigned, unsigned> MachineCombiner::getLatenciesForInstrSequences(
|
|
|
|
MachineInstr &MI, SmallVectorImpl<MachineInstr *> &InsInstrs,
|
|
|
|
SmallVectorImpl<MachineInstr *> &DelInstrs,
|
|
|
|
MachineTraceMetrics::Trace BlockTrace) {
|
|
|
|
assert(!InsInstrs.empty() && "Only support sequences that insert instrs.");
|
|
|
|
unsigned NewRootLatency = 0;
|
|
|
|
// NewRoot is the last instruction in the \p InsInstrs vector.
|
|
|
|
MachineInstr *NewRoot = InsInstrs.back();
|
|
|
|
for (unsigned i = 0; i < InsInstrs.size() - 1; i++)
|
|
|
|
NewRootLatency += TSchedModel.computeInstrLatency(InsInstrs[i]);
|
|
|
|
NewRootLatency += getLatency(&MI, NewRoot, BlockTrace);
|
|
|
|
|
|
|
|
unsigned RootLatency = 0;
|
|
|
|
for (auto I : DelInstrs)
|
|
|
|
RootLatency += TSchedModel.computeInstrLatency(I);
|
|
|
|
|
|
|
|
return {NewRootLatency, RootLatency};
|
|
|
|
}
|
|
|
|
|
2015-06-23 08:39:40 +08:00
|
|
|
/// The DAGCombine code sequence ends in MI (Machine Instruction) Root.
|
|
|
|
/// The new code sequence ends in MI NewRoot. A necessary condition for the new
|
|
|
|
/// sequence to replace the old sequence is that it cannot lengthen the critical
|
2015-11-11 00:48:53 +08:00
|
|
|
/// path. The definition of "improve" may be restricted by specifying that the
|
|
|
|
/// new path improves the data dependency chain (MustReduceDepth).
|
2015-06-23 08:39:40 +08:00
|
|
|
bool MachineCombiner::improvesCriticalPathLen(
|
2014-08-04 05:35:39 +08:00
|
|
|
MachineBasicBlock *MBB, MachineInstr *Root,
|
|
|
|
MachineTraceMetrics::Trace BlockTrace,
|
|
|
|
SmallVectorImpl<MachineInstr *> &InsInstrs,
|
2016-12-12 03:39:32 +08:00
|
|
|
SmallVectorImpl<MachineInstr *> &DelInstrs,
|
2015-06-23 08:39:40 +08:00
|
|
|
DenseMap<unsigned, unsigned> &InstrIdxForVirtReg,
|
Recommit [MachineCombiner] Update instruction depths incrementally for large BBs.
This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.
Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.
> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619
llvm-svn: 313751
2017-09-20 19:54:37 +08:00
|
|
|
MachineCombinerPattern Pattern,
|
|
|
|
bool SlackIsAccurate) {
|
2015-07-15 16:22:23 +08:00
|
|
|
assert(TSchedModel.hasInstrSchedModelOrItineraries() &&
|
|
|
|
"Missing machine model\n");
|
2015-11-11 00:48:53 +08:00
|
|
|
// Get depth and latency of NewRoot and Root.
|
|
|
|
unsigned NewRootDepth = getDepth(InsInstrs, InstrIdxForVirtReg, BlockTrace);
|
2016-02-22 11:33:28 +08:00
|
|
|
unsigned RootDepth = BlockTrace.getInstrCycles(*Root).Depth;
|
2015-11-11 00:48:53 +08:00
|
|
|
|
2018-02-15 15:55:02 +08:00
|
|
|
DEBUG(dbgs() << " Dependence data for " << *Root << "\tNewRootDepth: "
|
|
|
|
<< NewRootDepth << "\tRootDepth: " << RootDepth);
|
2015-11-11 00:48:53 +08:00
|
|
|
|
|
|
|
// For a transform such as reassociation, the cost equation is
|
|
|
|
// conservatively calculated so that we must improve the depth (data
|
|
|
|
// dependency cycles) in the critical path to proceed with the transform.
|
|
|
|
// Being conservative also protects against inaccuracies in the underlying
|
|
|
|
// machine trace metrics and CPU models.
|
2018-02-15 15:55:02 +08:00
|
|
|
if (getCombinerObjective(Pattern) == CombinerObjective::MustReduceDepth) {
|
|
|
|
DEBUG(dbgs() << "\tIt MustReduceDepth ");
|
|
|
|
DEBUG(NewRootDepth < RootDepth ? dbgs() << "\t and it does it\n"
|
|
|
|
: dbgs() << "\t but it does NOT do it\n");
|
2015-11-11 00:48:53 +08:00
|
|
|
return NewRootDepth < RootDepth;
|
2018-02-15 15:55:02 +08:00
|
|
|
}
|
2015-11-11 00:48:53 +08:00
|
|
|
|
|
|
|
// A more flexible cost calculation for the critical path includes the slack
|
|
|
|
// of the original code sequence. This may allow the transform to proceed
|
|
|
|
// even if the instruction depths (data dependency cycles) become worse.
|
2016-12-12 03:39:32 +08:00
|
|
|
|
[MachineCombiner] Add up latencies of all instructions in new pattern.
Summary:
When calculating the RootLatency, we add up all the latencies of the
deleted instructions. But for NewRootLatency we only add the latency of
the new root instructions, ignoring the latencies of the other
instructions inserted. This leads the combiner to underestimate the cost
of patterns which add multiple instructions. This patch fixes that by
summing up the latencies of all new instructions. For NewRootNode, the
more complex getLatency function is used.
Note that we may be slightly more precise than just summing up
all latencies. For example, consider a pattern like
r1 = INS1 ..
r2 = INS2 ..
r3 = INS3 r1, r2
I think in some other places, the total latency of the pattern would be
estimated as lat(INS3) + max(lat(INS1), lat(INS2)). If you consider
that worth changing, I think it would be best to do in a follow-up
patch.
Reviewers: Gerolf, sebpop, spop, fhahn
Reviewed By: fhahn
Subscribers: evandro, llvm-commits
Differential Revision: https://reviews.llvm.org/D40307
llvm-svn: 319951
2017-12-07 04:27:33 +08:00
|
|
|
// Account for the latency of the inserted and deleted instructions by
|
2018-01-31 21:54:30 +08:00
|
|
|
unsigned NewRootLatency, RootLatency;
|
|
|
|
std::tie(NewRootLatency, RootLatency) =
|
|
|
|
getLatenciesForInstrSequences(*Root, InsInstrs, DelInstrs, BlockTrace);
|
2016-12-12 03:39:32 +08:00
|
|
|
|
2016-02-22 11:33:28 +08:00
|
|
|
unsigned RootSlack = BlockTrace.getInstrSlack(*Root);
|
Recommit [MachineCombiner] Update instruction depths incrementally for large BBs.
This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.
Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.
> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619
llvm-svn: 313751
2017-09-20 19:54:37 +08:00
|
|
|
unsigned NewCycleCount = NewRootDepth + NewRootLatency;
|
2018-02-15 15:55:02 +08:00
|
|
|
unsigned OldCycleCount =
|
|
|
|
RootDepth + RootLatency + (SlackIsAccurate ? RootSlack : 0);
|
|
|
|
DEBUG(dbgs() << "\n\tNewRootLatency: " << NewRootLatency << "\tRootLatency: "
|
|
|
|
<< RootLatency << "\n\tRootSlack: " << RootSlack
|
|
|
|
<< " SlackIsAccurate=" << SlackIsAccurate
|
|
|
|
<< "\n\tNewRootDepth + NewRootLatency = " << NewCycleCount
|
|
|
|
<< "\n\tRootDepth + RootLatency + RootSlack = "
|
|
|
|
<< OldCycleCount;);
|
|
|
|
DEBUG(NewCycleCount <= OldCycleCount
|
|
|
|
? dbgs() << "\n\t It IMPROVES PathLen because"
|
|
|
|
: dbgs() << "\n\t It DOES NOT improve PathLen because");
|
|
|
|
DEBUG(dbgs() << "\n\t\tNewCycleCount = " << NewCycleCount
|
|
|
|
<< ", OldCycleCount = " << OldCycleCount << "\n");
|
2016-02-27 09:10:43 +08:00
|
|
|
|
2015-11-11 00:48:53 +08:00
|
|
|
return NewCycleCount <= OldCycleCount;
|
2014-08-04 05:35:39 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// helper routine to convert instructions into SC
|
|
|
|
void MachineCombiner::instr2instrSC(
|
|
|
|
SmallVectorImpl<MachineInstr *> &Instrs,
|
|
|
|
SmallVectorImpl<const MCSchedClassDesc *> &InstrsSC) {
|
|
|
|
for (auto *InstrPtr : Instrs) {
|
|
|
|
unsigned Opc = InstrPtr->getOpcode();
|
|
|
|
unsigned Idx = TII->get(Opc).getSchedClass();
|
2014-09-03 01:43:54 +08:00
|
|
|
const MCSchedClassDesc *SC = SchedModel.getSchedClassDesc(Idx);
|
2014-08-04 05:35:39 +08:00
|
|
|
InstrsSC.push_back(SC);
|
|
|
|
}
|
|
|
|
}
|
2015-10-07 07:24:35 +08:00
|
|
|
|
2015-01-28 06:26:56 +08:00
|
|
|
/// True when the new instructions do not increase resource length
|
2014-08-04 05:35:39 +08:00
|
|
|
bool MachineCombiner::preservesResourceLen(
|
|
|
|
MachineBasicBlock *MBB, MachineTraceMetrics::Trace BlockTrace,
|
|
|
|
SmallVectorImpl<MachineInstr *> &InsInstrs,
|
|
|
|
SmallVectorImpl<MachineInstr *> &DelInstrs) {
|
2015-07-15 16:22:23 +08:00
|
|
|
if (!TSchedModel.hasInstrSchedModel())
|
|
|
|
return true;
|
2014-08-04 05:35:39 +08:00
|
|
|
|
|
|
|
// Compute current resource length
|
|
|
|
|
2014-08-08 05:40:58 +08:00
|
|
|
//ArrayRef<const MachineBasicBlock *> MBBarr(MBB);
|
|
|
|
SmallVector <const MachineBasicBlock *, 1> MBBarr;
|
|
|
|
MBBarr.push_back(MBB);
|
2014-08-04 05:35:39 +08:00
|
|
|
unsigned ResLenBeforeCombine = BlockTrace.getResourceLength(MBBarr);
|
|
|
|
|
|
|
|
// Deal with SC rather than Instructions.
|
|
|
|
SmallVector<const MCSchedClassDesc *, 16> InsInstrsSC;
|
|
|
|
SmallVector<const MCSchedClassDesc *, 16> DelInstrsSC;
|
|
|
|
|
|
|
|
instr2instrSC(InsInstrs, InsInstrsSC);
|
|
|
|
instr2instrSC(DelInstrs, DelInstrsSC);
|
|
|
|
|
|
|
|
ArrayRef<const MCSchedClassDesc *> MSCInsArr = makeArrayRef(InsInstrsSC);
|
|
|
|
ArrayRef<const MCSchedClassDesc *> MSCDelArr = makeArrayRef(DelInstrsSC);
|
|
|
|
|
2015-06-11 03:52:58 +08:00
|
|
|
// Compute new resource length.
|
2014-08-04 05:35:39 +08:00
|
|
|
unsigned ResLenAfterCombine =
|
|
|
|
BlockTrace.getResourceLength(MBBarr, MSCInsArr, MSCDelArr);
|
|
|
|
|
2018-02-15 15:55:02 +08:00
|
|
|
DEBUG(dbgs() << "\t\tResource length before replacement: "
|
|
|
|
<< ResLenBeforeCombine << " and after: " << ResLenAfterCombine
|
|
|
|
<< "\n";);
|
|
|
|
DEBUG(
|
|
|
|
ResLenAfterCombine <= ResLenBeforeCombine
|
|
|
|
? dbgs() << "\t\t As result it IMPROVES/PRESERVES Resource Length\n"
|
|
|
|
: dbgs() << "\t\t As result it DOES NOT improve/preserve Resource "
|
|
|
|
"Length\n");
|
2014-08-04 05:35:39 +08:00
|
|
|
|
|
|
|
return ResLenAfterCombine <= ResLenBeforeCombine;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \returns true when new instruction sequence should be generated
|
2015-01-28 06:16:52 +08:00
|
|
|
/// independent if it lengthens critical path or not
|
2014-08-04 05:35:39 +08:00
|
|
|
bool MachineCombiner::doSubstitute(unsigned NewSize, unsigned OldSize) {
|
2018-03-17 04:11:55 +08:00
|
|
|
if (OptSize && (NewSize < OldSize))
|
|
|
|
return true;
|
2015-07-15 16:22:23 +08:00
|
|
|
if (!TSchedModel.hasInstrSchedModelOrItineraries())
|
2014-08-04 05:35:39 +08:00
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
Recommit [MachineCombiner] Update instruction depths incrementally for large BBs.
This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.
Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.
> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619
llvm-svn: 313751
2017-09-20 19:54:37 +08:00
|
|
|
/// Inserts InsInstrs and deletes DelInstrs. Incrementally updates instruction
|
|
|
|
/// depths if requested.
|
|
|
|
///
|
|
|
|
/// \param MBB basic block to insert instructions in
|
|
|
|
/// \param MI current machine instruction
|
|
|
|
/// \param InsInstrs new instructions to insert in \p MBB
|
|
|
|
/// \param DelInstrs instruction to delete from \p MBB
|
|
|
|
/// \param MinInstr is a pointer to the machine trace information
|
|
|
|
/// \param RegUnits set of live registers, needed to compute instruction depths
|
|
|
|
/// \param IncrementalUpdate if true, compute instruction depths incrementally,
|
|
|
|
/// otherwise invalidate the trace
|
2017-02-13 17:43:37 +08:00
|
|
|
static void insertDeleteInstructions(MachineBasicBlock *MBB, MachineInstr &MI,
|
|
|
|
SmallVector<MachineInstr *, 16> InsInstrs,
|
|
|
|
SmallVector<MachineInstr *, 16> DelInstrs,
|
Recommit [MachineCombiner] Update instruction depths incrementally for large BBs.
This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.
Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.
> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619
llvm-svn: 313751
2017-09-20 19:54:37 +08:00
|
|
|
MachineTraceMetrics::Ensemble *MinInstr,
|
|
|
|
SparseSet<LiveRegUnit> &RegUnits,
|
|
|
|
bool IncrementalUpdate) {
|
2017-02-13 17:43:37 +08:00
|
|
|
for (auto *InstrPtr : InsInstrs)
|
|
|
|
MBB->insert((MachineBasicBlock::iterator)&MI, InstrPtr);
|
Recommit [MachineCombiner] Update instruction depths incrementally for large BBs.
This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.
Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.
> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619
llvm-svn: 313751
2017-09-20 19:54:37 +08:00
|
|
|
|
|
|
|
for (auto *InstrPtr : DelInstrs) {
|
2017-02-13 17:43:37 +08:00
|
|
|
InstrPtr->eraseFromParentAndMarkDBGValuesForRemoval();
|
Recommit [MachineCombiner] Update instruction depths incrementally for large BBs.
This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.
Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.
> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619
llvm-svn: 313751
2017-09-20 19:54:37 +08:00
|
|
|
// Erase all LiveRegs defined by the removed instruction
|
|
|
|
for (auto I = RegUnits.begin(); I != RegUnits.end(); ) {
|
|
|
|
if (I->MI == InstrPtr)
|
|
|
|
I = RegUnits.erase(I);
|
|
|
|
else
|
|
|
|
I++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (IncrementalUpdate)
|
|
|
|
for (auto *InstrPtr : InsInstrs)
|
|
|
|
MinInstr->updateDepth(MBB, *InstrPtr, RegUnits);
|
|
|
|
else
|
|
|
|
MinInstr->invalidate(MBB);
|
|
|
|
|
|
|
|
NumInstCombined++;
|
2017-02-13 17:43:37 +08:00
|
|
|
}
|
|
|
|
|
2018-01-31 21:54:30 +08:00
|
|
|
// Check that the difference between original and new latency is decreasing for
|
|
|
|
// later patterns. This helps to discover sub-optimal pattern orderings.
|
|
|
|
void MachineCombiner::verifyPatternOrder(
|
|
|
|
MachineBasicBlock *MBB, MachineInstr &Root,
|
|
|
|
SmallVector<MachineCombinerPattern, 16> &Patterns) {
|
|
|
|
long PrevLatencyDiff = std::numeric_limits<long>::max();
|
2018-02-06 17:53:02 +08:00
|
|
|
(void)PrevLatencyDiff; // Variable is used in assert only.
|
2018-01-31 21:54:30 +08:00
|
|
|
for (auto P : Patterns) {
|
|
|
|
SmallVector<MachineInstr *, 16> InsInstrs;
|
|
|
|
SmallVector<MachineInstr *, 16> DelInstrs;
|
|
|
|
DenseMap<unsigned, unsigned> InstrIdxForVirtReg;
|
|
|
|
TII->genAlternativeCodeSequence(Root, P, InsInstrs, DelInstrs,
|
|
|
|
InstrIdxForVirtReg);
|
|
|
|
// Found pattern, but did not generate alternative sequence.
|
|
|
|
// This can happen e.g. when an immediate could not be materialized
|
|
|
|
// in a single instruction.
|
|
|
|
if (InsInstrs.empty() || !TSchedModel.hasInstrSchedModelOrItineraries())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
unsigned NewRootLatency, RootLatency;
|
|
|
|
std::tie(NewRootLatency, RootLatency) = getLatenciesForInstrSequences(
|
|
|
|
Root, InsInstrs, DelInstrs, MinInstr->getTrace(MBB));
|
|
|
|
long CurrentLatencyDiff = ((long)RootLatency) - ((long)NewRootLatency);
|
|
|
|
assert(CurrentLatencyDiff <= PrevLatencyDiff &&
|
|
|
|
"Current pattern is better than previous pattern.");
|
|
|
|
PrevLatencyDiff = CurrentLatencyDiff;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-01-28 06:26:56 +08:00
|
|
|
/// Substitute a slow code sequence with a faster one by
|
2014-08-04 05:35:39 +08:00
|
|
|
/// evaluating instruction combining pattern.
|
|
|
|
/// The prototype of such a pattern is MUl + ADD -> MADD. Performs instruction
|
|
|
|
/// combining based on machine trace metrics. Only combine a sequence of
|
|
|
|
/// instructions when this neither lengthens the critical path nor increases
|
|
|
|
/// resource pressure. When optimizing for codesize always combine when the new
|
|
|
|
/// sequence is shorter.
|
|
|
|
bool MachineCombiner::combineInstructions(MachineBasicBlock *MBB) {
|
|
|
|
bool Changed = false;
|
|
|
|
DEBUG(dbgs() << "Combining MBB " << MBB->getName() << "\n");
|
|
|
|
|
Recommit [MachineCombiner] Update instruction depths incrementally for large BBs.
This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.
Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.
> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619
llvm-svn: 313751
2017-09-20 19:54:37 +08:00
|
|
|
bool IncrementalUpdate = false;
|
2014-08-04 05:35:39 +08:00
|
|
|
auto BlockIter = MBB->begin();
|
2017-10-12 04:25:58 +08:00
|
|
|
decltype(BlockIter) LastUpdate;
|
2016-04-24 13:14:01 +08:00
|
|
|
// Check if the block is in a loop.
|
|
|
|
const MachineLoop *ML = MLI->getLoopFor(MBB);
|
Recommit [MachineCombiner] Update instruction depths incrementally for large BBs.
This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.
Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.
> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619
llvm-svn: 313751
2017-09-20 19:54:37 +08:00
|
|
|
if (!MinInstr)
|
|
|
|
MinInstr = Traces->getEnsemble(MachineTraceMetrics::TS_MinInstrCount);
|
|
|
|
|
|
|
|
SparseSet<LiveRegUnit> RegUnits;
|
|
|
|
RegUnits.setUniverse(TRI->getNumRegUnits());
|
2014-08-04 05:35:39 +08:00
|
|
|
|
|
|
|
while (BlockIter != MBB->end()) {
|
|
|
|
auto &MI = *BlockIter++;
|
2015-11-06 03:34:57 +08:00
|
|
|
SmallVector<MachineCombinerPattern, 16> Patterns;
|
2014-08-04 05:35:39 +08:00
|
|
|
// The motivating example is:
|
|
|
|
//
|
|
|
|
// MUL Other MUL_op1 MUL_op2 Other
|
|
|
|
// \ / \ | /
|
|
|
|
// ADD/SUB => MADD/MSUB
|
|
|
|
// (=Root) (=NewRoot)
|
|
|
|
|
|
|
|
// The DAGCombine code always replaced MUL + ADD/SUB by MADD. While this is
|
|
|
|
// usually beneficial for code size it unfortunately can hurt performance
|
|
|
|
// when the ADD is on the critical path, but the MUL is not. With the
|
|
|
|
// substitution the MUL becomes part of the critical path (in form of the
|
|
|
|
// MADD) and can lengthen it on architectures where the MADD latency is
|
|
|
|
// longer than the ADD latency.
|
|
|
|
//
|
|
|
|
// For each instruction we check if it can be the root of a combiner
|
|
|
|
// pattern. Then for each pattern the new code sequence in form of MI is
|
|
|
|
// generated and evaluated. When the efficiency criteria (don't lengthen
|
|
|
|
// critical path, don't use more resources) is met the new sequence gets
|
|
|
|
// hooked up into the basic block before the old sequence is removed.
|
|
|
|
//
|
|
|
|
// The algorithm does not try to evaluate all patterns and pick the best.
|
|
|
|
// This is only an artificial restriction though. In practice there is
|
2015-06-20 07:21:42 +08:00
|
|
|
// mostly one pattern, and getMachineCombinerPatterns() can order patterns
|
2018-01-31 21:54:30 +08:00
|
|
|
// based on an internal cost heuristic. If
|
|
|
|
// machine-combiner-verify-pattern-order is enabled, all patterns are
|
|
|
|
// checked to ensure later patterns do not provide better latency savings.
|
2014-08-04 05:35:39 +08:00
|
|
|
|
2015-11-11 04:09:02 +08:00
|
|
|
if (!TII->getMachineCombinerPatterns(MI, Patterns))
|
|
|
|
continue;
|
|
|
|
|
2018-01-31 21:54:30 +08:00
|
|
|
if (VerifyPatternOrder)
|
|
|
|
verifyPatternOrder(MBB, MI, Patterns);
|
|
|
|
|
2015-11-11 04:09:02 +08:00
|
|
|
for (auto P : Patterns) {
|
|
|
|
SmallVector<MachineInstr *, 16> InsInstrs;
|
|
|
|
SmallVector<MachineInstr *, 16> DelInstrs;
|
|
|
|
DenseMap<unsigned, unsigned> InstrIdxForVirtReg;
|
|
|
|
TII->genAlternativeCodeSequence(MI, P, InsInstrs, DelInstrs,
|
|
|
|
InstrIdxForVirtReg);
|
|
|
|
unsigned NewInstCount = InsInstrs.size();
|
|
|
|
unsigned OldInstCount = DelInstrs.size();
|
|
|
|
// Found pattern, but did not generate alternative sequence.
|
|
|
|
// This can happen e.g. when an immediate could not be materialized
|
|
|
|
// in a single instruction.
|
|
|
|
if (!NewInstCount)
|
|
|
|
continue;
|
|
|
|
|
2018-02-15 15:55:02 +08:00
|
|
|
DEBUG(if (dump_intrs) {
|
|
|
|
dbgs() << "\tFor the Pattern (" << (int)P << ") these instructions could be removed\n";
|
|
|
|
for (auto const *InstrPtr : DelInstrs) {
|
|
|
|
dbgs() << "\t\t" << STI->getSchedInfoStr(*InstrPtr) << ": ";
|
2018-02-26 17:43:21 +08:00
|
|
|
InstrPtr->print(dbgs(), false, false, false, TII);
|
2018-02-15 15:55:02 +08:00
|
|
|
}
|
|
|
|
dbgs() << "\tThese instructions could replace the removed ones\n";
|
|
|
|
for (auto const *InstrPtr : InsInstrs) {
|
|
|
|
dbgs() << "\t\t" << STI->getSchedInfoStr(*InstrPtr) << ": ";
|
2018-02-26 17:43:21 +08:00
|
|
|
InstrPtr->print(dbgs(), false, false, false, TII);
|
2018-02-15 15:55:02 +08:00
|
|
|
}
|
|
|
|
});
|
|
|
|
|
2016-04-24 13:14:01 +08:00
|
|
|
bool SubstituteAlways = false;
|
|
|
|
if (ML && TII->isThroughputPattern(P))
|
|
|
|
SubstituteAlways = true;
|
|
|
|
|
Recommit [MachineCombiner] Update instruction depths incrementally for large BBs.
This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.
Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.
> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619
llvm-svn: 313751
2017-09-20 19:54:37 +08:00
|
|
|
if (IncrementalUpdate) {
|
|
|
|
// Update depths since the last incremental update.
|
|
|
|
MinInstr->updateDepths(LastUpdate, BlockIter, RegUnits);
|
|
|
|
LastUpdate = BlockIter;
|
|
|
|
}
|
|
|
|
|
2015-11-11 04:09:02 +08:00
|
|
|
// Substitute when we optimize for codesize and the new sequence has
|
|
|
|
// fewer instructions OR
|
|
|
|
// the new sequence neither lengthens the critical path nor increases
|
|
|
|
// resource pressure.
|
2017-02-13 17:43:37 +08:00
|
|
|
if (SubstituteAlways || doSubstitute(NewInstCount, OldInstCount)) {
|
Recommit [MachineCombiner] Update instruction depths incrementally for large BBs.
This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.
Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.
> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619
llvm-svn: 313751
2017-09-20 19:54:37 +08:00
|
|
|
insertDeleteInstructions(MBB, MI, InsInstrs, DelInstrs, MinInstr,
|
|
|
|
RegUnits, IncrementalUpdate);
|
2015-11-11 04:09:02 +08:00
|
|
|
// Eagerly stop after the first pattern fires.
|
2017-02-13 17:43:37 +08:00
|
|
|
Changed = true;
|
2015-11-11 04:09:02 +08:00
|
|
|
break;
|
2018-03-17 04:11:55 +08:00
|
|
|
} else {
|
Recommit [MachineCombiner] Update instruction depths incrementally for large BBs.
This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.
Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.
> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619
llvm-svn: 313751
2017-09-20 19:54:37 +08:00
|
|
|
// For big basic blocks, we only compute the full trace the first time
|
|
|
|
// we hit this. We do not invalidate the trace, but instead update the
|
|
|
|
// instruction depths incrementally.
|
|
|
|
// NOTE: Only the instruction depths up to MI are accurate. All other
|
|
|
|
// trace information is not updated.
|
2017-02-13 17:43:37 +08:00
|
|
|
MachineTraceMetrics::Trace BlockTrace = MinInstr->getTrace(MBB);
|
Recommit [MachineCombiner] Update instruction depths incrementally for large BBs.
This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.
Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.
> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619
llvm-svn: 313751
2017-09-20 19:54:37 +08:00
|
|
|
Traces->verifyAnalysis();
|
2017-02-13 17:43:37 +08:00
|
|
|
if (improvesCriticalPathLen(MBB, &MI, BlockTrace, InsInstrs, DelInstrs,
|
Recommit [MachineCombiner] Update instruction depths incrementally for large BBs.
This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.
Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.
> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619
llvm-svn: 313751
2017-09-20 19:54:37 +08:00
|
|
|
InstrIdxForVirtReg, P,
|
|
|
|
!IncrementalUpdate) &&
|
2017-02-13 17:43:37 +08:00
|
|
|
preservesResourceLen(MBB, BlockTrace, InsInstrs, DelInstrs)) {
|
2017-10-12 04:25:58 +08:00
|
|
|
if (MBB->size() > inc_threshold) {
|
Recommit [MachineCombiner] Update instruction depths incrementally for large BBs.
This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.
Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.
> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619
llvm-svn: 313751
2017-09-20 19:54:37 +08:00
|
|
|
// Use incremental depth updates for basic blocks above treshold
|
|
|
|
IncrementalUpdate = true;
|
2017-10-12 04:25:58 +08:00
|
|
|
LastUpdate = BlockIter;
|
|
|
|
}
|
Recommit [MachineCombiner] Update instruction depths incrementally for large BBs.
This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.
Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.
> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619
llvm-svn: 313751
2017-09-20 19:54:37 +08:00
|
|
|
|
|
|
|
insertDeleteInstructions(MBB, MI, InsInstrs, DelInstrs, MinInstr,
|
|
|
|
RegUnits, IncrementalUpdate);
|
|
|
|
|
2017-02-13 17:43:37 +08:00
|
|
|
// Eagerly stop after the first pattern fires.
|
|
|
|
Changed = true;
|
|
|
|
break;
|
|
|
|
}
|
2015-11-11 04:09:02 +08:00
|
|
|
// Cleanup instructions of the alternative code sequence. There is no
|
|
|
|
// use for them.
|
|
|
|
MachineFunction *MF = MBB->getParent();
|
|
|
|
for (auto *InstrPtr : InsInstrs)
|
|
|
|
MF->DeleteMachineInstr(InstrPtr);
|
2014-08-04 05:35:39 +08:00
|
|
|
}
|
2015-11-11 04:09:02 +08:00
|
|
|
InstrIdxForVirtReg.clear();
|
2014-08-04 05:35:39 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Recommit [MachineCombiner] Update instruction depths incrementally for large BBs.
This version of the patch fixes an off-by-one error causing PR34596. We
do not need to use std::next(BlockIter) when calling updateDepths, as
BlockIter already points to the next element.
Original commit message:
> For large basic blocks with lots of combinable instructions, the
> MachineTraceMetrics computations in MachineCombiner can dominate the compile
> time, as computing the trace information is quadratic in the number of
> instructions in a BB and it's relevant successors/predecessors.
> In most cases, knowing the instruction depth should be enough to make
> combination decisions. As we already iterate over all instructions in a basic
> block, the instruction depth can be computed incrementally. This reduces the
> cost of machine-combine drastically in cases where lots of instructions
> are combined. The major drawback is that AFAIK, computing the critical path
> length cannot be done incrementally. Therefore we only compute
> instruction depths incrementally, for basic blocks with more
> instructions than inc_threshold. The -machine-combiner-inc-threshold
> option can be used to set the threshold and allows for easier
> experimenting and checking if using incremental updates for all basic
> blocks has any impact on the performance.
>
> Reviewers: sanjoy, Gerolf, MatzeB, efriedma, fhahn
>
> Reviewed By: fhahn
>
> Subscribers: kiranchandramohan, javed.absar, efriedma, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D36619
llvm-svn: 313751
2017-09-20 19:54:37 +08:00
|
|
|
if (Changed && IncrementalUpdate)
|
|
|
|
Traces->invalidate(MBB);
|
2014-08-04 05:35:39 +08:00
|
|
|
return Changed;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool MachineCombiner::runOnMachineFunction(MachineFunction &MF) {
|
2018-02-15 15:55:02 +08:00
|
|
|
STI = &MF.getSubtarget();
|
|
|
|
TII = STI->getInstrInfo();
|
|
|
|
TRI = STI->getRegisterInfo();
|
|
|
|
SchedModel = STI->getSchedModel();
|
2018-04-09 03:56:04 +08:00
|
|
|
TSchedModel.init(STI);
|
2014-08-04 05:35:39 +08:00
|
|
|
MRI = &MF.getRegInfo();
|
2016-04-24 13:14:01 +08:00
|
|
|
MLI = &getAnalysis<MachineLoopInfo>();
|
2014-08-04 05:35:39 +08:00
|
|
|
Traces = &getAnalysis<MachineTraceMetrics>();
|
2015-10-07 07:24:35 +08:00
|
|
|
MinInstr = nullptr;
|
2017-12-16 06:22:58 +08:00
|
|
|
OptSize = MF.getFunction().optForSize();
|
2014-08-04 05:35:39 +08:00
|
|
|
|
|
|
|
DEBUG(dbgs() << getPassName() << ": " << MF.getName() << '\n');
|
|
|
|
if (!TII->useMachineCombiner()) {
|
|
|
|
DEBUG(dbgs() << " Skipping pass: Target does not support machine combiner\n");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool Changed = false;
|
|
|
|
|
|
|
|
// Try to combine instructions.
|
|
|
|
for (auto &MBB : MF)
|
|
|
|
Changed |= combineInstructions(&MBB);
|
|
|
|
|
|
|
|
return Changed;
|
|
|
|
}
|