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

[Quentin Colombet via llvm-commits]

> On Aug 15, 2017, at 5:27 PM, Marina Yatsina via Phabricator <reviews at reviews.llvm.org> wrote:
> 
> myatsina added a comment.
> 
> As far as I read (http://www.eecs.umich.edu/~mahlke/papers/1993/hwu_jsuper93.pdf), in order to create superblocks, we need to identify traces using execution profile information, and then do tail duplication to avoid multiple entrances.
> According the authors of this technique, this transformation as itself takes significant amount of code and compile time.
> I don’t think this transformation is something we should do only for the sake of machine copy propagation pass, as it adds significant complexity.
> The decision of supporting this transformation and the possible optimizations that can benefit from it seems like an orthogonal discussion that is not directly related to this bad eviction chains I’m trying to solve.
> 
> Even if I do have some transformation to superblocks that have single entry and multiple exists, I will still need to do liveness tracking over all possible paths to maintain correctness:
> 
> bb1:
> xmm0 = copy xmm1
> xmm1 = copy xmm2
> xmm2 = copy xmm3
> ...
> 
> test
> je bb3
> 
> bb2:
> xmm3 = copy xmm2
> xmm2 = copy xmm1
> xmm1 = copy xmm0
> return
> 
> bb3:
> return
> 
> The path bb1->bb2 can benefit from the change, but it is not legal for me to this change if a paths like bb1->bb3 exits – I need to scan all paths.

The copy propagation only forwards copies. Put differently, it only removes copies on the paths that are valid forward.
So for this example, by just running machine copy propagation on the super block bb1-bb2, we would get rid of the xmm1 = copy xmm0 in bb2.

> 
> For each suspected copy chain I will need to track a whole subtree in this superblock CFG which begins with the first copy of the chain.

Machine copy propagation is about 1 copy at a time as opposed as 1 chain, so yeah that will not help removing the full chain.

> I will need to make sure all possible paths from that first copy contain the whole chain and that there is no path that clobbers one of the registers in the middle of that chain.
> So I find myself doing some sort of liveness tracking here too.
> I know my original solution added complexity to Greedy, but Greedy’s decisions are the source of this issue, and it doesn’t seem like we have an elegant way to clean up the consequences of those decisions when we’re talking about cross-BB chains.

Fair enough, I’ll have a closer look. I was hoping we’ll get most of the benefits with machine copy propagation, possibly by extending it to work at a super block level (I am not binding the notion of super block to the paper you’ve mentioned, just simple entry multiple, we could go with fall through for the choice of super block and we don’t need to deal with duplication stuff at least for that optimization), but looks like it is not the case.

Cheers,
-Quentin
> 
> Thanks,
> Marina
> 
> 
> Repository:
>  rL LLVM
> 
> https://reviews.llvm.org/D35816
> 
> 
>