<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:SimSun;
        panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
        {font-family:SimSun;
        panose-1:2 1 6 0 3 1 1 1 1 1;}
@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;}
@font-face
        {font-family:"\@SimSun";
        panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        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:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;}
@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=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi James & Chandler,<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'>I have two small test cases to show James’ first concern. Test results show loop vectorizor generates quite poor code for wide store. To see the result by following command lines:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>opt –S –loop-vectorize < wide-store.ll<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>opt –S –loop-vectorize < narrow-stores.ll<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'>The wide-store.ll and narrow-stores.ll are generated from attached struct.cpp by with or without the my patch. This cpp case is simplified from a hot function in SPEC CPU 2006 473.astar. Currently the poor code affects the performance.<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><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi Chandler,<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'>I also agree with your concern. On the other hand, If the input is zext/shl/or and a wide store, the patch in SROA can not handle such case. For example, if the input is wide-store.ll, only a separate pass or function specific to handle such case can generate simpler code.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>But there is a conflict, even though we add code in the backend, we still can’t solve the problem about the wide-store affecting the Loop Vectorization issue. For this concern, I think maybe we prefer narrow stores than wide store.<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'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-Hao<o:p></o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> mankeyrabbit@gmail.com [mailto:mankeyrabbit@gmail.com] <b>On Behalf Of </b>James Molloy<br><b>Sent:</b> Friday, August 29, 2014 5:40 PM<br><b>To:</b> Chandler Carruth<br><b>Cc:</b> Hao Liu; Commit Messages and Patches for LLVM; reviews+D4954+public+39a520765005fb8e@reviews.llvm.org<br><b>Subject:</b> Re: [PATCH] [PATCH][SROA]Also slice the STORE when slicing a LOAD in AllocaSliceRewriter<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Hi Chandler,</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Nebbing in with my two-pennyworth;</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Also, with the IR produced by SROA, the information needed is still present. I think the problem is that both backends need to be taught the trick of using multiple stores at indexed offsets to save math combining two values. That's my suggestion for how to improve the quality of code for these patterns.</span><o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I think while it's easy to ask the backend to do this, SROA runs fairly early and there are many things in between it and the backend.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>My first concern is that the additional IR instructions diverge greatly from the expected generated code, which breaks the SLP and loop vectorizers' heuristics.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Secondly, there is no guarantee that the inserted zexts/sexts/or's will still be in a coherent group for the backend to identify. If other midend passes manage to remove or combine one or more of them, the idiom may no longer be matched. Or worse, if part of them are lifted or sunk into a different basic block our instruction selection will never see them!<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>So I'm not sure your proposed solution is the best available.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Cheers,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>James<o:p></o:p></p></div></div><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoNormal>On 29 August 2014 10:23, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Wed, Aug 27, 2014 at 8:46 PM, Hao Liu <<a href="mailto:Hao.Liu@arm.com" target="_blank">Hao.Liu@arm.com</a>> wrote:<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I think you concern about when the narrow LOADs are folded back, we can’t fuse the narrow STOREs back. Am I get your point?</span><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal>No, my concern is about when we completely remove the loads through GVN or even the mem2reg process that runs in SROA itself. The sliced loads are expected to go away and become SSA registers. We might well be able to then fold away the zext / shl / or / etc into the math that feeds those SSA values. But we will in most cases fail to fuse the stores back together once they are split.<o:p></o:p></p></div><div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>But I think the narrow LOADs won’t be folded back, as the SROA checks such LOAD can be split and removed. So if the narrow LOADs won’t exist, there are two choices for us:</span><o:p></o:p></p><p><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>(1)</span><span style='font-size:7.0pt;color:#1F497D'>    </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The additional ZEXT/SHL/OR and wide STORE.</span><o:p></o:p></p><p><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>(2)</span><span style='font-size:7.0pt;color:#1F497D'>    </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Two narrow STOREs.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I still prefer the (2) than the (1). I think a better optimization for (1) is to split the STORE. Even if there are other optimizations to change the wide STORE, we’ll still have ZEXT/SHL/OR left. Such code with bit math seems not the best choice.</span><o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal>I'm not really sure what you mean about having instructions left over.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The fundamental thing is this: the width of memory stored to is actually a very important property of the source program. It clarifies the maximum width of memory that is correct to store two in a single instruction. Splitting or narrowing a store is often irreversible because fusing or widening can introduce data races.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>As a consequence, it is a conscious choice throughout the optimizer to preserve the maximal width of stores (and to a lesser extend loads). This preserves the information in the middle-end about what freedoms the source program has w.r.t. to memory accesses and data races.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Also, with the IR produced by SROA, the information needed is still present. I think the problem is that both backends need to be taught the trick of using multiple stores at indexed offsets to save math combining two values. That's my suggestion for how to improve the quality of code for these patterns.<o:p></o:p></p></div></div></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><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" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></body></html>