[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