[llvm-commits] [patch] Improve register coalescing

Rafael Ávila de Espíndola rafael.espindola at gmail.com
Sat Jul 2 12:01:24 PDT 2011


>> 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.

Note that this is just an idea for what to do if we run on another case 
the current coalescer cannot handle. I am not proposing implementing it 
right now.

It is kept on the worklist. We stop when no conflict is found in all of 
the worklist. Since splits always make the sets smaller, the termination 
is trivial (but getting good performance wouldn't).

> 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.

Thanks. I found searching for papers/docs on this area really hard. As I 
mentioned, all cases that I found were combined phi elim and coalescing 
or the coalescing part started with "build an interference graph".

I hope I didn't reinvent the wheel too badly :-)

P.S.: I will try a build of firefox with the strong phi elimination and 
open a bug with the testcase if it still fails.

> Cameron

Cheers,
Rafael



More information about the llvm-commits mailing list