-/// If we can determine the operand latency from the def only, without machine
-/// model or itinerary lookup, do so. Otherwise return -1.
-int TargetSchedModel::getDefLatency(const MachineInstr *DefMI,
- bool FindMin) const {
-
- // Return a latency based on the itinerary properties and defining instruction
- // if possible. Some common subtargets don't require per-operand latency,
- // especially for minimum latencies.
- if (FindMin) {
- // If MinLatency is invalid, then use the itinerary for MinLatency. If no
- // itinerary exists either, then use single cycle latency.
- if (SchedModel.MinLatency < 0 && !hasInstrItineraries()) {
- return 1;
- }
- return SchedModel.MinLatency;
- }
- else if (!hasInstrSchedModel() && !hasInstrItineraries()) {
- return TII->defaultDefLatency(&SchedModel, DefMI);
- }
- // ...operand lookup required
- return -1;
+// The machine model may explicitly specify an invalid latency, which
+// effectively means infinite latency. Since users of the TargetSchedule API
+// don't know how to handle this, we convert it to a very large latency that is
+// easy to distinguish when debugging the DAG but won't induce overflow.
+static unsigned capLatency(int Cycles) {
+ return Cycles >= 0 ? Cycles : 1000;