[llvm-mca] Make Dispatch a subclass of Stage.

[mattd]

Summary

The logic of dispatch remains the same, but now DispatchUnit is a Stage (DispatchStage).

This change has the benefit of simplifying the backend runCycle() code.
The same logic applies, but it belongs to different components now. This is just a start,
eventually we will need to remove the call to the DispatchStage in Scheduler.cpp, but
that will be a separate patch. This change is mostly a renaming and moving of existing logic.

This change also encouraged me to remove the Subtarget (STI) member from the
Backend class. That member was used to initialize the other members of Backend
and to eventually call DispatchUnit::dispatch(). Now that we have Stages, we
can eliminate this by instantiating the DispatchStage with everything it needs
at the time of construction (e.g., Subtarget). That change allows us to call
DispatchStage::execute(IR) as we expect to call execute() for all other stages.

Once we add the Stage list (D46907) we can more cleanly call preExecute() on
all of the stages, DispatchStage, will probably wrap cycleEvent() in that
case.

Made some formatting and minor cleanups to README.txt. Some of the text
was re-flowed to stay within 80 cols.

[andreadb]

LGTM too.

Thanks Matt.

llvm/trunk/tools/llvm-mca/Backend.h

 ///
 /// This file implements an OoO backend for the llvm-mca tool.
 ///
 //===----------------------------------------------------------------------===//
 
 #ifndef LLVM_TOOLS_LLVM_MCA_BACKEND_H
 #define LLVM_TOOLS_LLVM_MCA_BACKEND_H
 
-#include "Dispatch.h"
+#include "DispatchStage.h"
 #include "FetchStage.h"
 #include "InstrBuilder.h"
 #include "Scheduler.h"
 
 namespace mca {
 
 class HWEventListener;
 class HWInstructionEvent;

 /// The Backend entry point is method 'run()' which executes cycles in a loop
 /// until there are new instructions to dispatch, and not every instruction
 /// has been retired.
 ///
 /// Internally, the Backend collects statistical information in the form of
 /// histograms. For example, it tracks how the dispatch group size changes
 /// over time.
 class Backend {
-  const llvm::MCSubtargetInfo &STI;
-
   /// This is the initial stage of the pipeline.
   /// TODO: Eventually this will become a list of unique Stage* that this
   /// backend pipeline executes.
   std::unique_ptr<FetchStage> Fetch;
-
   std::unique_ptr<Scheduler> HWS;
-  std::unique_ptr<DispatchUnit> DU;
+  std::unique_ptr<DispatchStage> Dispatch;
   std::set<HWEventListener *> Listeners;
   unsigned Cycles;
 
   void runCycle(unsigned Cycle);
 
 public:
   Backend(const llvm::MCSubtargetInfo &Subtarget,
           const llvm::MCRegisterInfo &MRI,
           std::unique_ptr<FetchStage> InitialStage, unsigned DispatchWidth = 0,
           unsigned RegisterFileSize = 0, unsigned LoadQueueSize = 0,
           unsigned StoreQueueSize = 0, bool AssumeNoAlias = false)
-      : STI(Subtarget), Fetch(std::move(InitialStage)),
+      : Fetch(std::move(InitialStage)),
         HWS(llvm::make_unique<Scheduler>(this, Subtarget.getSchedModel(),
                                          LoadQueueSize, StoreQueueSize,
                                          AssumeNoAlias)),
-        DU(llvm::make_unique<DispatchUnit>(this, Subtarget.getSchedModel(), MRI,
-                                           RegisterFileSize, DispatchWidth,
-                                           HWS.get())),
+        Dispatch(llvm::make_unique<DispatchStage>(
+            this, Subtarget, MRI, RegisterFileSize, DispatchWidth, HWS.get())),
         Cycles(0) {
-    HWS->setDispatchUnit(DU.get());
+    HWS->setDispatchStage(Dispatch.get());
   }
 
   void run();
   void addEventListener(HWEventListener *Listener);
   void notifyCycleBegin(unsigned Cycle);
   void notifyInstructionEvent(const HWInstructionEvent &Event);
   void notifyStallEvent(const HWStallEvent &Event);
   void notifyResourceAvailable(const ResourceRef &RR);
   void notifyReservedBuffers(llvm::ArrayRef<unsigned> Buffers);
   void notifyReleasedBuffers(llvm::ArrayRef<unsigned> Buffers);
   void notifyCycleEnd(unsigned Cycle);
 };
 } // namespace mca
 
 #endif

llvm/trunk/tools/llvm-mca/Backend.cpp

 using namespace llvm;
 
 void Backend::addEventListener(HWEventListener *Listener) {
   if (Listener)
     Listeners.insert(Listener);
 }
 
 void Backend::run() {
-  while (Fetch->isReady() || !DU->isRCUEmpty())
+  while (Fetch->isReady() || !Dispatch->isReady())
     runCycle(Cycles++);
 }
 
 void Backend::runCycle(unsigned Cycle) {
   notifyCycleBegin(Cycle);
 
   InstRef IR;
   while (Fetch->execute(IR)) {
-    const InstrDesc &Desc = IR.getInstruction()->getDesc();
-    if (!DU->isAvailable(Desc.NumMicroOps) || !DU->canDispatch(IR))
+    if (!Dispatch->execute(IR))
       break;
-    DU->dispatch(IR, STI);
     Fetch->postExecute(IR);
   }
 
   notifyCycleEnd(Cycle);
 }
 
 void Backend::notifyCycleBegin(unsigned Cycle) {
   LLVM_DEBUG(dbgs() << "[E] Cycle begin: " << Cycle << '\n');
   for (HWEventListener *Listener : Listeners)
     Listener->onCycleBegin();
 
-  DU->cycleEvent();
+  Dispatch->cycleEvent();
   HWS->cycleEvent();
 }
 
 void Backend::notifyInstructionEvent(const HWInstructionEvent &Event) {
   for (HWEventListener *Listener : Listeners)
     Listener->onInstructionEvent(Event);
 }
 

llvm/trunk/tools/llvm-mca/CMakeLists.txt

 set(LLVM_LINK_COMPONENTS
   AllTargetsAsmPrinters
   AllTargetsAsmParsers
   AllTargetsDescs
   AllTargetsDisassemblers
   AllTargetsInfos
   MC
   MCParser
   Support
   )
 
 add_llvm_tool(llvm-mca
   Backend.cpp
   BackendPrinter.cpp
   CodeRegion.cpp
-  Dispatch.cpp
+  DispatchStage.cpp
   DispatchStatistics.cpp
   FetchStage.cpp
   HWEventListener.cpp
   InstrBuilder.cpp
   Instruction.cpp
   InstructionInfoView.cpp
   InstructionTables.cpp
   LSUnit.cpp

llvm/trunk/tools/llvm-mca/Dispatch.h

-//===----------------------- Dispatch.h -------------------------*- C++ -*-===//
-//
-//                     The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===----------------------------------------------------------------------===//
-/// \file
-///
-/// This file implements classes that are used to model reorder buffers and
-/// the hardware dispatch logic.
-///
-//===----------------------------------------------------------------------===//
-
-#ifndef LLVM_TOOLS_LLVM_MCA_DISPATCH_H
-#define LLVM_TOOLS_LLVM_MCA_DISPATCH_H
-
-#include "Instruction.h"
-#include "RegisterFile.h"
-#include "RetireControlUnit.h"
-#include "llvm/MC/MCRegisterInfo.h"
-#include "llvm/MC/MCSubtargetInfo.h"
-
-namespace mca {
-
-class WriteState;
-class Scheduler;
-class Backend;
-
-// Implements the hardware dispatch logic.
-//
-// This class is responsible for the dispatch stage, in which instructions are
-// dispatched in groups to the Scheduler.  An instruction can be dispatched if
-// functional units are available.
-// To be more specific, an instruction can be dispatched to the Scheduler if:
-//  1) There are enough entries in the reorder buffer (implemented by class
-//     RetireControlUnit) to accomodate all opcodes.
-//  2) There are enough temporaries to rename output register operands.
-//  3) There are enough entries available in the used buffered resource(s).
-//
-// The number of micro opcodes that can be dispatched in one cycle is limited by
-// the value of field 'DispatchWidth'. A "dynamic dispatch stall" occurs when
-// processor resources are not available (i.e. at least one of the
-// abovementioned checks fails). Dispatch stall events are counted during the
-// entire execution of the code, and displayed by the performance report when
-// flag '-verbose' is specified.
-//
-// If the number of micro opcodes of an instruction is bigger than
-// DispatchWidth, then it can only be dispatched at the beginning of one cycle.
-// The DispatchUnit will still have to wait for a number of cycles (depending on
-// the DispatchWidth and the number of micro opcodes) before it can serve other
-// instructions.
-class DispatchUnit {
-  unsigned DispatchWidth;
-  unsigned AvailableEntries;
-  unsigned CarryOver;
-  Scheduler *SC;
-
-  std::unique_ptr<RegisterFile> RAT;
-  std::unique_ptr<RetireControlUnit> RCU;
-  Backend *Owner;
-
-  bool checkRAT(const InstRef &IR);
-  bool checkRCU(const InstRef &IR);
-  bool checkScheduler(const InstRef &IR);
-
-  void updateRAWDependencies(ReadState &RS, const llvm::MCSubtargetInfo &STI);
-  void notifyInstructionDispatched(const InstRef &IR,
-                                   llvm::ArrayRef<unsigned> UsedPhysRegs);
-
-public:
-  DispatchUnit(Backend *B, const llvm::MCSchedModel &SM,
-               const llvm::MCRegisterInfo &MRI, unsigned RegisterFileSize,
-               unsigned MaxDispatchWidth, Scheduler *Sched)
-      : DispatchWidth(MaxDispatchWidth), AvailableEntries(MaxDispatchWidth),
-        CarryOver(0U), SC(Sched),
-        RAT(llvm::make_unique<RegisterFile>(SM, MRI, RegisterFileSize)),
-        RCU(llvm::make_unique<RetireControlUnit>(SM, this)), Owner(B) {}
-
-  unsigned getDispatchWidth() const { return DispatchWidth; }
-
-  bool isAvailable(unsigned NumEntries) const {
-    return NumEntries <= AvailableEntries || AvailableEntries == DispatchWidth;
-  }
-
-  bool isRCUEmpty() const { return RCU->isEmpty(); }
-
-  bool canDispatch(const InstRef &IR) {
-    assert(isAvailable(IR.getInstruction()->getDesc().NumMicroOps));
-    return checkRCU(IR) && checkRAT(IR) && checkScheduler(IR);
-  }
-
-  void dispatch(InstRef IR, const llvm::MCSubtargetInfo &STI);
-
-  void collectWrites(llvm::SmallVectorImpl<WriteState *> &Vec,
-                     unsigned RegID) const {
-    return RAT->collectWrites(Vec, RegID);
-  }
-
-  void cycleEvent() {
-    RCU->cycleEvent();
-    AvailableEntries =
-        CarryOver >= DispatchWidth ? 0 : DispatchWidth - CarryOver;
-    CarryOver = CarryOver >= DispatchWidth ? CarryOver - DispatchWidth : 0U;
-  }
-
-  void notifyInstructionRetired(const InstRef &IR);
-
-  void notifyDispatchStall(const InstRef &IR, unsigned EventType);
-
-  void onInstructionExecuted(unsigned TokenID) {
-    RCU->onInstructionExecuted(TokenID);
-  }
-
-#ifndef NDEBUG
-  void dump() const;
-#endif
-};
-} // namespace mca
-
-#endif

llvm/trunk/tools/llvm-mca/Dispatch.cpp

-//===--------------------- Dispatch.cpp -------------------------*- C++ -*-===//
-//
-//                     The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===----------------------------------------------------------------------===//
-/// \file
-///
-/// This file implements methods declared by the DispatchUnit class.
-///
-//===----------------------------------------------------------------------===//
-
-#include "Dispatch.h"
-#include "Backend.h"
-#include "HWEventListener.h"
-#include "Scheduler.h"
-#include "llvm/Support/Debug.h"
-
-using namespace llvm;
-
-#define DEBUG_TYPE "llvm-mca"
-
-namespace mca {
-
-void DispatchUnit::notifyInstructionDispatched(const InstRef &IR,
-                                               ArrayRef<unsigned> UsedRegs) {
-  LLVM_DEBUG(dbgs() << "[E] Instruction Dispatched: " << IR << '\n');
-  Owner->notifyInstructionEvent(HWInstructionDispatchedEvent(IR, UsedRegs));
-}
-
-void DispatchUnit::notifyInstructionRetired(const InstRef &IR) {
-  LLVM_DEBUG(dbgs() << "[E] Instruction Retired: " << IR << '\n');
-  SmallVector<unsigned, 4> FreedRegs(RAT->getNumRegisterFiles());
-  const InstrDesc &Desc = IR.getInstruction()->getDesc();
-
-  for (const std::unique_ptr<WriteState> &WS : IR.getInstruction()->getDefs())
-    RAT->removeRegisterWrite(*WS.get(), FreedRegs, !Desc.isZeroLatency());
-  Owner->notifyInstructionEvent(HWInstructionRetiredEvent(IR, FreedRegs));
-}
-
-bool DispatchUnit::checkRAT(const InstRef &IR) {
-  SmallVector<unsigned, 4> RegDefs;
-  for (const std::unique_ptr<WriteState> &RegDef :
-       IR.getInstruction()->getDefs())
-    RegDefs.emplace_back(RegDef->getRegisterID());
-
-  unsigned RegisterMask = RAT->isAvailable(RegDefs);
-  // A mask with all zeroes means: register files are available.
-  if (RegisterMask) {
-    Owner->notifyStallEvent(HWStallEvent(HWStallEvent::RegisterFileStall, IR));
-    return false;
-  }
-
-  return true;
-}
-
-bool DispatchUnit::checkRCU(const InstRef &IR) {
-  const unsigned NumMicroOps = IR.getInstruction()->getDesc().NumMicroOps;
-  if (RCU->isAvailable(NumMicroOps))
-    return true;
-  Owner->notifyStallEvent(
-      HWStallEvent(HWStallEvent::RetireControlUnitStall, IR));
-  return false;
-}
-
-bool DispatchUnit::checkScheduler(const InstRef &IR) {
-  return SC->canBeDispatched(IR);
-}
-
-void DispatchUnit::updateRAWDependencies(ReadState &RS,
-                                         const MCSubtargetInfo &STI) {
-  SmallVector<WriteState *, 4> DependentWrites;
-
-  collectWrites(DependentWrites, RS.getRegisterID());
-  RS.setDependentWrites(DependentWrites.size());
-  LLVM_DEBUG(dbgs() << "Found " << DependentWrites.size()
-                    << " dependent writes\n");
-  // We know that this read depends on all the writes in DependentWrites.
-  // For each write, check if we have ReadAdvance information, and use it
-  // to figure out in how many cycles this read becomes available.
-  const ReadDescriptor &RD = RS.getDescriptor();
-  if (!RD.HasReadAdvanceEntries) {
-    for (WriteState *WS : DependentWrites)
-      WS->addUser(&RS, /* ReadAdvance */ 0);
-    return;
-  }
-
-  const MCSchedModel &SM = STI.getSchedModel();
-  const MCSchedClassDesc *SC = SM.getSchedClassDesc(RD.SchedClassID);
-  for (WriteState *WS : DependentWrites) {
-    unsigned WriteResID = WS->getWriteResourceID();
-    int ReadAdvance = STI.getReadAdvanceCycles(SC, RD.UseIndex, WriteResID);
-    WS->addUser(&RS, ReadAdvance);
-  }
-  // Prepare the set for another round.
-  DependentWrites.clear();
-}
-
-void DispatchUnit::dispatch(InstRef IR, const MCSubtargetInfo &STI) {
-  assert(!CarryOver && "Cannot dispatch another instruction!");
-  Instruction &IS = *IR.getInstruction();
-  const InstrDesc &Desc = IS.getDesc();
-  const unsigned NumMicroOps = Desc.NumMicroOps;
-  if (NumMicroOps > DispatchWidth) {
-    assert(AvailableEntries == DispatchWidth);
-    AvailableEntries = 0;
-    CarryOver = NumMicroOps - DispatchWidth;
-  } else {
-    assert(AvailableEntries >= NumMicroOps);
-    AvailableEntries -= NumMicroOps;
-  }
-
-  // A dependency-breaking instruction doesn't have to wait on the register
-  // input operands, and it is often optimized at register renaming stage.
-  // Update RAW dependencies if this instruction is not a dependency-breaking
-  // instruction. A dependency-breaking instruction is a zero-latency
-  // instruction that doesn't consume hardware resources.
-  // An example of dependency-breaking instruction on X86 is a zero-idiom XOR.
-  if (!Desc.isZeroLatency())
-    for (std::unique_ptr<ReadState> &RS : IS.getUses())
-      updateRAWDependencies(*RS, STI);
-
-  // By default, a dependency-breaking zero-latency instruction is expected to
-  // be optimized at register renaming stage. That means, no physical register
-  // is allocated to the instruction.
-  SmallVector<unsigned, 4> RegisterFiles(RAT->getNumRegisterFiles());
-  for (std::unique_ptr<WriteState> &WS : IS.getDefs())
-    RAT->addRegisterWrite(*WS, RegisterFiles, !Desc.isZeroLatency());
-
-  // Reserve slots in the RCU, and notify the instruction that it has been
-  // dispatched to the schedulers for execution.
-  IS.dispatch(RCU->reserveSlot(IR, NumMicroOps));
-
-  // Notify listeners of the "instruction dispatched" event.
-  notifyInstructionDispatched(IR, RegisterFiles);
-
-  // Now move the instruction into the scheduler's queue.
-  // The scheduler is responsible for checking if this is a zero-latency
-  // instruction that doesn't consume pipeline/scheduler resources.
-  SC->scheduleInstruction(IR);
-}
-
-#ifndef NDEBUG
-void DispatchUnit::dump() const {
-  RAT->dump();
-  RCU->dump();
-}
-#endif
-} // namespace mca

llvm/trunk/tools/llvm-mca/DispatchStage.h

+//===----------------------- Dispatch.h -------------------------*- C++ -*-===//
+//
+//                     The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===----------------------------------------------------------------------===//
+/// \file
+///
+/// This file implements classes that are used to model reorder buffers and
+/// the hardware dispatch logic.
+///
+//===----------------------------------------------------------------------===//
+
+#ifndef LLVM_TOOLS_LLVM_MCA_DISPATCH_H
+#define LLVM_TOOLS_LLVM_MCA_DISPATCH_H
+
+#include "Instruction.h"
+#include "RegisterFile.h"
+#include "RetireControlUnit.h"
+#include "Stage.h"
+#include "llvm/MC/MCRegisterInfo.h"
+#include "llvm/MC/MCSubtargetInfo.h"
+
+namespace mca {
+
+class WriteState;
+class Scheduler;
+class Backend;
+
+// Implements the hardware dispatch logic.
+//
+// This class is responsible for the dispatch stage, in which instructions are
+// dispatched in groups to the Scheduler.  An instruction can be dispatched if
+// functional units are available.
+// To be more specific, an instruction can be dispatched to the Scheduler if:
+//  1) There are enough entries in the reorder buffer (implemented by class
+//     RetireControlUnit) to accommodate all opcodes.
+//  2) There are enough temporaries to rename output register operands.
+//  3) There are enough entries available in the used buffered resource(s).
+//
+// The number of micro opcodes that can be dispatched in one cycle is limited by
+// the value of field 'DispatchWidth'. A "dynamic dispatch stall" occurs when
+// processor resources are not available (i.e. at least one of the
+// aforementioned checks fails). Dispatch stall events are counted during the
+// entire execution of the code, and displayed by the performance report when
+// flag '-verbose' is specified.
+//
+// If the number of micro opcodes of an instruction is bigger than
+// DispatchWidth, then it can only be dispatched at the beginning of one cycle.
+// The DispatchStage will still have to wait for a number of cycles (depending
+// on the DispatchWidth and the number of micro opcodes) before it can serve
+// other instructions.
+class DispatchStage : public Stage {
+  unsigned DispatchWidth;
+  unsigned AvailableEntries;
+  unsigned CarryOver;
+  Scheduler *SC;
+  std::unique_ptr<RegisterFile> RAT;
+  std::unique_ptr<RetireControlUnit> RCU;
+  Backend *Owner;
+  const llvm::MCSubtargetInfo &STI;
+
+  bool checkRAT(const InstRef &IR);
+  bool checkRCU(const InstRef &IR);
+  bool checkScheduler(const InstRef &IR);
+  void dispatch(InstRef IR);
+  bool isRCUEmpty() const { return RCU->isEmpty(); }
+  void updateRAWDependencies(ReadState &RS, const llvm::MCSubtargetInfo &STI);
+
+  void notifyInstructionDispatched(const InstRef &IR,
+                                   llvm::ArrayRef<unsigned> UsedPhysRegs);
+
+  bool isAvailable(unsigned NumEntries) const {
+    return NumEntries <= AvailableEntries || AvailableEntries == DispatchWidth;
+  }
+
+  bool canDispatch(const InstRef &IR) {
+    assert(isAvailable(IR.getInstruction()->getDesc().NumMicroOps));
+    return checkRCU(IR) && checkRAT(IR) && checkScheduler(IR);
+  }
+
+  void collectWrites(llvm::SmallVectorImpl<WriteState *> &Vec,
+                     unsigned RegID) const {
+    return RAT->collectWrites(Vec, RegID);
+  }
+
+public:
+  DispatchStage(Backend *B, const llvm::MCSubtargetInfo &Subtarget,
+                const llvm::MCRegisterInfo &MRI, unsigned RegisterFileSize,
+                unsigned MaxDispatchWidth, Scheduler *Sched)
+      : DispatchWidth(MaxDispatchWidth), AvailableEntries(MaxDispatchWidth),
+        CarryOver(0U), SC(Sched),
+        RAT(llvm::make_unique<RegisterFile>(Subtarget.getSchedModel(), MRI,
+                                            RegisterFileSize)),
+        RCU(llvm::make_unique<RetireControlUnit>(Subtarget.getSchedModel(),
+                                                 this)),
+        Owner(B), STI(Subtarget) {}
+
+  void cycleEvent() {
+    RCU->cycleEvent();
+    AvailableEntries =
+        CarryOver >= DispatchWidth ? 0 : DispatchWidth - CarryOver;
+    CarryOver = CarryOver >= DispatchWidth ? CarryOver - DispatchWidth : 0U;
+  }
+
+  virtual bool isReady() const override final { return isRCUEmpty(); }
+  virtual bool execute(InstRef &IR) override final;
+  void notifyInstructionRetired(const InstRef &IR);
+  void notifyDispatchStall(const InstRef &IR, unsigned EventType);
+
+  void onInstructionExecuted(unsigned TokenID) {
+    RCU->onInstructionExecuted(TokenID);
+  }
+
+#ifndef NDEBUG
+  void dump() const;
+#endif
+};
+} // namespace mca
+
+#endif

llvm/trunk/tools/llvm-mca/DispatchStage.cpp

+//===--------------------- Dispatch.cpp -------------------------*- C++ -*-===//
+//
+//                     The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===----------------------------------------------------------------------===//
+/// \file
+///
+/// This file implements methods declared by the DispatchStage class.
+///
+//===----------------------------------------------------------------------===//
+
+#include "DispatchStage.h"
+#include "Backend.h"
+#include "HWEventListener.h"
+#include "Scheduler.h"
+#include "llvm/Support/Debug.h"
+
+using namespace llvm;
+
+#define DEBUG_TYPE "llvm-mca"
+
+namespace mca {
+
+void DispatchStage::notifyInstructionDispatched(const InstRef &IR,
+                                                ArrayRef<unsigned> UsedRegs) {
+  LLVM_DEBUG(dbgs() << "[E] Instruction Dispatched: " << IR << '\n');
+  Owner->notifyInstructionEvent(HWInstructionDispatchedEvent(IR, UsedRegs));
+}
+
+void DispatchStage::notifyInstructionRetired(const InstRef &IR) {
+  LLVM_DEBUG(dbgs() << "[E] Instruction Retired: " << IR << '\n');
+  SmallVector<unsigned, 4> FreedRegs(RAT->getNumRegisterFiles());
+  const InstrDesc &Desc = IR.getInstruction()->getDesc();
+
+  for (const std::unique_ptr<WriteState> &WS : IR.getInstruction()->getDefs())
+    RAT->removeRegisterWrite(*WS.get(), FreedRegs, !Desc.isZeroLatency());
+  Owner->notifyInstructionEvent(HWInstructionRetiredEvent(IR, FreedRegs));
+}
+
+bool DispatchStage::checkRAT(const InstRef &IR) {
+  SmallVector<unsigned, 4> RegDefs;
+  for (const std::unique_ptr<WriteState> &RegDef :
+       IR.getInstruction()->getDefs())
+    RegDefs.emplace_back(RegDef->getRegisterID());
+
+  unsigned RegisterMask = RAT->isAvailable(RegDefs);
+  // A mask with all zeroes means: register files are available.
+  if (RegisterMask) {
+    Owner->notifyStallEvent(HWStallEvent(HWStallEvent::RegisterFileStall, IR));
+    return false;
+  }
+
+  return true;
+}
+
+bool DispatchStage::checkRCU(const InstRef &IR) {
+  const unsigned NumMicroOps = IR.getInstruction()->getDesc().NumMicroOps;
+  if (RCU->isAvailable(NumMicroOps))
+    return true;
+  Owner->notifyStallEvent(
+      HWStallEvent(HWStallEvent::RetireControlUnitStall, IR));
+  return false;
+}
+
+bool DispatchStage::checkScheduler(const InstRef &IR) {
+  return SC->canBeDispatched(IR);
+}
+
+void DispatchStage::updateRAWDependencies(ReadState &RS,
+                                          const MCSubtargetInfo &STI) {
+  SmallVector<WriteState *, 4> DependentWrites;
+
+  collectWrites(DependentWrites, RS.getRegisterID());
+  RS.setDependentWrites(DependentWrites.size());
+  LLVM_DEBUG(dbgs() << "Found " << DependentWrites.size()
+                    << " dependent writes\n");
+  // We know that this read depends on all the writes in DependentWrites.
+  // For each write, check if we have ReadAdvance information, and use it
+  // to figure out in how many cycles this read becomes available.
+  const ReadDescriptor &RD = RS.getDescriptor();
+  if (!RD.HasReadAdvanceEntries) {
+    for (WriteState *WS : DependentWrites)
+      WS->addUser(&RS, /* ReadAdvance */ 0);
+    return;
+  }
+
+  const MCSchedModel &SM = STI.getSchedModel();
+  const MCSchedClassDesc *SC = SM.getSchedClassDesc(RD.SchedClassID);
+  for (WriteState *WS : DependentWrites) {
+    unsigned WriteResID = WS->getWriteResourceID();
+    int ReadAdvance = STI.getReadAdvanceCycles(SC, RD.UseIndex, WriteResID);
+    WS->addUser(&RS, ReadAdvance);
+  }
+  // Prepare the set for another round.
+  DependentWrites.clear();
+}
+
+void DispatchStage::dispatch(InstRef IR) {
+  assert(!CarryOver && "Cannot dispatch another instruction!");
+  Instruction &IS = *IR.getInstruction();
+  const InstrDesc &Desc = IS.getDesc();
+  const unsigned NumMicroOps = Desc.NumMicroOps;
+  if (NumMicroOps > DispatchWidth) {
+    assert(AvailableEntries == DispatchWidth);
+    AvailableEntries = 0;
+    CarryOver = NumMicroOps - DispatchWidth;
+  } else {
+    assert(AvailableEntries >= NumMicroOps);
+    AvailableEntries -= NumMicroOps;
+  }
+
+  // A dependency-breaking instruction doesn't have to wait on the register
+  // input operands, and it is often optimized at register renaming stage.
+  // Update RAW dependencies if this instruction is not a dependency-breaking
+  // instruction. A dependency-breaking instruction is a zero-latency
+  // instruction that doesn't consume hardware resources.
+  // An example of dependency-breaking instruction on X86 is a zero-idiom XOR.
+  if (!Desc.isZeroLatency())
+    for (std::unique_ptr<ReadState> &RS : IS.getUses())
+      updateRAWDependencies(*RS, STI);
+
+  // By default, a dependency-breaking zero-latency instruction is expected to
+  // be optimized at register renaming stage. That means, no physical register
+  // is allocated to the instruction.
+  SmallVector<unsigned, 4> RegisterFiles(RAT->getNumRegisterFiles());
+  for (std::unique_ptr<WriteState> &WS : IS.getDefs())
+    RAT->addRegisterWrite(*WS, RegisterFiles, !Desc.isZeroLatency());
+
+  // Reserve slots in the RCU, and notify the instruction that it has been
+  // dispatched to the schedulers for execution.
+  IS.dispatch(RCU->reserveSlot(IR, NumMicroOps));
+
+  // Notify listeners of the "instruction dispatched" event.
+  notifyInstructionDispatched(IR, RegisterFiles);
+
+  // Now move the instruction into the scheduler's queue.
+  // The scheduler is responsible for checking if this is a zero-latency
+  // instruction that doesn't consume pipeline/scheduler resources.
+  SC->scheduleInstruction(IR);
+}
+
+bool DispatchStage::execute(InstRef &IR) {
+  const InstrDesc &Desc = IR.getInstruction()->getDesc();
+  if (!isAvailable(Desc.NumMicroOps) || !canDispatch(IR))
+    return false;
+  dispatch(IR);
+  return true;
+}
+
+#ifndef NDEBUG
+void DispatchStage::dump() const {
+  RAT->dump();
+  RCU->dump();
+}
+#endif
+} // namespace mca

llvm/trunk/tools/llvm-mca/HWEventListener.h

 class HWInstructionEvent {
 public:
   // This is the list of event types that are shared by all targets, that
   // generic subtarget-agnostic classes (e.g. Backend, HWInstructionEvent, ...)
   // and generic Views can manipulate.
   // Subtargets are free to define additional event types, that are goin to be
   // handled by generic components as opaque values, but can still be
   // emitted by subtarget-specific pipeline components (e.g. Scheduler,
-  // DispatchUnit, ...) and interpreted by subtarget-specific EventListener
+  // DispatchStage, ...) and interpreted by subtarget-specific EventListener
   // implementations.
   enum GenericEventType {
     Invalid = 0,
     // Events generated by the Retire Control Unit.
     Retired,
     // Events generated by the Scheduler.
     Ready,
     Issued,

 };
 
 // A HWStallEvent represents a pipeline stall caused by the lack of hardware
 // resources.
 class HWStallEvent {
 public:
   enum GenericEventType {
     Invalid = 0,
-    // Generic stall events generated by the DispatchUnit.
+    // Generic stall events generated by the DispatchStage.
     RegisterFileStall,
     RetireControlUnitStall,
     // Generic stall events generated by the Scheduler.
     DispatchGroupStall,
     SchedulerQueueFull,
     LoadQueueFull,
     StoreQueueFull,
     LastGenericEvent

llvm/trunk/tools/llvm-mca/README.txt

 llvm-mca - LLVM Machine Code Analyzer
 -------------------------------------
 
 llvm-mca is a performance analysis tool that uses information which is already
-available in LLVM (e.g. scheduling models) to statically measure the performance
-of machine code in a specific cpu.
+available in LLVM (e.g., scheduling models) to statically measure the
+performance of machine code in a specific cpu.
 
 Performance is measured in terms of throughput as well as processor resource
 consumption.  The tool currently works for processors with an out-of-order
 backend, for which there is a scheduling model available in LLVM.
 
 The main goal of this tool is not just to predict the performance of the code
 when run on the target, but also help with diagnosing potential performance
 issues.
 
 Given an assembly code sequence, llvm-mca estimates the IPC (instructions Per
 cycle), as well as hardware resources pressure. The analysis and reporting style
 were inspired by the IACA tool from Intel.
 
 The presence of long data dependency chains, as well as poor usage of hardware
 resources may lead to bottlenecks in the back-end.  The tool is able to generate
 a detailed report which should help with identifying and analyzing sources of
 bottlenecks.
 
 Scheduling models are mostly used to compute instruction latencies, to obtain
 read-advance information, and understand how processor resources are used by
 instructions.  By design, the quality of the performance analysis conducted by
-the tool is inevitably affected by the quality of the target scheduling models. 
-
-However, scheduling models intentionally do not describe all processors details,
+the tool is inevitably affected by the quality of the target scheduling models.
+However, scheduling models intentionally do not describe all processor details,
 since the goal is just to enable the scheduling of machine instructions during
 compilation. That means, there are processor details which are not important for
 the purpose of scheduling instructions (and therefore not described by the
 scheduling model), but are very important for this tool.
 
 A few examples of details that are missing in scheduling models are:
  - Actual dispatch width (it often differs from the issue width).
  - Number of read/write ports in the register file(s).

 [5] - JFPU1
 [6] - JLAGU
 [7] - JSAGU
 [8] - JSTC
 [9] - JVIMUL
 
 
 Resource pressure per iteration:
-[0]    [1]    [2]    [3]    [4]    [5]    [6]    [7]    [8]    [9]    
- -      -      -      -     2.00   1.00    -      -      -      -     
+[0]    [1]    [2]    [3]    [4]    [5]    [6]    [7]    [8]    [9]
+ -      -      -      -     2.00   1.00    -      -      -      -
 
 Resource pressure by instruction:
 [0]    [1]    [2]    [3]    [4]    [5]    [6]    [7]    [8]    [9]      Instructions:
  -      -      -      -      -     1.00    -      -      -      -       vmulps  %xmm0, %xmm1, %xmm2
  -      -      -      -     1.00    -      -      -      -      -       vhaddps %xmm2, %xmm2, %xmm3
  -      -      -      -     1.00    -      -      -      -      -       vhaddps %xmm3, %xmm3, %xmm4
 
 

 
 ///////////////////
 
 According to this report, the dot-product kernel has been executed 300 times,
 for a total of 900 instructions dynamically executed.
 
 The report is structured in three main sections.  A first section collects a few
 performance numbers; the goal of this section is to give a very quick overview
-of the performance throughput. In this example, the two important perforamce
-indicators are a) the predicted total number of cycles, and b) the IPC. 
+of the performance throughput. In this example, the two important performance
+indicators are a) the predicted total number of cycles, and b) the IPC.
 IPC is probably the most important throughput indicator. A big delta between the
 Dispatch Width and the computed IPC is an indicator of potential performance
 issues.
 
 The second section is the so-called "resource pressure view".  This view reports
 the average number of resource cycles consumed every iteration by instructions
 for every processor resource unit available on the target.  Information is
 structured in two tables. The first table reports the number of resource cycles
 spent on average every iteration. The second table correlates the resource
 cycles to the machine instruction in the sequence. For example, every iteration
 of the dot-product, instruction 'vmulps' always executes on resource unit [5]
 (JFPU1 - floating point pipeline #1), consuming an average of 1 resource cycle
 per iteration.  Note that on Jaguar, vector FP multiply can only be issued to
 pipeline JFPU1, while horizontal FP adds can only be issued to pipeline JFPU0.
 
 The third (and last) section of the report shows the latency and reciprocal
 throughput of every instruction in the sequence. That section also reports extra
-information related to the number of micro opcodes, and opcode properties (i.e.
-'MayLoad', 'MayStore' and 'UnmodeledSideEffects').
+information related to the number of micro opcodes, and opcode properties (i.e.,
+'MayLoad', 'MayStore', and 'UnmodeledSideEffects').
 
 The resource pressure view helps with identifying bottlenecks caused by high
 usage of specific hardware resources.  Situations with resource pressure mainly
 concentrated on a few resources should, in general, be avoided.  Ideally,
 pressure should be uniformly distributed between multiple resources.
 
 Timeline View
 -------------
 
 A detailed report of each instruction's state transitions over time can be
 enabled using the command line flag '-timeline'.  This prints an extra section
 in the report which contains the so-called "timeline view".  Below is the
 timeline view for the dot-product example from the previous section.
 
 ///////////////
 Timeline view:
                 012345
-Index 0123456789      
+Index 0123456789
 
 [0,0] DeeER.    .    .  vmulps  %xmm0, %xmm1, %xmm2
 [0,1] D==eeeER  .    .  vhaddps %xmm2, %xmm2, %xmm3
 [0,2] .D====eeeER    .  vhaddps %xmm3, %xmm3, %xmm4
 
 [1,0] .DeeE-----R    .  vmulps  %xmm0, %xmm1, %xmm2
 [1,1] . D=eeeE---R   .  vhaddps %xmm2, %xmm2, %xmm3
 [1,2] . D====eeeER   .  vhaddps %xmm3, %xmm3, %xmm4

 The timeline view is structured in two tables.  The first table shows how
 instructions change in state over time (measured in cycles); the second table
 (named "Average Wait times") reports useful timing statistics which should help
 diagnose performance bottlenecks caused by long data dependencies and
 sub-optimal usage of hardware resources.
 
 An instruction in the timeline view is identified by a pair of indices, where
 the 'first' index identifies an iteration, and the 'second' index is the actual
-instruction index (i.e. where it appears in the code sequence).
+instruction index (i.e., where it appears in the code sequence).
 
-Excluding the first and last column, the remaining columns are in cycles.  Cycles
-are numbered sequentially starting from 0.  The following characters are used to
-describe the state of an instruction:
+Excluding the first and last column, the remaining columns are in cycles.
+Cycles are numbered sequentially starting from 0.  The following characters are
+used to describe the state of an instruction:
 
  D : Instruction dispatched.
  e : Instruction executing.
  E : Instruction executed.
  R : Instruction retired.
  = : Instruction already dispatched, waiting to be executed.
  - : Instruction executed, waiting to be retired.
 
 Based on the timeline view from the example, we know that:
   - Instruction [1, 0] was dispatched at cycle 1.
   - Instruction [1, 0] started executing at cycle 2.
   - Instruction [1, 0] reached the write back stage at cycle 4.
   - Instruction [1, 0] was retired at cycle 10.
 
-Instruction [1, 0] (i.e. the vmulps from iteration #1) doesn't have to wait in
+Instruction [1, 0] (i.e., the vmulps from iteration #1) doesn't have to wait in
 the scheduler's queue for the operands to become available. By the time the
 vmulps is dispatched, operands are already available, and pipeline JFPU1 is
 ready to serve another instruction.  So the instruction can be immediately
 issued on the JFPU1 pipeline. That is demonstrated by the fact that the
 instruction only spent 1cy in the scheduler's queue.
 
 There is a gap of 5 cycles between the write-back stage and the retire event.
 That is because instructions must retire in program order, so [1,0] has to wait
-for [0, 2] to be retired first (i.e it has to wait unti cycle 10).
+for [0, 2] to be retired first (i.e., it has to wait until cycle 10).
 
 In the dot-product example, all instructions are in a RAW (Read After Write)
 dependency chain.  Register %xmm2 written by the vmulps is immediately used by
 the first vhaddps, and register %xmm3 written by the first vhaddps is used by
 the second vhaddps.  Long data dependencies negatively affect the ILP
 (Instruction Level Parallelism).
 
 In the dot-product example, there are anti-dependencies introduced by
 instructions from different iterations.  However, those dependencies can be
 removed at register renaming stage (at the cost of allocating register aliases,
 and therefore consuming temporary registers).
 
 Table "Average Wait times" helps diagnose performance issues that are caused by
 the presence of long latency instructions and potentially long data dependencies
 which may limit the ILP.  Note that the tool by default assumes at least 1cy
 between the dispatch event and the issue event.
 
 When the performance is limited by data dependencies and/or long latency
 instructions, the number of cycles spent while in the "ready" state is expected
 to be very small when compared with the total number of cycles spent in the
 scheduler's queue.  So the difference between the two counters is a good
 indicator of how big of an impact data dependencies had on the execution of
 instructions.  When performance is mostly limited by the lack of hardware
 resources, the delta between the two counters is small.  However, the number of
-cycles spent in the queue tends to be bigger (i.e. more than 1-3cy) especially
+cycles spent in the queue tends to be bigger (i.e., more than 1-3cy) especially
 when compared with other low latency instructions.
 
 Extra statistics to further diagnose performance issues.
 --------------------------------------------------------
 
 Flag '-verbose' enables extra statistics and performance counters for the
 dispatch logic, the reorder buffer, the retire control unit and the register
 file.

 JLSAGU,  0/12
 ///////////////////
 
 Based on the verbose report, the backend was only able to dispatch two
 instructions 51.5% of the time.  The dispatch group was limited to one
 instruction 44.6% of the cycles, which corresponds to 272 cycles.
 
 If we look at section "Dynamic Dispatch Stall Cycles", we can see how counter
-SCHEDQ reports 272 cycles.  Counter SCHEDQ is incremented every time the dispatch
-logic is unable to dispatch a full group of two instructions because the
-scheduler's queue is full.
+SCHEDQ reports 272 cycles.  Counter SCHEDQ is incremented every time the
+dispatch logic is unable to dispatch a full group of two instructions because
+the scheduler's queue is full.
 
 Section "Scheduler's queue usage" shows how the maximum number of buffer entries
-(i.e. scheduler's queue entries) used at runtime for resource JFPU01 reached its
-maximum. Note that AMD Jaguar implements three schedulers:
+(i.e., scheduler's queue entries) used at runtime for resource JFPU01 reached
+its maximum. Note that AMD Jaguar implements three schedulers:
   * JALU01 - A scheduler for ALU instructions
   * JLSAGU - A scheduler for address generation
   * JFPU01 - A scheduler floating point operations.
 
 The dot-product is a kernel of three floating point instructions (a vector
 multiply followed by two horizontal adds).  That explains why only the floating
 point scheduler appears to be used according to section "Scheduler's queue
 usage".
 
 A full scheduler's queue is either caused by data dependency chains, or by a
 sub-optimal usage of hardware resources.  Sometimes, resource pressure can be
 mitigated by rewriting the kernel using different instructions that consume
 different scheduler resources.  Schedulers with a small queue are less resilient
 to bottlenecks caused by the presence of long data dependencies.
 
 In this example, we can conclude that the IPC is mostly limited by data
 dependencies, and not by resource pressure.
 
 LLVM-MCA instruction flow
 -------------------------
 
 This section describes the instruction flow through the out-of-order backend, as
-well as the functional units involved in the process. 
+well as the functional units involved in the process.
 
 An instruction goes through a default sequence of stages:
     - Dispatch (Instruction is dispatched to the schedulers).
     - Issue (Instruction is issued to the processor pipelines).
     - Write Back (Instruction is executed, and results are written back).
     - Retire (Instruction is retired; writes are architecturally committed).
 
 The tool only models the out-of-order portion of a processor. Therefore, the
 instruction fetch and decode stages are not modeled. Performance bottlenecks in
 the frontend are not diagnosed by this tool.  The tool assumes that instructions
 have all been decoded and placed in a queue.  Also, the tool doesn't know
 anything about branch prediction.
 
 The long term plan is to make the process customizable, so that processors can
 define their own. This is a future work.
 
 Instruction Dispatch
 --------------------
 
 During the Dispatch stage, instructions are picked in program order from a queue
 of already decoded instructions, and dispatched in groups to the hardware
-schedulers.  The dispatch logic is implemented by class DispatchUnit in file
-Dispatch.h.
+schedulers.  The dispatch logic is implemented by class DispatchStage in file
+DispatchStage.h.
 
 The size of a dispatch group depends on the availability of hardware resources,
-and it cannot exceed the value of field 'DispatchWidth' in class DispatchUnit.
+and it cannot exceed the value of field 'DispatchWidth' in class DispatchStage.
 Note that field DispatchWidth defaults to the value of field 'IssueWidth' from
 the scheduling model.
 
 Users can override the DispatchWidth value with flag "-dispatch=<N>" (where 'N'
 is an unsigned quantity).
 
 An instruction can be dispatched if:
  - The size of the dispatch group is smaller than DispatchWidth
  - There are enough entries in the reorder buffer
  - There are enough temporary registers to do register renaming
  - Schedulers are not full.
 
-Since r329067, scheduling models can now optionally specify which register files
-are available on the processor. Class DispatchUnit(see Dispatch.h) would use
-that information to initialize register file descriptors.
+Since r329067, scheduling models can now optionally specify which register
+files are available on the processor. Class DispatchStage(see DispatchStage.h)
+would use that information to initialize register file descriptors.
 
 By default, if the model doesn't describe register files, the tool
 (optimistically) assumes a single register file with an unbounded number of
-temporary registers.  Users can limit the number of temporary registers that are
-globally available for register renaming using flag `-register-file-size=<N>`,
-where N is the number of temporaries.  A value of zero for N means 'unbounded'.
-Knowing how many temporaries are available for register renaming, the tool can
-predict dispatch stalls caused by the lack of temporaries.
+temporary registers.  Users can limit the number of temporary registers that
+are globally available for register renaming using flag
+`-register-file-size=<N>`, where N is the number of temporaries.  A value of
+zero for N means 'unbounded'.  Knowing how many temporaries are available for
+register renaming, the tool can predict dispatch stalls caused by the lack of
+temporaries.
 
 The number of reorder buffer entries consumed by an instruction depends on the
 number of micro-opcodes it specifies in the target scheduling model (see field
-'NumMicroOpcodes' of tablegen class ProcWriteResources and its derived classes;
+'NumMicroOpcodes' of TableGen class ProcWriteResources and its derived classes;
 TargetSchedule.td).
 
-The reorder buffer is implemented by class RetireControlUnit (see Dispatch.h).
-Its goal is to track the progress of instructions that are "in-flight", and
-retire instructions in program order.  The number of entries in the reorder
-buffer defaults to the value of field 'MicroOpBufferSize' from the target
-scheduling model.
+The reorder buffer is implemented by class RetireControlUnit (see
+DispatchStage.h).  Its goal is to track the progress of instructions that are
+"in-flight", and retire instructions in program order.  The number of entries
+in the reorder buffer defaults to the value of field 'MicroOpBufferSize' from
+the target scheduling model.
 
 Instructions that are dispatched to the schedulers consume scheduler buffer
 entries.  The tool queries the scheduling model to figure out the set of
 buffered resources consumed by an instruction.  Buffered resources are treated
 like "scheduler" resources, and the field 'BufferSize' (from the processor
-resource tablegen definition) defines the size of the scheduler's queue.
+resource TableGen definition) defines the size of the scheduler's queue.
 
 Zero latency instructions (for example NOP instructions) don't consume scheduler
 resources.  However, those instructions still reserve a number of slots in the
 reorder buffer.
 
 Instruction Issue
 -----------------
 

 instruction at register renaming stage.
 
 Load/Store Unit and Memory Consistency Model
 --------------------------------------------
 
 The tool attempts to emulate out-of-order execution of memory operations.  Class
 LSUnit (see file LSUnit.h) emulates a load/store unit implementing queues for
 speculative execution of loads and stores.
- 
 Each load (or store) consumes an entry in the load (or store) queue.  The number
 of slots in the load/store queues is unknown by the tool, since there is no
 mention of it in the scheduling model.  In practice, users can specify flag
 `-lqueue=N` (vic. `-squeue=N`) to limit the number of entries in the queue to be
 equal to exactly N (an unsigned value). If N is zero, then the tool assumes an
 unbounded queue (this is the default).
 
 LSUnit implements a relaxed consistency model for memory loads and stores. The
 rules are:
 1) A younger load is allowed to pass an older load only if there is no
    intervening store in between the two loads.
 2) An younger store is not allowed to pass an older store.
 3) A younger store is not allowed to pass an older load.
 4) A younger load is allowed to pass an older store provided that the load does
    not alias with the store.
 
-By default, this class conservatively (i.e. pessimistically) assumes that loads
-always may-alias store operations.  Essentially, this LSUnit doesn't perform any
-sort of alias analysis to rule out cases where loads and stores don't overlap
-with each other.  The downside of this approach however is that younger loads are
-never allowed to pass older stores.  To make it possible for a younger load to
-pass an older store, users can use the command line flag -noalias.  Under
-'noalias', a younger load is always allowed to pass an older store.
+By default, this class conservatively (i.e., pessimistically) assumes that loads
+always may-alias store operations.  Essentially, this LSUnit doesn't perform
+any sort of alias analysis to rule out cases where loads and stores don't
+overlap with each other.  The downside of this approach however is that younger
+loads are never allowed to pass older stores.  To make it possible for a
+younger load to pass an older store, users can use the command line flag
+-noalias.  Under 'noalias', a younger load is always allowed to pass an older
+store.
 
 Note that, in the case of write-combining memory, rule 2. could be relaxed a bit
 to allow reordering of non-aliasing store operations.  That being said, at the
 moment, there is no way to further relax the memory model (flag -noalias is the
 only option).  Essentially, there is no option to specify a different memory
 type (for example: write-back, write-combining, write-through; etc.) and
 consequently to weaken or strengthen the memory model.
 

 extended to expose more details, as long as they are opt-in for targets.
 
 The accuracy of the performance analysis is also affected by assumptions made by
 the processor model used by the tool.
 
 Most recent Intel and AMD processors implement dedicated LoopBuffer/OpCache in
 the hardware frontend to speedup the throughput in the presence of tight loops.
 The presence of these buffers complicates the decoding logic, and requires
-knowledge on the branch predictor too.  Class 'SchedMachineModel' in tablegen
+knowledge on the branch predictor too.  Class 'SchedMachineModel' in TableGen
 provides a field named 'LoopMicroOpBufferSize' which is used to describe loop
 buffers.  However, the purpose of that field is to enable loop unrolling of
 tight loops; essentially, it affects the cost model used by pass loop-unroll.
 
 At the current state, the tool only describes the out-of-order portion of a
 processor, and consequently doesn't try to predict the frontend throughput. That
 being said, this tool could be definitely extended in future to also account for
 the hardware frontend when doing performance analysis.  This would inevitably

 
 This model doesn't correctly describe processors where the dispatch/issue is a
 single stage. This is what happens for example in VLIW processors, where
 instructions are packaged and statically scheduled at compile time; it is up to
 the compiler to predict the latency of instructions and package issue groups
 accordingly. For such targets, there is no dynamic scheduling done by the
 hardware.
 
-Existing classes (DispatchUnit, Scheduler, etc.) could be extended/adapted to
+Existing classes (DispatchStage, Scheduler, etc.) could be extended/adapted to
 support processors with a single dispatch/issue stage. The execution flow would
-require some changes in the way how existing components (i.e.  DispatchUnit,
+require some changes in the way how existing components (i.e.,  DispatchStage,
 Scheduler, etc.) interact. This can be a future development.
 
 The following sections describes other known limitations.  The goal is not to
 provide an extensive list of limitations; we want to report what we believe are
 the most important limitations, and suggest possible methods to overcome them.
 
 Load/Store barrier instructions and serializing operations
 ----------------------------------------------------------

 Here, register %eax is only partially updated. To be more specific, the lower
 half of %eax is set, and the upper half is left unchanged. There is also no
 change in the upper 48 bits of register %rax.
 
 To get accurate performance analysis, the tool has to know which instructions
 perform a partial register update, and which instructions fully update the
 destination's super-register.
 
-One way to expose this information is (again) via tablegen.  For example, we
-could add a flag in the tablegen instruction class to tag instructions that
+One way to expose this information is (again) via TableGen.  For example, we
+could add a flag in the TableGen instruction class to tag instructions that
 perform partial register updates. Something like this: 'bit
 hasPartialRegisterUpdate = 1'. However, this would force a `let
 hasPartialRegisterUpdate = 0` on several instruction definitions.
 
 Another approach is to have a MCSubtargetInfo hook similar to this:
     virtual bool updatesSuperRegisters(unsigned short opcode) { return false; }
 
 Targets will be able to override this method if needed.  Again, this is just an
 idea. But the plan is to have this fixed as a future development.
 
 2) Macro Op fusion.
 
 The tool doesn't know about macro-op fusion. On modern x86 processors, a
 'cmp/test' followed by a 'jmp' is fused into a single macro operation.  The
 advantage is that the fused pair only consumes a single slot in the dispatch
-group. 
+group.
 
 As a future development, the tool should be extended to address macro-fusion.
 Ideally, we could have LLVM generate a table enumerating all the opcode pairs
 that can be fused together. That table could be exposed to the tool via the
 MCSubtargetInfo interface.  This is just an idea; there may be better ways to
 implement this.
 
 3) Intel processors: mixing legacy SSE with AVX instructions.

 In LLVM, class MCInstrDesc is used to fully describe target instructions and
 their operands. The opcode of a machine instruction (a MachineInstr object) can
 be used to query the instruction set through method `MCInstrInfo::get' to obtain
 the associated MCInstrDesc object.
 
 However class MCInstrDesc describes properties and operands of MachineInstr
 objects. Essentially, MCInstrDesc is not meant to be used to describe MCInst
 objects.  To be more specific, MCInstrDesc objects are automatically generated
-via tablegen from the instruction set description in the target .td files.  For
+via TableGen from the instruction set description in the target .td files.  For
 example, field `MCInstrDesc::NumDefs' is always equal to the cardinality of the
-`(outs)` set from the tablegen instruction definition.
+`(outs)` set from the TableGen instruction definition.
 
 By construction, register definitions always appear at the beginning of the
 MachineOperands list in MachineInstr. Basically, the (outs) are the first
 operands of a MachineInstr, and the (ins) will come after in the machine operand
 list. Knowing the number of register definitions is enough to identify
 all the register operands that are definitions.
 
 In a normal compilation process, MCInst objects are generated from MachineInstr
 objects through a lowering step. By default the lowering logic simply iterates
 over the machine operands of a MachineInstr, and converts/expands them into
 equivalent MCOperand objects.
 
-The default lowering strategy has the advantage of preserving all of the
-above mentioned assumptions on the machine operand sequence. That means, register
+The default lowering strategy has the advantage of preserving all of the above
+mentioned assumptions on the machine operand sequence. That means, register
 definitions would still be at the beginning of the MCOperand sequence, and
 register uses would come after.
 
 Targets may still define custom lowering routines for specific opcodes. Some of
 these routines may lower operands in a way that potentially breaks (some of) the
 assumptions on the machine operand sequence which were valid for MachineInstr.
 Luckily, this is not the most common form of lowering done by the targets, and
 the vast majority of the MachineInstr are lowered based on the default strategy
 which preserves the original machine operand sequence.  This is especially true
-for x86, where the custom lowering logic always preserves the original (i.e.
+for x86, where the custom lowering logic always preserves the original (i.e.,
 from the MachineInstr) operand sequence.
 
 This tool currently works under the strong (and potentially incorrect)
 assumption that register def/uses in a MCInst can always be identified by
 querying the machine instruction descriptor for the opcode. This assumption made
 it possible to develop this tool and get good numbers at least for the
 processors available in the x86 backend.
 
 That being said, the analysis is still potentially incorrect for other targets.
 So we plan (with the help of the community) to find a proper mechanism to map
 when possible MCOperand indices back to MachineOperand indices of the equivalent
 MachineInstr.  This would be equivalent to describing changes made by the
 lowering step which affected the operand sequence. For example, we could have an
 index for every register MCOperand (or -1, if the operand didn't exist in the
 original MachineInstr). The mapping could look like this <0,1,3,2>.  Here,
 MCOperand #2 was obtained from the lowering of MachineOperand #3. etc.
 
-This information could be automatically generated via tablegen for all the
+This information could be automatically generated via TableGen for all the
 instructions whose custom lowering step breaks assumptions made by the tool on
 the register operand sequence (In general, these instructions should be the
 minority of a target's instruction set). Unfortunately, we don't have that
 information now.  As a consequence, we assume that the number of explicit
 register definitions is the same number specified in MCInstrDesc.  We also
 assume that register definitions always come first in the operand sequence.
 
 In conclusion: these are for now the strong assumptions made by the tool:

llvm/trunk/tools/llvm-mca/RetireControlUnit.h

 #include "Instruction.h"
 #include "llvm/MC/MCSchedule.h"
 
 #include <algorithm>
 #include <vector>
 
 namespace mca {
 
-class DispatchUnit;
+class DispatchStage;
 
 /// This class tracks which instructions are in-flight (i.e., dispatched but not
 /// retired) in the OoO backend.
 //
 /// This class checks on every cycle if/which instructions can be retired.
 /// Instructions are retired in program order.
-/// In the event of instruction retired, the DispatchUnit object that owns
+/// In the event of instruction retired, the DispatchStage object that owns
 /// this RetireControlUnit (RCU) gets notified.
 /// On instruction retired, register updates are all architecturally
 /// committed, and any temporary registers originally allocated for the
 /// retired instruction are freed.
 struct RetireControlUnit {
   // A RUToken is created by the RCU for every instruction dispatched to the
   // schedulers.  These "tokens" are managed by the RCU in its token Queue.
   //
struct RetireControlUnit {
   };
 
 private:
   unsigned NextAvailableSlotIdx;
   unsigned CurrentInstructionSlotIdx;
   unsigned AvailableSlots;
   unsigned MaxRetirePerCycle; // 0 means no limit.
   std::vector<RUToken> Queue;
-  DispatchUnit *Owner;
+  DispatchStage *Owner;
 
 public:
-  RetireControlUnit(const llvm::MCSchedModel &SM, DispatchUnit *DU);
+  RetireControlUnit(const llvm::MCSchedModel &SM, DispatchStage *DU);
 
   bool isFull() const { return !AvailableSlots; }
   bool isEmpty() const { return AvailableSlots == Queue.size(); }
   bool isAvailable(unsigned Quantity = 1) const {
     // Some instructions may declare a number of uOps which exceedes the size
     // of the reorder buffer. To avoid problems, cap the amount of slots to
     // the size of the reorder buffer.
     Quantity = std::min(Quantity, static_cast<unsigned>(Queue.size()));

llvm/trunk/tools/llvm-mca/RetireControlUnit.cpp

 //===---------------------- RetireControlUnit.cpp ---------------*- C++ -*-===//
 //
 //                     The LLVM Compiler Infrastructure
 //
 // This file is distributed under the University of Illinois Open Source
 // License. See LICENSE.TXT for details.
 //
 //===----------------------------------------------------------------------===//
 /// \file
 ///
 /// This file implements methods declared by the RetireControlUnit interface.
 ///
 //===----------------------------------------------------------------------===//
 
-#include "Dispatch.h"
 #include "RetireControlUnit.h"
+#include "DispatchStage.h"
 #include "llvm/Support/Debug.h"
 
 using namespace llvm;
 
 #define DEBUG_TYPE "llvm-mca"
 
 namespace mca {
 
 RetireControlUnit::RetireControlUnit(const llvm::MCSchedModel &SM,
-                                     DispatchUnit *DU)
+                                     DispatchStage *DS)
     : NextAvailableSlotIdx(0), CurrentInstructionSlotIdx(0),
-      AvailableSlots(SM.MicroOpBufferSize), MaxRetirePerCycle(0), Owner(DU) {
+      AvailableSlots(SM.MicroOpBufferSize), MaxRetirePerCycle(0), Owner(DS) {
   // Check if the scheduling model provides extra information about the machine
   // processor. If so, then use that information to set the reorder buffer size
   // and the maximum number of instructions retired per cycle.
   if (SM.hasExtraProcessorInfo()) {
     const MCExtraProcessorInfo &EPI = SM.getExtraProcessorInfo();
     if (EPI.ReorderBufferSize)
       AvailableSlots = EPI.ReorderBufferSize;
     MaxRetirePerCycle = EPI.MaxRetirePerCycle;

llvm/trunk/tools/llvm-mca/Scheduler.h

 #include "LSUnit.h"
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/MC/MCSubtargetInfo.h"
 #include <map>
 
 namespace mca {
 
 class Backend;
-class DispatchUnit;
+class DispatchStage;
 
 /// Used to notify the internal state of a processor resource.
 ///
 /// A processor resource is available if it is not reserved, and there are
 /// available slots in the buffer.  A processor resource is unavailable if it
 /// is either reserved, or the associated buffer is full. A processor resource
 /// with a buffer size of -1 is always available if it is not reserved.
 ///
class Scheduler {
   // Hardware resources that are managed by this scheduler.
   std::unique_ptr<ResourceManager> Resources;
   std::unique_ptr<LSUnit> LSU;
 
   // The Backend gets notified when instructions are ready/issued/executed.
   Backend *const Owner;
 
   // The dispatch unit gets notified when instructions are executed.
-  DispatchUnit *DU;
+  DispatchStage *DS;
 
   using QueueEntryTy = std::pair<unsigned, Instruction *>;
   std::map<unsigned, Instruction *> WaitQueue;
   std::map<unsigned, Instruction *> ReadyQueue;
   std::map<unsigned, Instruction *> IssuedQueue;
 
   void
   notifyInstructionIssued(const InstRef &IR,

 public:
   Scheduler(Backend *B, const llvm::MCSchedModel &Model, unsigned LoadQueueSize,
             unsigned StoreQueueSize, bool AssumeNoAlias)
       : SM(Model), Resources(llvm::make_unique<ResourceManager>(SM)),
         LSU(llvm::make_unique<LSUnit>(LoadQueueSize, StoreQueueSize,
                                       AssumeNoAlias)),
         Owner(B) {}
 
-  void setDispatchUnit(DispatchUnit *DispUnit) { DU = DispUnit; }
+  void setDispatchStage(DispatchStage *DispStage) { DS = DispStage; }
 
   /// Check if the instruction in 'IR' can be dispatched.
   ///
-  /// The DispatchUnit is responsible for querying the Scheduler before
+  /// The DispatchStage is responsible for querying the Scheduler before
   /// dispatching new instructions. Queries are performed through method
-  /// `Scheduler::CanBeDispatched`. If scheduling resources are available,
+  /// `Scheduler::canBeDispatched`. If scheduling resources are available,
   /// and the instruction can be dispatched, then this method returns true.
   /// Otherwise, a generic HWStallEvent is notified to the listeners.
   bool canBeDispatched(const InstRef &IR) const;
   void scheduleInstruction(InstRef &IR);
 
   /// Issue an instruction.
   void issueInstruction(InstRef &IR);
 

llvm/trunk/tools/llvm-mca/Scheduler.cpp

void Scheduler::notifyInstructionIssued(
   Owner->notifyInstructionEvent(HWInstructionIssuedEvent(IR, Used));
 }
 
 void Scheduler::notifyInstructionExecuted(const InstRef &IR) {
   LSU->onInstructionExecuted(IR);
   LLVM_DEBUG(dbgs() << "[E] Instruction Executed: " << IR << '\n');
   Owner->notifyInstructionEvent(
       HWInstructionEvent(HWInstructionEvent::Executed, IR));
-  DU->onInstructionExecuted(IR.getInstruction()->getRCUTokenID());
+  DS->onInstructionExecuted(IR.getInstruction()->getRCUTokenID());
 }
 
 void Scheduler::notifyInstructionReady(const InstRef &IR) {
   LLVM_DEBUG(dbgs() << "[E] Instruction Ready: " << IR << '\n');
   Owner->notifyInstructionEvent(
       HWInstructionEvent(HWInstructionEvent::Ready, IR));
 }