[llvm-dev] [MachineScheduler] Question about IssueWidth / NumMicroOps

[Jonas Paulsson via llvm-dev]

Hi Andrew,

Thank you very much for the most helpful explanations! Many things could 
go in as comments, if you ask me - for example:

---
> The LLVM machine model is an abstract machine.

> 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.

---

> I don't think IssueWidth necessarily has anything to do with instruction decoding or the execution capacity of functional units. I will say that we expect the decoding capacity to "keep up with" the issue width. If the IssueWidth property also serves that purpose for you, I think that's fine. In the case of the x86 machine models above, since each instruction is a micro-op, I don't see any useful distinction between decode bandwidth and in-order issue of micro-ops.
I think this is mostly true for SystemZ also since the majority of 
instructions are basically a single micro-op.

>
> (caveat: there may still be GenericScheduler implementation deficiencies because it is trying to support more scheduling features than we have in-tree targets).
Right now it seems that BeginGroup/EndGroup is only used by SystemZ, or? 
I see they are used in checkHazard(), which I actually don't see as 
helpful during pre-RA scheduling for SystemZ. Could this be made 
optional, or perhaps only done post-RA if target does post-RA 
scheduling? SystemZ does post-RA scheduling to manage decoder grouping, 
which is where the BeginGroup/EndGroup and IssueWidth/NumMicroOps is 
useful. However doing this pre-RA and thereby limiting the freedom of 
other heuristics (making less instructions available) seems like a bad idea.

> Sorry, I don't have time to draw diagrams and tables. Hopefully you can makes sense of my long-form rambling.
Yes, very helpful to me :-)

Thanks again,

Jonas