<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 7/14/20 4:34 PM, Hal Finkel via
      llvm-dev wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:80ab90a1-63db-1ef0-5af3-270ca4b66bd2@anl.gov">
      <br>
      On 7/14/20 11:28 AM, Fangqing Du wrote:
      <br>
      <blockquote type="cite">Thank you Hal and Stefan!
        <br>
        <br>
        Bug report is filed: <a class="moz-txt-link-freetext" href="https://bugs.llvm.org/show_bug.cgi?id=46717">https://bugs.llvm.org/show_bug.cgi?id=46717</a>
        <a class="moz-txt-link-rfc2396E" href="https://bugs.llvm.org/show_bug.cgi?id=46717"><https://bugs.llvm.org/show_bug.cgi?id=46717></a>
        <br>
        <br>
        And Stefan,
        <br>
        I think 'attributor' is a really nice pass, and can infer more
        precise and useful attributes, which may give more
        opportunities for optimization.
        <br>
        But we shouldn't depend on 'attributor' to correct wrong
        function attributes, because we cannot run 'attributor' after
        every pass, right?
        <br>
      </blockquote>
      <br>
      Correct. Each pass must be correct on its own. We need to fix
      ipsccp.
      <br>
      <br>
    </blockquote>
    <p>I don't think that was ever questioned ;) <br>
    </p>
    <p>I think the comment about the Attributor was more to show that
      this behavior</p>
    <p> is not the same there which is yet another good indicator this
      is a bug.</p>
    <p><br>
    </p>
    <p>~ Johannes</p>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:80ab90a1-63db-1ef0-5af3-270ca4b66bd2@anl.gov"> -Hal
      <br>
      <br>
      <br>
      <blockquote type="cite">
        <br>
        Thanks,
        <br>
        Fangqing
        <br>
        <br>
        On Sat, Jul 11, 2020 at 5:12 AM Hal Finkel <<a class="moz-txt-link-abbreviated" href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>
        <a class="moz-txt-link-rfc2396E" href="mailto:hfinkel@anl.gov"><mailto:hfinkel@anl.gov></a>> wrote:
        <br>
        <br>
            Hi, Fangqing,
        <br>
        <br>
            Yes, this seems like a bug. Can you please file a bug report
        at
        <br>
            <a class="moz-txt-link-freetext" href="https://bugs.llvm.org/">https://bugs.llvm.org/</a> <a class="moz-txt-link-rfc2396E" href="https://bugs.llvm.org/"><https://bugs.llvm.org/></a> ? If
        you need
        <br>
            someone else to do this on your behalf, please let us know.
        <br>
        <br>
             -Hal
        <br>
        <br>
            On 7/10/20 9:04 PM, Fangqing Du via llvm-dev wrote:
        <br>
        <blockquote type="cite">    Hi all,
          <br>
          <br>
              Let's see an example (from Alexandre Isoard) first:
          <br>
             
****************************************************************************************<br>
              ; RUN: opt -ipsccp -deadargelim -licm -O2 -S < %s
          <br>
          <br>
              @g = internal global i32 0
          <br>
          <br>
              ; Function Attrs: argmemonly
          <br>
              define internal void @foo(i32* nonnull dereferenceable(4)
          %arg,
          <br>
              i32 %val) #0 {
          <br>
              entry:
          <br>
                store i32 %val, i32* %arg
          <br>
                ret void
          <br>
              }
          <br>
          <br>
              define i32 @bar(i32 %n) {
          <br>
              entry:
          <br>
                store i32 1, i32* @g
          <br>
                br label %loop
          <br>
          <br>
              loop: ; preds = %bb1, %bb
          <br>
              %i = phi i32 [ %i.inc, %loop ], [ 0, %entry ]
          <br>
              %g.val = load i32, i32* @g
          <br>
              %g.inc = add nuw i32 %g.val, 1
          <br>
              tail call void @foo(i32* @g, i32 %g.inc)
          <br>
              %i.inc = add nuw i32 %i, 1
          <br>
              %cond = icmp eq i32 %i.inc, %n
          <br>
                br i1 %cond, label %exit, label %loop
          <br>
          <br>
              exit: ; preds = %bb1
          <br>
                ret i32 %g.val
          <br>
              }
          <br>
          <br>
              declare void @llvm.assume(i1)
          <br>
          <br>
              attributes #0 = { argmemonly }
          <br>
             
****************************************************************************************<br>
          <br>
              With opt cmd '-ipsccp -deadargelim -licm -O2',
          function @bar will
          <br>
              return constant value 1, instead of correct value %n. This
          is
          <br>
              crazy, right?
          <br>
              Let's see what happens here.
          <br>
              Due to pass 'ipsccp' replaced the argument of function
          '@foo'
          <br>
              with global variable '@g', but keeps attr 'argmemonly'
          there, so
          <br>
              pass 'licm' will hoist the load of '@g' before the loop
          (as the
          <br>
              value of @g isn't changed, but it is changed), and will
          cause
          <br>
              function return wrong constant value '1', instead of '%n'
          (the
          <br>
              correct value) , like following:
          <br>
             
****************************************************************************************<br>
          <br>
              ; Function Attrs: nofree norecurse nounwind writeonly
          <br>
              define i32 @bar(i32 %n) local_unnamed_addr #0 {
          <br>
              entry:
          <br>
              ret i32 1
          <br>
              }
          <br>
          <br>
              attributes #0 = { nofree norecurse nounwind writeonly }
          <br>
             
****************************************************************************************<br>
          <br>
          <br>
              And if remove the 'argmemonly' attribute, function @bar
          will
          <br>
              return the correct value:
          <br>
             
****************************************************************************************<br>
          <br>
              ; Function Attrs: nofree norecurse nounwind
          <br>
              define i32 @bar(i32 %n) local_unnamed_addr #0 {
          <br>
              entry:
          <br>
              ret i32 %n
          <br>
              }
          <br>
             
****************************************************************************************<br>
          <br>
          <br>
              So if function attribute 'argmemonly' on function @foo is
          <br>
              correct, then there's a bug in pass 'ipsccp'. When it
          replaces
          <br>
              the function local value with global variable, then it
          shoud
          <br>
              remember to remove this function attribute.
          <br>
          <br>
              Thanks,
          <br>
              Fangqing
          <br>
          <br>
              _______________________________________________
          <br>
              LLVM Developers mailing list
          <br>
              <a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a> 
          <a class="moz-txt-link-rfc2396E" href="mailto:llvm-dev@lists.llvm.org"><mailto:llvm-dev@lists.llvm.org></a>
          <br>
              <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> 
<a class="moz-txt-link-rfc2396E" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"><https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev></a>
          <br>
        </blockquote>
        <br>
            --     Hal Finkel
        <br>
            Lead, Compiler Technology and Programming Languages
        <br>
            Leadership Computing Facility
        <br>
            Argonne National Laboratory
        <br>
        <br>
        <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>
    </blockquote>
  </body>
</html>