<div dir="ltr">Note that there is the same issue in ipconstprop (on the same example) for the same reason. (thanks <a class="gmail_plusreply" id="plusReplyChip-0" href="mailto:yu810226@gmail.com" tabindex="-1">@Lin-Ya Yu</a>)</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 14, 2020 at 5:02 PM Johannes Doerfert via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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><br>
    </p>
    <div>On 7/14/20 4:34 PM, Hal Finkel via
      llvm-dev wrote:<br>
    </div>
    <blockquote type="cite">
      <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 href="https://bugs.llvm.org/show_bug.cgi?id=46717" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=46717</a>
        <a href="https://bugs.llvm.org/show_bug.cgi?id=46717" target="_blank"><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"> -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 href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>
        <a href="mailto:hfinkel@anl.gov" target="_blank"><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 href="https://bugs.llvm.org/" target="_blank">https://bugs.llvm.org/</a> <a href="https://bugs.llvm.org/" target="_blank"><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 href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> 
          <a href="mailto:llvm-dev@lists.llvm.org" target="_blank"><mailto:llvm-dev@lists.llvm.org></a>
          <br>
              <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a> 
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank"><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></fieldset>
        <pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
      </blockquote>
    </blockquote>
  </div>

_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><b>Alexandre Isoard</b><br></div></div>