[llvm] MTM: improve operand latency when missing sched info (PR #101389)
Matt Arsenault via llvm-commits
llvm-commits at lists.llvm.org
Wed Oct 9 13:08:20 PDT 2024
================
@@ -761,6 +762,59 @@ static void updatePhysDepsDownwards(const MachineInstr *UseMI,
}
}
+/// Estimates the number of cycles elapsed between DefMI and UseMI, DefMI
+/// inclusive and UseMI exclusive, if they're in the same MBB. Returns
+/// std::nullopt if they're in different MBBs, and 0 if UseMI is null.
+static std::optional<unsigned>
+estimateDefUseCycles(const TargetSchedModel &Sched, const MachineInstr *DefMI,
+ const MachineInstr *UseMI) {
+ if (!UseMI)
+ return 0;
+ if (DefMI->getParent() != UseMI->getParent())
+ return std::nullopt;
+
+ const auto DefIt = DefMI->getIterator();
+ const auto UseIt = UseMI->getIterator();
+
+ unsigned NumMicroOps = 0;
+ for (auto It = DefIt; It != UseIt; ++It) {
+ // In cases where the UseMI is a PHI at the beginning of the MBB, compute
+ // MicroOps until the end of the MBB.
+ if (It.isEnd())
+ break;
+
+ NumMicroOps += Sched.getNumMicroOps(&*It);
+ }
+ return NumMicroOps / Sched.getIssueWidth();
+}
+
+/// Wraps Sched.computeOperandLatency, accounting for the case when
+/// InstrSchedModel and InstrItineraries are not available: in this case,
+/// Sched.computeOperandLatency returns DefaultDefLatency, which is a very rough
+/// approximate; to improve this approximate, offset it by the approximate
+/// cycles elapsed from DefMI to UseMI (since the MIs could be re-ordered by the
+/// scheduler, and we don't have this information, this cannot be known
+/// exactly). When scheduling information is available,
+/// Sched.computeOperandLatency returns a much better estimate (especially if
+/// UseMI is non-null), so we just return that.
+static unsigned computeOperandLatency(const TargetSchedModel &Sched,
+ const MachineInstr *DefMI,
+ unsigned DefOperIdx,
+ const MachineInstr *UseMI,
+ unsigned UseOperIdx) {
+ assert(DefMI && "Non-null DefMI expected");
+ if (!Sched.hasInstrSchedModel() && !Sched.hasInstrItineraries()) {
----------------
arsenm wrote:
Instead of placing this in this wrapper, could the default implementation of computeOperandLatency handle this?
https://github.com/llvm/llvm-project/pull/101389
More information about the llvm-commits
mailing list