[llvm-commits] [patch] Improve register coalescing

[Cameron Zwarich]

On 2011-06-30, at 2:36 PM, Rafael Ávila de Espíndola wrote:

> An updated copy is attached.
> 
>> Would it be possible to do more complete value-based checking? For
>> example, you don't handle this:
>> 
>> X = Y A = X B = Y
> 
> but it doesn't handle this, we would have to coalesce X and Y first (which might fail).
> 
> The real solution I think would be to turn the coalescing algorithm
> upside down: instead of trying to merge registers one pair at a time,
> start by assuming that every copy related register can be merged and
> try to show it cannot.

If you consider a pair and can't show that it cannot be merged, what do you do with it? Throw it back onto a worklist? Then you run into termination issues. If you remove it from consideration, then you're not doing anything fundamentally different than merging them one pair at a time.

Two variables with the same value don't interfere, and your copy chains suggestion simply causes more pairs of values to be recognized as identical. You could substitute any sound value numbering and the existing coalescing algorithm would be able to incorporate it.

There is one technique I have seen that is similar in spirit to your suggestion to assume that all copy-related registers can be merged. If you do coalescing with phis or parallel copies still in place, you can modify your heuristic to first search for a maximal non-interfering subset of the registers involved in that phi / parallel copy, and then merge those together first.

This is probably the best paper on the problem of phi elimination and the coalescing that ensues:

http://perso.ens-lyon.fr/fabrice.rastello/Biblio_Perso/Articles/CGO2009.pdf

The trick in the patch you just landed is called "copy sharing" there. Of course, our coalescer does a lot of important tricks involving cross-class copies, subregisters, and 2-address instructions that don't really show up anywhere in the literature.

Cameron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110701/4135e1b2/attachment.html>