<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 1, 2016 at 12:14 PM, David Majnemer via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Aug 1, 2016 at 11:08 AM, Nadav Rotem via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">







<div bgcolor="white" lang="EN-US" link="#0563C1" vlink="#954F72">
<div>
<p class="MsoNormal"><span style="font-size:11pt">Hi David, <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">Thanks for working on this.  I’d like to help reviewing your work!
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">How much code from the original patch are you leaving around? If you are reusing a lot of code from the original pass then you can refactor, clean and add new functionality. But if you are not keeping much
 then maybe it would be useful to develop a new pass (with small incremental reviewable changes), and when the work is done flip the switch and start using the new pass. What do you prefer?   <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">I think that introducing the new flag that allows the removal of infinite loops is a great idea. LLVM is used for compilation of non-C languages, like Swift, Java, Python, etc, and these languages may benefit
 from the new functionality.</span></p></div></div></blockquote><div><br></div></span><div>LLVM doesn't handle "infinite loops are a side effect" in a principled way:</div><div>- The LLVM IR corresponding to an infinite loop doesn't contain side effects which means that the loop itself doesn't have side effects.  Calls to functions which merely infinite loop can (and will) be removed by LLVM (because they are readnone, nounwind, etc.). </div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>A proper design for "infinite loops are a side effect" would likely be a function attribute which indicates what behavior the optimizer may assume when it sees a loop with unknown bound in a function.</div><div><br></div></div></div></div></blockquote><div><br></div><div>True. FWIW, at least the previous versions of the pass are entirely based on control flow.</div><div><br></div><div>That is, they are variants of the traditional control-dependence based DCE removal. They will remove output-free infinite loops, regardless of bound.</div><div>They will not detect loops whose bound is infinite.</div><div><br></div><div>Essentially, it will remove any loop it is not necessary to go through to get to an instruction that is not dead.</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>While this doesn't mean that the pass shouldn't contain logic for leaving infinite loops alone, it likely means that parameterizing the pass on a flag is wrong.</div></div></div></div></blockquote><div><br></div></div></div></div>