<div dir="ltr">And now I'm planning to re-introduce it. I'll at least add test coverage. I'm also going to put it into the main loop pass pipeline so I can remove simplification logic from unswitching (at least for the new PM).</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Mar 5, 2018 at 1:52 PM Philip Reames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>The code is simple enough that I'd vote to delete and reintroduce
later if needed. :)</p></div><div text="#000000" bgcolor="#FFFFFF">
<p>Philip<br>
</p>
<br>
<div class="m_-4988733521048613306moz-cite-prefix">On 03/05/2018 01:23 PM, Vedant Kumar
wrote:<br>
</div>
<blockquote type="cite">
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><br>
</div>
<div>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><br>
</div>
<div>[+ Chad, one of the pass contributors, for comment.]</div>
<div><br>
</div>
<div>thanks,</div>
<div>vedant<br>
<div><br>
</div>
<div><br>
<div>
<blockquote type="cite">
<div>On Mar 5, 2018, at 8:47 AM, Philip Reames
<<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>>
wrote:</div>
<br class="m_-4988733521048613306Apple-interchange-newline">
<div>
<div text="#000000" bgcolor="#FFFFFF">
<p>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>Since we don't really document this
anywhere, let me describe what I see as a canonical
loop:</p>
<ul>
<li>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>
</li>
<li>All trivial CSE done. I include both
arithmetic and load elimination for constant
memory.<br>
</li>
<li>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>
</li>
<li>All trivial LICM done. By this I mean
LICM which does not require aliasing or
speculation safety logic. This is
Loop::makeInvariant. <br>
</li>
<li>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>
</li>
</ul>
To be clear, the above list is aspirational. We
definitely don't do all of the above today. :)<br>
<br>
Philip<br>
<br>
<div class="m_-4988733521048613306moz-cite-prefix">On 03/02/2018 04:36 PM,
Vedant Kumar via llvm-dev wrote:<br>
</div>
<blockquote type="cite">
Hi,
<div><br>
</div>
<div>I think we should remove
the LoopInstSimplify pass, as it has no test
coverage and no users (afaik).</div>
<div><br>
</div>
<div>If you are using the pass, or think
that it should stay in tree for some other reason,
please let me know.</div>
<div><br>
</div>
<div>Here's the patch: <a href="https://reviews.llvm.org/D44053" target="_blank">https://reviews.llvm.org/D44053</a></div>
<div><br>
</div>
<div>vedant</div>
<br>
<fieldset class="m_-4988733521048613306mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
LLVM Developers mailing list
<a class="m_-4988733521048613306moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_-4988733521048613306moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
</div>
</div>
</blockquote>
<span></span><span></span><span></span></div>
<br>
</div>
</div>
</blockquote>
<br>
</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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>