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

[Hal Finkel]

Quentin,

I'm glad to see that this problem is being worked on; you're certainly right that we sometimes do more spilling then is necessary.

I would prefer, in general, that we make an effort not to introduce more magic cutoff constants. In this patch I see:

+    if (Q.collectInterferingVRegs(8) >= 8) {

and

+  if (Depth >= 5) {

and I think that, considering that this is not intended to be hot-path code, we make these cl::opt<unsigned>s instead. That makes it much easier to tune these as necessary.

Thanks again,
Hal

----- Original Message -----
> From: "Quentin Colombet" <qcolombet at apple.com>
> To: "Jakob Stoklund Olesen" <stoklund at 2pi.dk>
> Cc: "llvm-commits" <llvm-commits at cs.uiuc.edu>
> Sent: Tuesday, February 4, 2014 5:29:33 PM
> Subject: [PATCH][RegAlloc] Add a last chance recoloring mechanism when	everything else failed to find a register
> 
> 
> 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, l ast 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
> 
> 
> 
> 
> 
> 
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory