<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div apple-content-edited="true"><br></div><div><div>On Feb 5, 2014, at 11:36 AM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><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><div><br></div></blockquote>I second that, unfortunately.</div><div><br></div><div>Like I said in my initial mail, there are plenty of tweaks we can do to avoid the current “ran of registers”. At some point, however, this will not be enough and the heuristic will still fail, like in the running example.</div><div>I prefer to have a back-up before playing with the tweaking ;).</div><div><br></div><div>-Quentin</div><div><blockquote type="cite"><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>
</blockquote></div><br></body></html>