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

[Quentin Colombet]

Hi Hal, Jakob,

Thanks for the reviews.
Attached is the updated patch.

Hal, just to clarify, this patch does not tackle any spilling problem. This patch “just” introduces a reshuffling (or recoloring) of the registers involved in coloring decisions when we expelled all of the others options (spilling included). This means we may have already done more spilling than necessary, but at least we may be able to allocate the current instance instead of crashing the compiler.

The two problems are orthogonal. Although I am interested in better spilling heuristics, I do not plan to work on that shortly.

On Feb 5, 2014, at 9:17 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:

> 
> On Feb 4, 2014, at 3:29 PM, Quentin Colombet <qcolombet at apple.com> wrote:
> 
>> 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.
> 
> Hi Quentin,
> 
> The patch looks good to me, but please address Hal’s concerns.
> 
> I can see how this last-chance recoloring can be necessary, particularly when dealing with constrained register classes and inline assembly. However, I am not sure that the machine scheduler is doing the right thing if it is extending physical register live ranges. As I see it, physreg live ranges should always have a COPY in one end, and the copies should be placed to make the live ranges as short as possible.
I agree and I was surprised to see such extended live-ranges for physical registers.
Like you said and like I showed in my motivating example, the recoloring may still be needed for constrained register classes. Thus, I will pursue with that last chance approach.

I’ll look into the extended live-ranges problem as some point, because I believe this can improve the quality of the allocation in some cases (here for example :)).
> 
> Even when the scheduler is tracking register pressure, it is extremely difficult to guarantee that a valid register allocation exists if physical live ranges are extended.
Agree.

> We had this same problem back when the coalescer was extending physreg live ranges, and it was a constant source of obscure “ran out of registers” bugs like your test case.
> 
> Thanks,
> /jakob
> 
Thanks again,
-Quentin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: regalloc-last-chance.patch
Type: application/octet-stream
Size: 22882 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140205/37bc62fd/attachment.obj>