<div dir="ltr"><div>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".<br><br></div>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.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 29, 2016 at 4:14 PM, Philip Reames via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div class="m_-74545741213208380moz-cite-prefix">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:<br>
    </div>
    <blockquote type="cite">
      <p><font face="Calibri">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 </font><b><font face="Calibri">(</font></b><a href="https://reviews.llvm.org/D28163" target="_blank"><b><font face="Calibri">https://reviews.llvm.org/<wbr>D28163</font></b></a><b><font face="Calibri">)</font></b><font face="Calibri"> is an
          initial implementation for PowerPC to expand memcmp when the
          size is an 8 byte multiple.</font></p>
      <p><font face="Calibri">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. </font></p>
      <p><font face="Calibri">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. </font></p>
      <p><font face="Calibri">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</font><font face="Times New Roman">.<br>
          <br>
          Thanks,</font></p>
      <p><font face="Times New Roman">Zaara Syeda</font><br>
        <br>
      </p>
      <fieldset class="m_-74545741213208380mimeAttachmentHeader"></fieldset>
      <br>
      <pre>______________________________<wbr>_________________
LLVM Developers mailing list
<a class="m_-74545741213208380moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_-74545741213208380moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote>
    <p><br>
    </p>
  </div>

<br>______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>