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

[Eric Christopher]

On Wed, 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.

FWIW Inline Asm is handled as a block and so an inline asm that uses
all registers will cause the problem. Even one that compiles with gcc
because of address folding that we don't necessarily do inside the
inline asm.

-eric

>
> 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.
>
> 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
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits