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

[Hal Finkel]

----- Original Message -----
> From: "Eric Christopher" <echristo at gmail.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Quentin Colombet" <qcolombet at apple.com>, "Commit Messages and Patches for LLVM" <llvm-commits at cs.uiuc.edu>
> Sent: Wednesday, February 5, 2014 1:22:00 PM
> Subject: Re: [PATCH][RegAlloc] Add a last chance recoloring mechanism when everything else failed to find a register
> 
> 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.

Fair enough, but will this recoloring help that?

 -Hal

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

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory