[PATCH] D54957: [llvm-mca][MC] Add the ability to declare which processor resources model load/store queues (PR36666).

[Andrea Di Biagio via Phabricator via llvm-commits]

andreadb created this revision.
andreadb added reviewers: RKSimon, spatel, evandro, courbet, gchatelet, mattd.
Herald added subscribers: gbedwell, tschuett, javed.absar.

This patch adds the ability to specify via tablegen which processor resources are load/store queue resources.

A new tablegen class named `MemoryQueue` can be optionally used to mark resources that model load/store queues.
Information about the load/store queue is collected at CodeGenSchedule stage, and analyzed by the SubtargetEmitter to initialize two new fields in `struct MCExtraProcessorInfo` named `LoadQueueID` and `StoreQueueID`.
Those two fields are identifiers for buffered resources used to describe the load queue and the store queue.
Field `BufferSize` is interpreted as the number of entries in the queue, while the number of units is a throughput indicator (i.e. number of available pickers for loads/stores).

At construction time, LSUnit in llvm-mca checks for the presence of extra processor information (i.e. MCExtraProcessorInfo) in the scheduling model.
If that information is available, and fields `LoadQueueID` and `StoreQueueID` are set to a value different than zero (i.e. the invalid processor resource index), then LSUnit initializes its LoadQueue/StoreQueue based on the `BufferSize` value declared by the two processor resources.

With this patch, we more accurately track dynamic dispatch stalls caused by the lack of LS tokens (i.e. load/store queue full). This is also shown by the differences in two BdVer2 tests. Stalls that were previously classified as generic SCHEDULER FULL stalls, are not correctly classified either as "load queue full" or "store queue full".

About the minor differences in the -scheduler-stats view:
those differences are expected, because entries in the load/store queue are not released when at `instruction issue` stage. Those are only released at `instruction executed` stage. This is the main reason why in some tests the load/store queues become full before PdEx is full.

Let me know if okay to commit.

-Andrea


https://reviews.llvm.org/D54957

Files:
  include/llvm/MC/MCSchedule.h
  include/llvm/Target/TargetSchedule.td
  lib/Target/X86/X86ScheduleBdVer2.td
  test/tools/llvm-mca/X86/BdVer2/load-throughput.s
  test/tools/llvm-mca/X86/BdVer2/store-throughput.s
  tools/llvm-mca/Views/SchedulerStatistics.cpp
  tools/llvm-mca/Views/SchedulerStatistics.h
  tools/llvm-mca/include/HardwareUnits/LSUnit.h
  tools/llvm-mca/lib/Context.cpp
  tools/llvm-mca/lib/HardwareUnits/LSUnit.cpp
  tools/llvm-mca/llvm-mca.cpp
  utils/TableGen/CodeGenSchedule.cpp
  utils/TableGen/CodeGenSchedule.h
  utils/TableGen/SubtargetEmitter.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D54957.175509.patch
Type: text/x-patch
Size: 39727 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20181127/9a25ef44/attachment.bin>