[llvm] [CodeGen][MISched] Add misched post-regalloc bidirectional scheduling (PR #77138)

Michael Maitland via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 29 07:28:17 PST 2024


================
@@ -51,3 +61,6 @@ body:             |
 # BOTTOMUP-NEXT: SU(1):   renamable $x13 = ADD renamable $x11, renamable $x10
 # BOTTOMUP-NEXT: SU(0):   renamable $x12 = MUL renamable $x11, renamable $x10
 # BOTTOMUP-NEXT: SU(2):   renamable $x14 = DIVW renamable $x12, renamable $x13
+
+# BIDIRECTIONAL: *** Final schedule for %bb.0 ***
+# BIDIRECTIONAL-NEXT: * Schedule table (Bidirectional): not implemented
----------------
michaelmaitland wrote:

I want to reflect on my usage of the topdown table and the bottomup table. They were useful in helping me understand (a) resource utilization of the final schedule, (b) where the pipeline faced stalls, and (c) where pipeline was able to take advantage of parallelism. I think that llvm-mca could be a good candidate to extract this kind of information as well, although I concede that the tables here allow us to work on pseudo instructions and virtual registers, which does communicate some finer grained information.

I assumed the reason we do not model bidirectional table is because there is ambiguity in how it might be presented. There are three main concerns I can think of:

(1) The topdown print out starts at cycle 0 and each subsequent cycle increases by 1. For bottomup it starts at cycle N and counts down to cycle zero. We would need to have a useful way to impose the two on top of each other for bidirectional. I initially thought about doing something like:

```
topdown:  1 2 3 4
bottomup: 4 3 2 1
```

but I have noticed that the number of topdown cycles is not always equal to the number of bottom up cycles.

(2) For the sake of the point I am going to make, assume a case that the number of top down cycles is equal to the number of bottom up cycles: I predict that a bottom up view could model an instruction issued on different absolute cycle than the topdown view modeled the same instruction to be issued. 
```
topdown:  1 2 3 4
bottomup: 4 3 2 1
absolute:   0 1 2 3

ADD            i i  // <======= maybe the topdown view had the add issued on absolute cycle 0 but bottomup view had the add issued on absolute cycle 1.
```

It may be tricky to represent both views at the same time for these two reasons. How do you model subsequent instructions interacting with both possibilities?

(3) In the bidirectional scheduler there is the notion that you could schedule from top or bottom each time you pick a node to be scheduled. Would such a table be able to capture when the decision came from a top choice or a bottom choice? This information is captured in the debug output that precedes the table. Would this data impact the way the table is generated? 

In summary, there is some ambiguity on what the table would look like. I think that llvm-mca might be able to communicate some of the information that these tables intend to communicate, but not all of it. I am open to us adding this bidirectional table in the future, but we need to think how the data would be presented.

https://github.com/llvm/llvm-project/pull/77138


More information about the llvm-commits mailing list