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

[Quentin Colombet via llvm-commits]

> On Sep 25, 2017, at 8:46 AM, Marina Yatsina via Phabricator <reviews at reviews.llvm.org> wrote:
> 
> myatsina added a comment.
> 
> Hi Quentin,
> 
> I wouldn’t say my patch tries to avoid splitting, but rather tries to improve the calculation of the spill weight of split candidates:
> When the register allocator decides to do a region split, it looks for the best physical register candidate for the split.
> The best candidate is the one that will cause the minimal spill cost.
> When calculating the spill cost of each candidate the algorithm takes into account interferences in the entrance/exist of the basic blocks.
> However, there may be interference local to a basic block, which later, during the split itself will cause the creation of a new local interval (which will be local to the basic block) on top of the “by reg” and “by stack” intervals which are created during the split.
> The algorithm currently ignores the fact that this local interval may cause spills (and thus may increase the spill weight of this candidate for the split).
> 
> My solution is to try to predict if this split candidate will case the creation of local intervals and if they in turn will cause spills, and add their spill weights to the total weight.
> By doing so, I try to make the spill weight calculation of each candidate more accurate and allow the algorithm to choose a more suitable candidate.
> 
> If a local interval is created then we have a few options for its allocation:
> 
> 1. The interval will be allocated to some free reg – no additional spill cost needed.
> 2. The interval may cause an eviction – in some cases this eviction is "bad" and guaranteed to causes a spill (it’s “bad” when you’re evicting the interval that evicted you, kind of like a cat and mouse game - somebody must loose here) - in this patch I’m trying to predict if it’s "bad" or not, and incorporate the spill weight of this interval.
> 3. The interval may spill – I’ve already encountered a case where the new local interval is in a hot loop and ends us spilling around all uses – this spill cost wasn’t considered when the candidate was chosen. I have a solution for this case which is based on parts of this patch.
> 4. The interval may split – I guess there might be some spill cost to consider here as well, but I didn’t explore this case yet.
> 
> I did see nice performance results with my current solution. 

I can totally see that. I wonder if adding 1K LOC is worth it and in particular if we can’t have the same result with fewer LOC.
My main concern is we try to predict yet another thing. Again the approach itself as you describe it makes sense, but the trade off complexity reward is not clear to me. In particular, what is the compile time impact, what are the regressions and so on.

> I will try to look into the hint reconciling as well, but I do think that the current spill weight calculation of the split candidates is not accurate enough and we need to consider the affects of those local intervals.
> 
> Thanks,
> Marina
> 
> 
> Repository:
>  rL LLVM
> 
> https://reviews.llvm.org/D35816
> 
> 
>