int MCSchedModel::computeInstrLatency(const MCSubtargetInfo &STI,
const MCSchedClassDesc &SCDesc) {
int Latency = 0;
for (unsigned DefIdx = 0, DefEnd = SCDesc.NumWriteLatencyEntries;
DefIdx != DefEnd; ++DefIdx) {
// Lookup the definition's write latency in SubtargetInfo.
const MCWriteLatencyEntry *WLEntry =
STI.getWriteLatencyEntry(&SCDesc, DefIdx);
// Early exit if we found an invalid latency.
if (WLEntry->Cycles < 0)
return WLEntry->Cycles;
Latency = std::max(Latency, static_cast<int>(WLEntry->Cycles));
}
return Latency;
}
static void populateWrites(InstrDesc &ID, const MCInst &MCI,
const MCInstrDesc &MCDesc,
const MCSchedClassDesc &SCDesc,
const MCSubtargetInfo &STI) {
// Set if writes through this opcode may update super registers.
// TODO: on x86-64, a 4 byte write of a general purpose register always
// fully updates the super-register.
// More in general, (at least on x86) not all register writes perform
// a partial (super-)register update.
// For example, an AVX instruction that writes on a XMM register implicitly
// zeroes the upper half of every aliasing super-register.
//
// For now, we pessimistically assume that writes are all potentially
// partial register updates. This is a good default for most targets, execept
// for those like x86 which implement a special semantic for certain opcodes.
// At least on x86, this may lead to an inaccurate prediction of the
// instruction level parallelism.
bool FullyUpdatesSuperRegisters = false;
// Now Populate Writes.
// This algorithm currently works under the strong (and potentially incorrect)
// assumption that information related to register def/uses can be obtained
// from MCInstrDesc.
//
// However class MCInstrDesc is used to describe MachineInstr objects and not
// MCInst objects. To be more specific, MCInstrDesc objects are opcode
// descriptors that are automatically generated via tablegen based on the
// instruction set information available from the target .td files. That
// means, the number of (explicit) definitions according to MCInstrDesc always
// matches the cardinality of the `(outs)` set in tablegen.
//
// By constructions, definitions must appear first in the operand sequence of
// a MachineInstr. Also, the (outs) sequence is preserved (example: the first
// element in the outs set is the first operand in the corresponding
// MachineInstr). That's the reason why MCInstrDesc only needs to declare the
// total number of register definitions, and not where those definitions are
// in the machine operand sequence.
//
// Unfortunately, it is not safe to use the information from MCInstrDesc to
// also describe MCInst objects. An MCInst object can be obtained from a
// MachineInstr through a lowering step which may restructure the operand
// sequence (and even remove or introduce new operands). So, there is a high
// risk that the lowering step breaks the assumptions that register
// definitions are always at the beginning of the machine operand sequence.
//
// This is a fundamental problem, and it is still an open problem. Essentially
// we have to find a way to correlate def/use operands of a MachineInstr to
// operands of an MCInst. Otherwise, we cannot correctly reconstruct data
// dependencies, nor we can correctly interpret the scheduling model, which
// heavily uses machine operand indices to define processor read-advance
// information, and to identify processor write resources. Essentially, we
// either need something like a MCInstrDesc, but for MCInst, or a way
// to map MCInst operands back to MachineInstr operands.
//
// Unfortunately, we don't have that information now. So, this prototype
// currently work under the strong assumption that we can always safely trust
// the content of an MCInstrDesc. For example, we can query a MCInstrDesc to
// obtain the number of explicit and implicit register defintions. We also
// assume that register definitions always come first in the operand sequence.
// This last assumption usually makes sense for MachineInstr, where register
// definitions always appear at the beginning of the operands sequence. In
// reality, these assumptions could be broken by the lowering step, which can
// decide to lay out operands in a different order than the original order of
// operand as specified by the MachineInstr.
//
// Things get even more complicated in the presence of "optional" register
// definitions. For MachineInstr, optional register definitions are always at
// the end of the operand sequence. Some ARM instructions that may update the
// status flags specify that register as a optional operand. Since we don't
// have operand descriptors for MCInst, we assume for now that the optional
// definition is always the last operand of a MCInst. Again, this assumption
// may be okay for most targets. However, there is no guarantee that targets
// would respect that.
//
// In conclusion: these are for now the strong assumptions made by the tool:
// * The number of explicit and implicit register definitions in a MCInst
// matches the number of explicit and implicit definitions according to
// the opcode descriptor (MCInstrDesc).
// * Register definitions take precedence over register uses in the operands
// list.
// * If an opcode specifies an optional definition, then the optional
// definition is always the last operand in the sequence, and it can be
// set to zero (i.e. "no register").
//
// These assumptions work quite well for most out-of-order in-tree targets
// like x86. This is mainly because the vast majority of instructions is
// expanded to MCInst using a straightforward lowering logic that preserves
// the ordering of the operands.
//
// In the longer term, we need to find a proper solution for this issue.
unsigned NumExplicitDefs = MCDesc.getNumDefs();
unsigned NumImplicitDefs = MCDesc.getNumImplicitDefs();
unsigned NumWriteLatencyEntries = SCDesc.NumWriteLatencyEntries;
unsigned TotalDefs = NumExplicitDefs + NumImplicitDefs;
if (MCDesc.hasOptionalDef())
TotalDefs++;
ID.Writes.resize(TotalDefs);
// Iterate over the operands list, and skip non-register operands.
// The first NumExplictDefs register operands are expected to be register
// definitions.
unsigned CurrentDef = 0;
unsigned i = 0;
for (; i < MCI.getNumOperands() && CurrentDef < NumExplicitDefs; ++i) {
const MCOperand &Op = MCI.getOperand(i);
if (!Op.isReg())
continue;
WriteDescriptor &Write = ID.Writes[CurrentDef];
Write.OpIndex = i;
if (CurrentDef < NumWriteLatencyEntries) {
const MCWriteLatencyEntry &WLE =
*STI.getWriteLatencyEntry(&SCDesc, CurrentDef);
// Conservatively default to MaxLatency.
Write.Latency = WLE.Cycles == -1 ? ID.MaxLatency : WLE.Cycles;
Write.SClassOrWriteResourceID = WLE.WriteResourceID;
} else {
// Assign a default latency for this write.
Write.Latency = ID.MaxLatency;
Write.SClassOrWriteResourceID = 0;
}
Write.FullyUpdatesSuperRegs = FullyUpdatesSuperRegisters;
Write.IsOptionalDef = false;
LLVM_DEBUG({
dbgs() << "\t\tOpIdx=" << Write.OpIndex << ", Latency=" << Write.Latency
<< ", WriteResourceID=" << Write.SClassOrWriteResourceID << '\n';
});
CurrentDef++;
}
