MCSchedModel: Add comments to IssueWidth.

[jonpa]

With inspiration from your reply, perhaps begin with something like:

The MCSchedModel (in contrast to InstrItineraries) is an abstract machine used for modeling predictable physical machine features. It is built around the notion...

I think this is a very important point.

include/llvm/MC/MCSchedule.h

203

Maybe remove this now?

212

"to model to" -> "to model"

213

What happens if there is no bottleneck after decoder - IssueWidth then is typically the decoder capacity?

[jonpa]

Very helpful!
LGTM.

[atrick]

Landed here

Author: atrick <atrick@91177308-0d34-0410-b5e6-96231b3b80d8>
Date: Fri May 18 08:57:54 2018

MCSchedModel: Add comments to IssueWidth.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@332729 91177308-0d34-0410-b5e6-96231b3b80d8

And I forgot to put a "Differential Revision" tag in the commit. I'll close this manually.

include/llvm/MC/MCSchedule.h

 /// microarchitecture to the scheduler in the form of properties. It also
 /// optionally refers to scheduler resource tables and itinerary
 /// tables. Scheduler resource tables model the latency and cost for each
 /// instruction type. Itinerary tables are an independent mechanism that
 /// provides a detailed reservation table describing each cycle of instruction
 /// execution. Subtargets may define any or all of the above categories of data
 /// depending on the type of CPU and selected scheduler.
 struct MCSchedModel {
   // IssueWidth is the maximum number of instructions that may be scheduled in
   // the same per-cycle group.
+  //
+  // The abstract pipeline is built around the notion of an "issue point". This
+  // is merely a reference point for counting machine cycles.  IssueWidth is
+  // meant to be a hard in-order constraint (we sometimes call this kind of
+  // constraint a "hazard"). In the GenericScheduler strategy, no more than
+  // IssueWidth micro-ops can ever be scheduled in a particular cycle.
+  //
+  // In practice, IssueWidth is useful to model to the bottleneck between the
+  // decoder (after micro-op expansion) and the out-of-order reservation
+  // stations. If the total number of reservation stations is also a bottleneck,
+  // or if any other pipeline stage has a bandwidth limitation, then that can be
+  // naturally modeled by adding an out-of-order processor resource.
   unsigned IssueWidth;
   static const unsigned DefaultIssueWidth = 1;
 
   // MicroOpBufferSize is the number of micro-ops that the processor may buffer
   // for out-of-order execution.
   //
   // "0" means operations that are not ready in this cycle are not considered
   // for scheduling (they go in the pending queue). Latency is paramount. This