<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Thanks for sharing this background information :). If you've got the time, I think it'd be great to check this bulleted list into docs/. I see that we don't have a Canonicalizations.rst or a LoopOptimizations.rst -- your notes look like a good starting point.<div class=""><br class=""></div><div class="">Given that the pass seems to be doing the right thing from a design perspective, should it stay in tree? Since it's been off-by-default since it was introduced in 2011, I'm still in favor of removing it unless someone is actively working on it.</div><div class=""><br class=""></div><div class="">[+ Chad, one of the pass contributors, for comment.]</div><div class=""><br class=""></div><div class="">thanks,</div><div class="">vedant<br class=""><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 5, 2018, at 8:47 AM, Philip Reames <<a href="mailto:listmail@philipreames.com" class="">listmail@philipreames.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252" class="">
  
  <div text="#000000" bgcolor="#FFFFFF" class=""><p class="">We're not actively using this, but from a design perspective I'm
      wondering if we should be using this or something like it.  At the
      moment, our various loop optimization assume mostly canonical
      input.  Some of the passes have been taught to deal with limited
      amounts of non-canonical-ism, but there's a strong code simplicity
      argument in favor of only handling canonical input and then having
      something else canonicalize if necessary.  Given our loop passes
      are iterated to a fixed point, having that canonicalization done
      in another loop pass seems appropriate.  This pass seems like a
      start down that path.</p><p class="">Since we don't really document this anywhere, let me describe
      what I see as a canonical loop:</p>
    <ul class="">
      <li class="">Use LCSSA, and LoopSimplify form.  Meaning no-uses of
        instructions defined in loop outside of loop and phis of loop
        exit blocks.  Preheaders available.  Unique (unshared) exit
        blocks.  <br class="">
      </li>
      <li class="">All trivial CSE done.  I include both arithmetic and load
        elimination for constant memory.<br class="">
      </li>
      <li class="">All instsimplify style simplifications available within the
        loop and preheader done.  There's an argument for doing
        instcombine style optimizations within the loop as well, but
        that's less clear to me.  <br class="">
      </li>
      <li class="">All trivial LICM done.  By this I mean LICM which does not
        require aliasing or speculation safety logic.  This is
        Loop::makeInvariant. <br class="">
      </li>
      <li class="">All trivial branches discharged.  By this I mean both
        CFGSimplify style elimination of constant branch conditions, but
        also CVP, KnownBits, and SCEV.  (Today, this is often true on
        entry to a loop pass manager, but is not upheld as passes run.)<br class="">
      </li>
    </ul>
    To be clear, the above list is aspirational.  We definitely don't do
    all of the above today.  :)<br class="">
    <br class="">
    Philip<br class="">
    <br class="">
    <div class="moz-cite-prefix">On 03/02/2018 04:36 PM, Vedant Kumar
      via llvm-dev wrote:<br class="">
    </div>
    <blockquote type="cite" cite="mid:D18FB05F-9CE4-42E2-8865-3E0B028DDF1E@apple.com" class="">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252" class="">
      Hi,
      <div class=""><br class="">
      </div>
      <div class="">I think we should remove the LoopInstSimplify pass,
        as it has no test coverage and no users (afaik).</div>
      <div class=""><br class="">
      </div>
      <div class="">If you are using the pass, or think that it should
        stay in tree for some other reason, please let me know.</div>
      <div class=""><br class="">
      </div>
      <div class="">Here's the patch: <a href="https://reviews.llvm.org/D44053" class="" moz-do-not-send="true">https://reviews.llvm.org/D44053</a></div>
      <div class=""><br class="">
      </div>
      <div class="">vedant</div>
      <br class="">
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br class="">
      <pre wrap="" class="">_______________________________________________
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 class="">
  </div>

</div></blockquote><span class=""></span><span class=""></span><span class=""></span></div><br class=""></div></div></body></html>