<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Agreed.  This seems like overall a huge win for readability. <br>
    </p>
    <p>I am a bit worried about all the miscompiles you're going to
      expose by using all that extra information, but we should
      definitely just fix those.  :)</p>
    <p>Philip<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 04/26/2017 08:53 AM, Hal Finkel via
      llvm-dev wrote:<br>
    </div>
    <blockquote cite="mid:ab9398c3-7487-309a-4a02-4c41981cf9cc@anl.gov"
      type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      <p><br>
      </p>
      <div class="moz-cite-prefix">On 04/25/2017 11:32 PM, Daniel Berlin
        via llvm-dev wrote:<br>
      </div>
      <blockquote
cite="mid:CAF4BwTVWWNnUTH66QdEDFFD1m=UPhWmQeEFYTKKBpKAfXprohQ@mail.gmail.com"
        type="cite">
        <meta http-equiv="Content-Type" content="text/html;
          charset=utf-8">
        <div dir="ltr">For those not following along, startingin
          r301379, Simplify* in InstructionSimplify now can just take a
          query struct  instead of 8000 optional arguments.  Nothing is
          really new since it used the same thing under the covers.
          <div>
            <div><br>
            </div>
            <div>I'm slowly converting the old uses away (deletion of
              the old APIs is a different question).</div>
            <div>Staring at most of them, i could just directly convert
              them using braced list initialization, and construct the
              objects again and again, but the vast majority of uses
              actually:</div>
            <div><br>
            </div>
            <div>A. don't change the relevant query arguments over the
              lifetime of the pass</div>
            <div>B. actually have more information sitting around than
              they are passing along.</div>
            <div><br>
            </div>
            <div>For example, instcombine has a DomTree and
              AssumptionCache that are required, but it doesn't pass
              them to SimplifyBinOp in a bunch of cases.</div>
            <div><br>
            </div>
            <div>JumpThreading has TLI but doesn't pass it to
              SimplifyCmpInst.</div>
            <div><br>
            </div>
            <div>CVP at least admits it has a problem:</div>
            <div>"CorrelatedValuePropagation.cpp:  // FIXME: Provide
              TLI, DT, AT to SimplifyInstruction.</div>
            <div>CorrelatedValuePropagation.cpp:  if (Value *V =
              SimplifyInstruction(P, DL)) {</div>
            <div>"</div>
            <div>(This is because it uses LVI, which requires those
              things, but it doesn't ask for them itself)</div>
            <div><br>
            </div>
            <div>Assuming this is not deliberate, it would seem to me to
              just be easiest to set up the query structure once in the
              pass and use it everywhere, which would hopefully avoid
              these issues in the future, besides making most of the
              call strings dramatically shorter :)</div>
            <div><br>
            </div>
            <div>Is there any real downside (compile time performance,
              etc) to this vs what we do now (which is basically
              constructing the query objects again and again under the
              covers) that anyone can think of?</div>
            <div><br>
            </div>
            <div>(again, assuming we are not deliberately avoiding
              passing info to Simplify* in most of these cases)</div>
          </div>
        </div>
      </blockquote>
      <br>
      I don't think it is deliberate; it is just that no one has done
      the work to make it uniform. It is possible that doing this will
      expose some compile-time issues, but if so, we should deal with
      them for real (not just hide them by a failure to provide
      optional-but-available analyses).<br>
      <br>
      I'm certainly in favor of more uniformity here.<br>
      <br>
       -Hal<br>
      <br>
      <blockquote
cite="mid:CAF4BwTVWWNnUTH66QdEDFFD1m=UPhWmQeEFYTKKBpKAfXprohQ@mail.gmail.com"
        type="cite">
        <div dir="ltr">
          <div>
            <div><br>
            </div>
          </div>
          <div>I figured i'd ask before i went writing the scripts/etc
            to help convert a bunch of this stuff :)</div>
          <div><br>
          </div>
        </div>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
LLVM Developers mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
      </blockquote>
      <br>
      <pre class="moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>