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

[Jakob Stoklund Olesen]

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.

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. 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