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

[Quentin Colombet]

Hi Hal,

On Feb 5, 2014, at 11:18 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
>> From: "Quentin Colombet" <qcolombet at apple.com>
>> To: "Jakob Stoklund Olesen" <stoklund at 2pi.dk>, "Hal Finkel" <hfinkel at anl.gov>
>> Cc: "Commit Messages and Patches for LLVM" <llvm-commits at cs.uiuc.edu>, "Andy Trick" <atrick at apple.com>
>> Sent: Wednesday, February 5, 2014 12:48:55 PM
>> Subject: Re: [PATCH][RegAlloc] Add a last chance recoloring mechanism when everything else failed to find a register
>> 
>> 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.
> 
> Okay, well I agree that not crashing is the higher-priority goal ;) -- but in this context, I don't understand what is going on. Unless we have a single instruction that uses and defines more registers than the entire set, how can we exhaust all other options including spilling? It seems like the limiting trivial case is where we spill and reload all relevant registers around every instruction, and that cannot fail.
Unfortunately, this is not that easy, let me go back to my running example with more details:
Assume the following register class constraints:
vA can use {R1, R2    }
vB can use {    R2, R3}
vC can use {R1        }

Input code:
vA = reload
vB = reload
vC = reload
inst vA, vB, vC (three uses, like for a store value, base + offset)

You cannot spill or split vA, vB, and vC, they are as short as possible.
A coloring exists for this instance, but the regular heuristic may not find it.
For instance, let us say the heuristic assigns the live-ranges top-down in the program order and uses the first available color:
vA => R1
vB => R2
vC => stuck
vA and vB were produced by spill, so you cannot do anything here.

If you would have use a graph coloring approach, you would have ended with the same problem. Because of the constrained of the register class, none of the nodes has a degree less than 3, thus you cannot derive a simplification order that is guarantee to complete.

The recoloring approach on the other hand, explore every possibility.

In this particular case, like I said, we end up in that situation because of a lot of factors.

> 
> With regard to the depth cuttoffs, then, if this is a correctness issue, then it seems like instead of skipping/aborting the hard cases, we should queue them to be revisited if no easier solution is found.
I prefer not to go in that direction because like I said, this is a backtracking algorithm. Thus if a solution exists we will find it but maybe not in a reasonable amount of time. Thus, we cut the branches that are likely to fail. Also, like Eric mentioned, there may not be a feasible solution with inline asm for instance.

Cheers,
-Quentin
> 
> Thanks again,
> Hal
> 
>> 
>> 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
>> 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140205/4715c80f/attachment.html>