[PATCH][RegAlloc] Add a last chance recoloring mechanism when everything else failed to find a register

[Quentin Colombet]

Hi Jakob,

The attached patch introduces a last chance recoloring mechanism when the current allocation scheme fails to assign a register.
Thanks for your review.

** Context **

In some extreme conditions the current allocation heuristic may fail to find a valid allocation solution whereas one exists.
This is demonstrated with the (big) test case that is contained in that patch.
Basically, in that test case, the greedy register allocator runs out of registers because of a combination of:
- The way the machine scheduler extends some physical register live-ranges, which end up putting a lot of contraints on the available registers.
- The relocation model, which consumes one register.
- The function attributes, which forces to keep a register for the frame pointer.
- The weight of the different variables, which affect the allocation order.

To simplify, here is what is going on during register allocation:
vA can use {R1, R2    }
vB can use {    R2, R3}
 vC can use {R1        }
Where vA, vB, and vC cannot be split anymore (they are reloads for instance) and they all interfere.

vA is assigned R1
vB is assigned R2
vC tries to evict vA but vA is already done.
=> register allocation fails.


** Proposed Solution **

For the problem at stake, tweaking the machine scheduler to be less aggressive on extending the live-ranges of physical registers would do the trick. Likewise tweaking the allocation cost model to change the allocation order would have worked.
Anyhow, these approaches would just hide a problem that eventually will happen.
Instead, the proposed patch introduced a (last chance) recoloring mechanism.

Basically the idea is to choose a color for the variable that cannot be allocated and recolor its interferences around. Unlike the current register allocation scheme, it is allowed to change the color of an already assigned (but maybe not splittable or spillable) live interval while propagating this change to its neighbors.
In other word, there are two things that may help finding an available color:
- Already assigned variables (RS_Done) can be recolored to different color.
- The recoloring allows to catch solutions that needs to touch more that just the neighbors of the current allocated variable.

On the previous example, here is how it works:
After the regular allocation scheme fails, last chance recoloring kicks in:
vC does as if vA was evicted => vC uses R1.
vC is marked as fixed.
vA needs to find a color.
None are available.
vA cannot evict vC: vC is a fixed virtual register now.
vA does as if vB was evicted => vA uses R2.
vB needs to find a color.
R3 is available.
Recoloring => vC = R1, vA = R2, vB = R3

The recoloring mechanism is a backtracking algorithm. It is supposed to kick in rarely so I did not spend a lot of effort to cut branches earlier or limit in a more comprehensive way the search space.

<rdar://problem/15947839>

Cheers,
-Quentin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140204/e6db64d6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: regalloc-last-chance.patch
Type: application/octet-stream
Size: 21924 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140204/e6db64d6/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140204/e6db64d6/attachment-0001.html>