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

Andrew Trick atrick at apple.com
Wed Feb 5 10:50:51 PST 2014


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.

That sounds like a scheduling bug to me too.
-Andy

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





More information about the llvm-commits mailing list