<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/7/22 1:55 PM, James Y Knight
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAA2zVHp0sM65aBwU13G8etfaLn=+LUHXiVxfQuBM46DQ182rAA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr"><br>
        </div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Fri, Jan 7, 2022 at 4:48
            PM Philip Reames via llvm-dev <<a
              href="mailto:llvm-dev@lists.llvm.org"
              moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            <div>
              <p>I think I've already killed several of the ones you
                note.  I agree there's definite room to improve the
                handling of strdup/strndup.  If you wanted to write a
                patch for that specifically, I'd be happy to review.</p>
            </div>
          </blockquote>
          <div>IMO, it doesn't seem worthwhile to make strdup handling
            expressible with generic attributes. We special case many
            other libc functions too, so this is not unusual, and unlike
            other allocator properties, "strdup-like" does not seem
            likely to be a very interesting thing to apply to other
            functions.</div>
          <div><br>
          </div>
        </div>
      </div>
    </blockquote>
    <p>Er, I was apparently unclear.</p>
    <p>The sole remaining property of a strndup that we can't get from
      generic attributes (which already exist) is the clamp on result
      size.  We can entirely remove strdup special casing (by having
      either the frontend or BuildLibCalls annotate it with appropriate
      attributes.)  We can *almost* do the same for strndup minus the
      size special casing.</p>
    <p>So, we can remove a bunch of existing special case code.  We
      would not be adding any new attribute motivated by strdup.  I
      agree it appears to be an uncommon pattern. <br>
    </p>
    <p>One potential interaction I've not looked at is the nobuiltin
      bit, but presumably we must have already solved that as we're
      adding attributes to lots of other libfuncs.  <br>
    </p>
    <p>Do drive this through, we do need to switch a bunch of transforms
      from isAllocLike to noalias return driven as well.  (I'm assuming
      we want to do that for all kinds of reasons.)<br>
    </p>
    <p>Philip<br>
    </p>
  </body>
</html>