[PATCH] D35816: [Greedy RegAlloc] Add logic to greedy reg alloc to avoid bad eviction chains

[Quentin Colombet via Phabricator via llvm-commits]

qcolombet added a comment.

Hi Marina,

I had a quick look at the patch and I am not sure this the right approach.
The patch tries to avoid splitting when it might be part of a bad eviction chain, but I would argue there is no such thing as bad eviction chain. The evictions happened to relax the constraints on the allocation problem and blocking the splitting it won't help.
Now, unless phabricator is not showing everything (it is acting weird since the patch is quite big), my understanding of the patch is that it  actually does not prevent eviction chains, it just resorts on less fancy splitting heuristics, which happens to spread splitting decisions around instead of having them localized at regions boundaries. Thus, we may still have eviction chains but they may be harder to spot.

Generally speaking, split points are not bad. What is bad though is the fact that we make poor allocation decisions that prevent to get rid of them later. I would focus my effort on that front if I were you.
For instance, in the example from the PR, I believe the bunch of copies don't get coalesced because we choose the color for the less constrained live-range first. That is if we were to allocate vreg79 first, then I believe vreg80 could use that as a hint eliminating one of the copy. Same for vreg81 and vreg82 and so on.
However, what happened is that we allocate vreg80 first and the allocation order makes it such that vreg79 won't be able to satisfy the hint, since what we pick interferes with what vreg79 can use. Given we have the same structure before and after the split point, the live-ranges get allocated in the order. Thus, the first mistake propagates through all the live-range (vreg79 prevents vreg81 to satisfy its live-range and so on).
For instance, if we were to delay vreg79, I believe we would satisfy all hints.

There is a lot of speculation in what I described for the example from the PR. I will try to spend some time verifying if any of those changes would indeed fix this problem.
In particular, I believe the problem can be solved with some tweaks in:

- TargetRegisterInfo::getRegAllocationHints (e.g., we could give a hint to vreg80 so that it avoids vreg79 interferences)
- Priority when enqueueing live-ranges
- Consider the cost of using a register that is going to create a broken hint down the road when assigning a color (similar idea than first item)
- Try to reconcile hints that are in the same region instead of one at a time

The last point is probably the one that is going to less affect existing code and thus would be probably the easiest to qualify.

Cheers,
-Quentin


Repository:
  rL LLVM

https://reviews.llvm.org/D35816