<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 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;}
@font-face
{font-family:"Book Antiqua";
panose-1:2 4 6 2 5 3 5 3 3 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 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;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
mso-fareast-language:EN-IE;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Book Antiqua",serif;
color:#943634;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
.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-IE link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-family:"Book Antiqua",serif;color:#002060;mso-fareast-language:EN-US'>With the intrinsic support for ‘</span><span style='font-family:"Courier New";color:black;mso-fareast-language:EN-US'>memcpy</span><span style='font-family:"Book Antiqua",serif;color:#002060;mso-fareast-language:EN-US'>’ and ‘</span><span style='font-family:"Courier New";color:black;mso-fareast-language:EN-US'>memset</span><span style='font-family:"Book Antiqua",serif;color:#002060;mso-fareast-language:EN-US'>’ the operands also have associated alignment operands. I think that ‘</span><span style='font-family:"Courier New";color:black;mso-fareast-language:EN-US'>memcmp</span><span style='font-family:"Book Antiqua",serif;color:#002060;mso-fareast-language:EN-US'>’ should also provide the alignment information for each of the source operands (when statically known). In some cases this will lead to more optimal alignment aware lowering, and for targets for which unaligned access is costly or fatal, it can be lowered safely.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Book Antiqua",serif;color:#002060;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Book Antiqua",serif;color:#002060;mso-fareast-language:EN-US'> MartinO<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Book Antiqua",serif;color:#002060;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif'> llvm-dev [mailto:llvm-dev-bounces@lists.llvm.org] <b>On Behalf Of </b>David Jones via llvm-dev<br><b>Sent:</b> 30 December 2016 00:28<br><b>To:</b> Philip Reames <listmail@philipreames.com><br><b>Cc:</b> llvm-dev <llvm-dev@lists.llvm.org>; Zaara Syeda <syzaara@ca.ibm.com><br><b>Subject:</b> Re: [llvm-dev] RFC: Inline expansion of memcmp vs call to standard library<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Can I make another suggestion: create an intrinsic for memory equality, e.g. llvm.memcmp_eq.p0i8.p0i8.i64(i8*a, i8*b, i64 len). This intrinsic would return zero if the memory regions are equal, and nonzero otherwise. However, it does NOT return any notion of "greater" or "less".<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>Many applications require only determining equality, rather than a total ordering. Given that "greater" and "less" also require some knowledge of endianness, even a fancy lowered version of memcmp can be slower than an equality-only compare.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Thu, Dec 29, 2016 at 4:14 PM, Philip Reames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p><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>Improving lowering for memcmp is definitely something we should do for all targets. Doing it in a target specific way is decidedly non-ideal. <br><br>It looks like we already have some code in SelectionDAGBuilder which tries to optimize the lowering for the memcpy library call. I am a bit confused by the problem you are trying to solve. Are you specifically interested in lowering for constant lengths greater than a legal size? (i.e. do you need the loop?)<br><br>If so, there are two approaches you might consider:<br>- Expand the memcmp call into the loop form in CodeGenPrep (or a similar timed pass) where working with multiple basic blocks is much easier. Long term, the "right place" for this type of thing is clearly GlobalISEL, but we have a number of other such hacks in lowering today and continuing to build off of that seems reasonable.<br>- Emit the non-early exit form for small constant values (a[0] == b[0] && a[1] == b[1] ...). Assuming your backend has handling for efficiently lowering and chains using branches, you may very well get the code you want. <br><br>Using the psuedo instruction here feels messy. In particular, I don't like the fact it basically opts out of all of the combines which might further improve the lowering.<br><br>Philip<br><br><br>On 12/29/2016 11:35 AM, Zaara Syeda via llvm-dev wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p><span style='font-family:"Calibri",sans-serif'>Currently on PowerPC, calls to memcmp are not expanded and are left as library calls. In certain conditions, expansion can improve performance rather than calling the library function as done for functions like memcpy, memmove, etc. This patch <b>(</b></span><a href="https://reviews.llvm.org/D28163" target="_blank"><b><span style='font-family:"Calibri",sans-serif'>https://reviews.llvm.org/D28163</span></b></a><b><span style='font-family:"Calibri",sans-serif'>)</span></b><span style='font-family:"Calibri",sans-serif'> is an initial implementation for PowerPC to expand memcmp when the size is an 8 byte multiple.</span><o:p></o:p></p><p><span style='font-family:"Calibri",sans-serif'>The approach currently added for this expansion tries to use the existing infrastructure by overriding the virtual function EmitTargetCodeForMemcmp. This function works on the SelectionDAG, but the expansion requires control flow for early exit. So, instead of implementing the expansion within EmitTargetCodeForMemcmp, a new pseudo instruction is added for memcmp and a SelectionDAG node for this new pseudo is created in EmitTargetCodeForMemcmp. This pseudo instruction is then expanded during lowering in EmitInstrWithCustomInserter.<br><br>The advantage of this approach is that it uses the existing infrastructure and does not impact other targets. If other targets would like to expand memcmp, they can also override EmitTargetCodeForMemcmp and create their own expansion. </span><o:p></o:p></p><p><span style='font-family:"Calibri",sans-serif'>Another option to consider is adding a new optimization pass for this expansion that isn’t target specific if other targets would benefit from a more general infrastructure. </span><o:p></o:p></p><p><span style='font-family:"Calibri",sans-serif'>Please provide feedback if this approach should be continued to implement the PowerPC specific memcmp expansions or whether the community is interested in devising a more general approach</span>.<br><br>Thanks,<o:p></o:p></p><p style='margin-bottom:12.0pt'>Zaara Syeda<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><pre>_______________________________________________<o:p></o:p></pre><pre>LLVM Developers mailing list<o:p></o:p></pre><pre><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><o:p></o:p></pre><pre><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></pre></blockquote><p><o:p> </o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'><br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>