[MISched] Add statistics to quantify scheduling

[c-rhodes]

When diagnosing scheduler issues it can be useful to know how scheduling changes the order of instructions, particularly for large functions when it's not trivial to figure out from the debug output by looking at the scheduling unit (SU) IDs.

This adds pre-RA and post-RA statistics to track 1) the number of instructions that remain in source order after scheduling and 2) the total number of instructions scheduled, to compare 1) against.

[mshockwave]

LGTM

[davemgreen]

A question about how this works - If you start with A;B;C;D;E and reorder it to A;E;B;C;D, does only 1 node count as in-order, or do 4? Is 4 nodes being inorder covered by #137981 (at least if they pick NodeOrder to remain in-order).

[c-rhodes]

A question about how this works - If you start with A;B;C;D;E and reorder it to A;E;B;C;D, does only 1 node count as in-order, or do 4? Is 4 nodes being inorder covered by #137981 (at least if they pick NodeOrder to remain in-order).

1, I fail to see how it could be 4, only A is in source order there?

As for NodeOrder it doesn't tell the full picture, a node can be picked due to some other heuristic but still be in source order. In the worst case this can mean the scheduler didnt change a thing, here's such an example:

llc foo.ll -mcpu=native -stats 2>&1 | grep machine-scheduler | grep pre
 157 machine-scheduler     - Number of scheduling units chosen from bottom queue pre-RA
  29 machine-scheduler     - Number of scheduling units chosen for FirstValid heuristic pre-RA
 161 machine-scheduler     - Number of instructions in source order after pre-RA scheduling
 161 machine-scheduler     - Number of instructions scheduled by pre-RA scheduler
 120 machine-scheduler     - Number of scheduling units chosen for NodeOrder heuristic pre-RA
   8 machine-scheduler     - Number of scheduling units chosen for Only1 heuristic pre-RA
   4 machine-scheduler     - Number of scheduling units chosen for PhysReg heuristic pre-RA
   4 machine-scheduler     - Number of scheduling units chosen from top queue pre-RA

[davemgreen]

A question about how this works - If you start with A;B;C;D;E and reorder it to A;E;B;C;D, does only 1 node count as in-order, or do 4? Is 4 nodes being inorder covered by #137981 (at least if they pick NodeOrder to remain in-order).

1, I fail to see how it could be 4, only A is in source order there?

I was wondering what the definition of inorder was it was using. Another example like A;E;C;D;B would have 3 nodes 'inorder' IIUC (even though it is more out-of-order than the first example)? To me moving one node in A;E;B;C;D would be a small change and most nodes remain inorder except for it. But I was just interested in how this worked and didn't realize you had submitted it before I left the comment. It sounds useful either way.

[c-rhodes]

A question about how this works - If you start with A;B;C;D;E and reorder it to A;E;B;C;D, does only 1 node count as in-order, or do 4? Is 4 nodes being inorder covered by #137981 (at least if they pick NodeOrder to remain in-order).

1, I fail to see how it could be 4, only A is in source order there?

I was wondering what the definition of inorder was it was using. Another example like A;E;C;D;B would have 3 nodes 'inorder' IIUC (even though it is more out-of-order than the first example)? To me moving one node in A;E;B;C;D would be a small change and most nodes remain inorder except for it.

that's a fair point, this is simply "does the index of the instruction change after scheduling?"