<p dir="ltr"><br>
On Feb 5, 2014 11:33 AM, "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br>
><br>
> ----- Original Message -----<br>
> > From: "Eric Christopher" <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>><br>
> > To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
> > Cc: "Quentin Colombet" <<a href="mailto:qcolombet@apple.com">qcolombet@apple.com</a>>, "Commit Messages and Patches for LLVM" <<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>><br>

> > Sent: Wednesday, February 5, 2014 1:22:00 PM<br>
> > Subject: Re: [PATCH][RegAlloc] Add a last chance recoloring mechanism when everything else failed to find a register<br>
> ><br>
> > On Wed, Feb 5, 2014 at 11:18 AM, Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br>
> > > ----- Original Message -----<br>
> > >> From: "Quentin Colombet" <<a href="mailto:qcolombet@apple.com">qcolombet@apple.com</a>><br>
> > >> To: "Jakob Stoklund Olesen" <<a href="mailto:stoklund@2pi.dk">stoklund@2pi.dk</a>>, "Hal Finkel"<br>
> > >> <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
> > >> Cc: "Commit Messages and Patches for LLVM"<br>
> > >> <<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>>, "Andy Trick" <<a href="mailto:atrick@apple.com">atrick@apple.com</a>><br>
> > >> Sent: Wednesday, February 5, 2014 12:48:55 PM<br>
> > >> Subject: Re: [PATCH][RegAlloc] Add a last chance recoloring<br>
> > >> mechanism when everything else failed to find a register<br>
> > >><br>
> > >> Hi Hal, Jakob,<br>
> > >><br>
> > >> Thanks for the reviews.<br>
> > >> Attached is the updated patch.<br>
> > >><br>
> > >> Hal, just to clarify, this patch does not tackle any spilling<br>
> > >> problem. This patch "just" introduces a reshuffling (or<br>
> > >> recoloring)<br>
> > >> of the registers involved in coloring decisions when we expelled<br>
> > >> all<br>
> > >> of the others options (spilling included). This means we may have<br>
> > >> already done more spilling than necessary, but at least we may be<br>
> > >> able to allocate the current instance instead of crashing the<br>
> > >> compiler.<br>
> > >><br>
> > >> The two problems are orthogonal. Although I am interested in<br>
> > >> better<br>
> > >> spilling heuristics, I do not plan to work on that shortly.<br>
> > ><br>
> > > Okay, well I agree that not crashing is the higher-priority goal ;)<br>
> > > -- but in this context, I don't understand what is going on.<br>
> > > Unless we have a single instruction that uses and defines more<br>
> > > registers than the entire set, how can we exhaust all other<br>
> > > options including spilling? It seems like the limiting trivial<br>
> > > case is where we spill and reload all relevant registers around<br>
> > > every instruction, and that cannot fail.<br>
> ><br>
> > FWIW Inline Asm is handled as a block and so an inline asm that uses<br>
> > all registers will cause the problem. Even one that compiles with gcc<br>
> > because of address folding that we don't necessarily do inside the<br>
> > inline asm.<br>
><br>
> Fair enough, but will this recoloring help that?<br>
></p>
<p dir="ltr">Unlikely. :)</p>
<p dir="ltr">Just giving an example. </p>
<p dir="ltr">-eric</p>
<p dir="ltr">>  -Hal<br>
><br>
> ><br>
> > -eric<br>
> ><br>
> > ><br>
> > > With regard to the depth cuttoffs, then, if this is a correctness<br>
> > > issue, then it seems like instead of skipping/aborting the hard<br>
> > > cases, we should queue them to be revisited if no easier solution<br>
> > > is found.<br>
> > ><br>
> > > Thanks again,<br>
> > > Hal<br>
> > ><br>
> > >><br>
> > >> On Feb 5, 2014, at 9:17 AM, Jakob Stoklund Olesen<br>
> > >> <<a href="mailto:stoklund@2pi.dk">stoklund@2pi.dk</a>><br>
> > >> wrote:<br>
> > >><br>
> > >> ><br>
> > >> > On Feb 4, 2014, at 3:29 PM, Quentin Colombet<br>
> > >> > <<a href="mailto:qcolombet@apple.com">qcolombet@apple.com</a>><br>
> > >> > wrote:<br>
> > >> ><br>
> > >> >> Hi Jakob,<br>
> > >> >><br>
> > >> >> The attached patch introduces a last chance recoloring<br>
> > >> >> mechanism<br>
> > >> >> when the current allocation scheme fails to assign a register.<br>
> > >> >> Thanks for your review.<br>
> > >> >><br>
> > >> >> ** Context **<br>
> > >> >><br>
> > >> >> In some extreme conditions the current allocation heuristic may<br>
> > >> >> fail to find a valid allocation solution whereas one exists.<br>
> > >> >> This is demonstrated with the (big) test case that is contained<br>
> > >> >> in<br>
> > >> >> that patch.<br>
> > >> >> Basically, in that test case, the greedy register allocator<br>
> > >> >> runs<br>
> > >> >> out of registers because of a combination of:<br>
> > >> >> - The way the machine scheduler extends some physical register<br>
> > >> >> live-ranges, which end up putting a lot of contraints on the<br>
> > >> >> available registers.<br>
> > >> >> - The relocation model, which consumes one register.<br>
> > >> >> - The function attributes, which forces to keep a register for<br>
> > >> >> the<br>
> > >> >> frame pointer.<br>
> > >> >> - The weight of the different variables, which affect the<br>
> > >> >> allocation order.<br>
> > >> ><br>
> > >> > Hi Quentin,<br>
> > >> ><br>
> > >> > The patch looks good to me, but please address Hal's concerns.<br>
> > >> ><br>
> > >> > I can see how this last-chance recoloring can be necessary,<br>
> > >> > particularly when dealing with constrained register classes and<br>
> > >> > inline assembly. However, I am not sure that the machine<br>
> > >> > scheduler<br>
> > >> > is doing the right thing if it is extending physical register<br>
> > >> > live<br>
> > >> > ranges. As I see it, physreg live ranges should always have a<br>
> > >> > COPY<br>
> > >> > in one end, and the copies should be placed to make the live<br>
> > >> > ranges as short as possible.<br>
> > >> I agree and I was surprised to see such extended live-ranges for<br>
> > >> physical registers.<br>
> > >> Like you said and like I showed in my motivating example, the<br>
> > >> recoloring may still be needed for constrained register classes.<br>
> > >> Thus, I will pursue with that last chance approach.<br>
> > >><br>
> > >> I'll look into the extended live-ranges problem as some point,<br>
> > >> because I believe this can improve the quality of the allocation<br>
> > >> in<br>
> > >> some cases (here for example :)).<br>
> > >> ><br>
> > >> > Even when the scheduler is tracking register pressure, it is<br>
> > >> > extremely difficult to guarantee that a valid register<br>
> > >> > allocation<br>
> > >> > exists if physical live ranges are extended.<br>
> > >> Agree.<br>
> > >><br>
> > >> > We had this same problem back when the coalescer was extending<br>
> > >> > physreg live ranges, and it was a constant source of obscure<br>
> > >> > "ran<br>
> > >> > out of registers" bugs like your test case.<br>
> > >> ><br>
> > >> > Thanks,<br>
> > >> > /jakob<br>
> > >> ><br>
> > >> Thanks again,<br>
> > >> -Quentin<br>
> > >><br>
> > ><br>
> > > --<br>
> > > Hal Finkel<br>
> > > Assistant Computational Scientist<br>
> > > Leadership Computing Facility<br>
> > > Argonne National Laboratory<br>
> > ><br>
> > > _______________________________________________<br>
> > > llvm-commits mailing list<br>
> > > <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> > > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
> ><br>
><br>
> --<br>
> Hal Finkel<br>
> Assistant Computational Scientist<br>
> Leadership Computing Facility<br>
> Argonne National Laboratory<br>
</p>