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

Wed Feb 5 11:36:17 PST 2014

On Feb 5, 2014 11:33 AM, "Hal Finkel" <hfinkel at anl.gov> wrote:
>
> ----- 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?
>

Unlikely. :)

Just giving an example.

-eric

>  -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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140205/9ca9f4b8/attachment.html>