<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body>
    <p>Glancing at the in-tree usage, it looks like we have decent
      support for optimizing and lowering existing calls to bcmp/memcpy,
      but very little in the way of pattern matching formation.  Are you
      planning on extending the matching pieces?  Or is the primary
      intent to be able to share lowering code for the atomic
      invariants?</p>
    <p>One thing I note is that glancing at existing code, it looks like
      not all targets support bcmp or memcmp.  Given that, any intrinsic
      formation is going to have to remain dependent on the appropriate
      TLI checks.  That's slightly odd, but not a show stopper.  <br>
    </p>
    <p>I would find this proposal more compelling if you could show
      benefit to the existing lowering/transformations by introducing
      the non-standard signatures.  I don't see any obvious ways to do
      so, but maybe give that some thought?</p>
    <p>The major alternative to this proposal would be to simply add two
      new libfuncs for the atomic variants of bcmp/memcpy, and then
      configure them to be not-present on most targets.  This would
      allow you to reuse the lowering code - which I do think is
      entirely reasonable for upstream - without the need for the
      intrinsics.</p>
    <p>Overall, I think this proposal is reasonable.  I'm not strongly
      in support given the ease of the libfunc approach, but I don't
      really see any serious downsides to it either.</p>
    <p>Philip<br>
    </p>
    <div class="moz-cite-prefix">On 11/22/21 8:22 AM, Dmitry Makogon via
      llvm-dev wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:BL0PR11MB31378DF6EA5F1A01CF5C34CEBD9F9@BL0PR11MB3137.namprd11.prod.outlook.com">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style>@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;}p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}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]-->
      <div class="WordSection1">
        <p class="MsoNormal">Hello everyone.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">I would like to introduce new intrinsics
          for memory comparison:<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">memcmp - an equivalent of libc' memcmp,<o:p></o:p></p>
        <p class="MsoNormal">bcmp - an equivalent of libc' bcmp,<o:p></o:p></p>
        <p class="MsoNormal">memcmp.element.unordered.atomic - an
          element atomic version of memcmp,<o:p></o:p></p>
        <p class="MsoNormal">bcmp.element.unordered.atomic - an element
          atomic version of bcmp.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Currently there exist some optimizations
          for memcmp/bcmp libc calls.<o:p></o:p></p>
        <p class="MsoNormal">We would like to have these optimizations
          for element atomic comparisons (atomicity permitted).<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">I suggest we rewrite the existing
          optimizations to work with on new intrinsics and transform<o:p></o:p></p>
        <p class="MsoNormal">memcmp/bcmp libc calls to the corresponding
          intrinsics. This is similar to what we do with<o:p></o:p></p>
        <p class="MsoNormal">memcpy library calls.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Having these optimizations work on
          intrinsics and not on recognized libc calls<o:p></o:p></p>
        <p class="MsoNormal">will allow us to share some existing
          transforms between atomic and non-atomic variants.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">I propose the following plan for
          introducing the new intrinsics:<o:p></o:p></p>
        <p class="MsoNormal">1. Introduce non-atomic memcmp and bcmp
          intrinsics.<o:p></o:p></p>
        <p class="MsoNormal">2. Reimplement existing transforms for
          non-atomic memcmp intrinsic,<o:p></o:p></p>
        <p class="MsoNormal">the same way as it's done for memcpy.<o:p></o:p></p>
        <p class="MsoNormal">3. Introduce atomic intrinsics and reuse
          the optimizations.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Please express your concerns about this.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Dmitry<o:p></o:p></p>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote>
  </body>
</html>