[llvm] [AMDGPU] Add and optionally use GCNIterativeRPTrackers (PR #88797)

[Jeffrey Byrnes via llvm-commits]

jrbyrnes wrote:

> Would be nice if you add a few words explaining overall approach. I'm curious why these new trackers are iterative, is it just a name to distinguish them from current?

I'll explain the approach by defining the issues. 

`GCNSchedStrategy` uses `GCNDownwardRPTracker` in a couple different places to calculate the pressure of a region. At these points, the schedule is in a steady state, so the tracker can scan through the region in order. Thus, it is okay to internalize the iterators (`LastTrackedMI`, `NextMI`, `MBBEnd`), which the tracker maintains through calls to `advance()` / `advanceBeforeNext()` / `advanceToNext()`. Obviously during scheduling the order is subject to change, so these internal iterators don't make sense -- at least not in the way they are currently maintained. Moreover, with these, there is no good way to query the impact a candidate `SU` will have on RP (`initCandidate`) since calls to `advance*` will update the iterators.

On the other hand, `GCNIterativeDownwardRPTracker` does not assume an in-order scan of a region, so it does not suffer from the above problems. I named it iterative because we are incrementally constructing the order, but I'm not very confident about the naming. Note that the `GCNUpwardRPTracker` has a more friendly interface for this use-case, but I also implemented `GCNIterativeUpwardRPTracker` since scheduling is bi-directional, and having a shared base class is the cleaner approach.

As noted in the code, the actual RP calculation implemention is largely copy & paste from the existing trackers. Note: when calculating RP, we call `getRegKind` which treats `%AV` registers as `VGPR`. During scheduling, we use the trackers to update the state of RP when we `schedNode`, and use this state to measure the impact of candidate `SU` in `initCandidate`. When first scheduling a region, we initialize the tackers with the LiveIn (Downward) / LiveOut (Upward) registers as calculated by the existing `getLiveRegMap`. This calculation is global live-thru aware (as opposed to the generic tracker which isn't https://github.com/llvm/llvm-project/blob/047b2b241defcad79a6ac0fec9cda092bac0a922/llvm/lib/CodeGen/RegisterPressure.cpp#L355 ).

The generic trackers are still maintained through scheduling, but the meaningful usecase of them is when picking between candidate SUs, and that usecase has been replaced with our trackers (`initCandidate`).

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