<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";
        mso-fareast-language:EN-GB;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";
        mso-fareast-language:EN-US;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> David Blaikie [mailto:dblaikie@gmail.com] <br><b>Sent:</b> 06 September 2014 21:40<br><b>To:</b> Arnaud De Grandmaison<br><b>Cc:</b> Tim Northover; llvm-commits@cs.uiuc.edu; Lang Hames<br><b>Subject:</b> Re: [PATCH] Add experimental PBQP support<o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><o:p> </o:p></p><div><p class=MsoNormal style='margin-left:36.0pt'><o:p> </o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:36.0pt'><o:p> </o:p></p><div><p class=MsoNormal style='margin-left:36.0pt'>On Sat, Sep 6, 2014 at 8:30 AM, Arnaud A. de Grandmaison <<a href="mailto:arnaud.degrandmaison@arm.com" target="_blank">arnaud.degrandmaison@arm.com</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Writing tests for a register allocator is not an easy task, as the set of all valid allocation is quite large, and can be equally good. What I have seen with the other allocators is that most testcases correspond to specific issues found in the allocator. My plan was to have an initial commit (this patch, with no real test), and then add testcases with subsequent commits as they improve specific areas of the allocation.</span><o:p></o:p></p></div></div><div><p class=MsoNormal style='margin-left:36.0pt'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'>so this change itself doesn't add any improvements, just lays the foundation for improvements to come?<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Correct. I see this patch as a foundation for improvements to come.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>This patch only uses the existing infrastructure as is,  and was necessary to run a wide range of benchmarks and diagnose where improvements should be made. I already have a few on my list, the first one being improving how the different costs are set and relate together (allocation cost, interference cost & spill weight) --- and this will require some modification in the generic infrastructure and a backend with extra constraints to see the effects.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt'><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> David Blaikie [mailto:<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>] <br><b>Sent:</b> 06 September 2014 17:17<br><b>To:</b> Arnaud De Grandmaison<br><b>Cc:</b> Tim Northover; <a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a>; Lang Hames<br><b>Subject:</b> RE: [PATCH] Add experimental PBQP support</span><o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:36.0pt'> <o:p></o:p></p><p style='margin-left:36.0pt'><br>On Sep 6, 2014 8:08 AM, "Arnaud A. de Grandmaison" <<a href="mailto:arnaud.degrandmaison@arm.com" target="_blank">arnaud.degrandmaison@arm.com</a>> wrote:<br>><br>> Hi Dave & Lang,<br>><br>>  <br>><br>> The AArch64 does not require extra constraints for the PBQP to work, but the AArch64/A57 benefits from setting additional constraints. On the A57, some sequence of operations will execute faster if some of their operands stays in even or odd registers. The Arch64FPLoadBalancing pass has been added to do some optimization there by permuting registers in the straight forward cases, whereas this can be solved generally and elegantly with the PBQP at register allocation time.<o:p></o:p></p><p style='margin-left:36.0pt'>Awesome - thanks for the explanation.<o:p></o:p></p><p style='margin-left:36.0pt'>Are the improvements separable into patches per specific improvement (with corresponding tests for each)?<o:p></o:p></p><p style='margin-left:36.0pt'>><br>>  <br>><br>> Cheers,<br>><br>> Arnaud<br>><br>>  <br>><br>> From: Lang Hames [mailto:<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>] <br>> Sent: 06 September 2014 06:14<br>> To: David Blaikie<br>> Cc: Arnaud De Grandmaison; <a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a>; Tim Northover<br>> Subject: Re: [PATCH] Add experimental PBQP support<br>><br>>  <br>><br>> Hi Dave,<br>><br>>  <br>><br>> Out-of-the-box PBQP knows about the standard constraints that CodeGen models. Any Target that works with the standard allocators (E.g. greedy) should also work with PBQP. I believe Arnaud's patch is an optimisation. (Arnaud - please correct me if I'm wrong and AArch64 did require extra constraints, but I don't think it should?)<br>><br>>  <br>><br>> - Lang.<br>><br>>  <br>><br>> On Fri, Sep 5, 2014 at 3:45 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>><br>> This'll probably show how little I know about register allocation - but I thought Lang was telling me the other day that PBQP is essentially a drop/opt in for any architecture without having specific code for it (learning about the register set from the tablegen files and that was all it needed).<br>><br>> Is that the case? Is the extra code in your patch then tuning, essentially - making PBQP better than the baseline table-driven PBQP for AArch64/A57? Or is my understanding incorrect?<br>><br>> - David<br>><br>>  <br>><br>> On Fri, Sep 5, 2014 at 1:49 PM, Arnaud A. de Grandmaison <<a href="mailto:arnaud.degrandmaison@arm.com" target="_blank">arnaud.degrandmaison@arm.com</a>> wrote:<br>>><br>>> I am currently investigating the benefits the PBQP register allocator could bring to the AArch64/A57.<br>>><br>>>  <br>>><br>>> This patch adds experimental support for PBQP. The PBQP is disabled by default, and can be enabled with the ‘–aarch64-pbqp’ command line option to llc when the cortex-a57 is in use.<br>>><br>>>  <br>>><br>>> I thought it would be a good thing to upstream this patch, as some other people in the community could be interested in experimenting with this allocator.<br>>><br>>>  <br>>><br>>> It passes all the tests (LNT, spec, …), but the performance of the generated code is not optimal yet. Expect some more patches in the coming days to improve the performance.<br>>><br>>>  <br>>><br>>> Cheers,<br>>><br>>> --<br>>><br>>> Arnaud A. de Grandmaison<br>>><br>>>  <br>>><br>>>  <br>>><br>>> _______________________________________________<br>>> llvm-commits mailing list<br>>> <a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>><br>>  <br>><br>>  <o:p></o:p></p></div></div></div></div></blockquote></div><p class=MsoNormal style='margin-left:36.0pt'><o:p> </o:p></p></div></div></div></body></html>