<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=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle18
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
span.EmailStyle19
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
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-US link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span style='color:#1F497D'>I have done some preliminary investigation into postponing some of the passes to see what the resulting performance impact would be. This is a fairly crude attempt at moving passes around to see if there is any potential benefit. I have attached the patch I used to do the tests, in case anyone is interested. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Briefly, the patch allows two different flows, with either a flag of –lto-new or –lto-new2. In the first case, the vectorization passes are postponed from the end of populateModulePassManager() function to midway through the addLTOOptimizationPasses(). In the second case, essentially the entire populateModulePassManager() function is deferred until link time.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>I ran spec2000/2006 on an ARM platform (Nexus 4), comparing 4 configurations (O3, O3 LTO, O3 LTO new, O3 LTO new 2). I have attached a PDF presenting the results from the test. The first 4 columns have the spec result (ratio) for the 4 different configurations. The second set of columns are the respective test / max(result of 4 configurations). I used this last one to see how well/poor a particular configuration was in comparison to other configurations. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>In general, there appears to be some benefit to be gained in a couple of the benchmarks (spec2000/art, spec2006/milc) by postponing vectorization. <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>I just wanted to present this information to the community to see if there is interest in pursuing the idea of postponing passes.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Daniel<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu] <b>On Behalf Of </b>Daniel Stewart<br><b>Sent:</b> Wednesday, September 17, 2014 9:46 AM<br><b>To:</b> llvmdev@cs.uiuc.edu<br><b>Subject:</b> [LLVMdev] Postponing more passes in LTO<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Looking at the existing flow of passes for LTO, it appears that most all passes are run on a per file basis, before the call to the gold linker. I’m looking to get people’s feedback on whether there would be an advantage to waiting to run a number of these passes until the linking stage. For example, I believe I saw a post a little while back about postponing vectorization until the linking stage. It seems to me that there could be an advantage to postponing (some) passes until the linking stage, where the entire graph is available. In general, what do people think about the idea of a different flow of LTO where more passes are postponed until the linking stage? <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Daniel Stewart<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>--<o:p></o:p></p><p class=MsoNormal>Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>