<div dir="ltr"><div>The two proposals have interesting upsides and downsides:</div><div><br></div>Making it a property of the function makes a lot of sense because we don't need the power to say that loops A and B have different termination guarantees in the same function. Also, as you mention, it makes the front-end's job a lot easier because it just slaps the attribute down and calls it a day.<div><br></div><div>I think the problem with the attribute (which is solved by the intrinsic) is that we would have to come up a very careful set of semantics for CFGs to make sure that hoisting wouldn't "break" things like:</div><div><br></div><div>while (always_true_at_runtime)</div><div> ;</div><div>*(volatile int *)NULL = 0;</div><div><br></div><div>doesn't turn into:</div><div><br></div><div><div>*(volatile int *)NULL = 0;</div><div>while (always_true_at_runtime)</div><div> ;</div><div><br></div></div><div>The intrinsic gives us a way of reifying the side effect in a semantically obvious way.</div><div><br></div><div>In the same way that calls which are not nounwind have an implicit abnormal edge heading out of the function, this intrinsic basically makes it possible to add abnormal edges to the CFG without having to retrofit LLVM to *really* have abnormal edges.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 26, 2017 at 10:08 PM, Dan Gohman 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"><div>Hello,</div><div><br></div><div>This email picks up the thread that to my knowledge was last discussed here:</div><div><div><br></div><div><a href="http://lists.llvm.org/pipermail/llvm-dev/2015-July/088103.html" target="_blank">http://lists.llvm.org/pipermai<wbr>l/llvm-dev/2015-July/088103.ht<wbr>ml</a></div></div><div><br></div><div>In brief, infinite loops containing no side effects produce undefined behavior in C++ (and C in some cases), however in other languages, they have fully defined behavior. LLVM's optimizer currently assumes that infinite loops eventually terminate in a few places, and will sometimes delete them in practice. There is currently no clean way to opt out of this behavior from languages where it's not valid.</div><div><br></div><div>This is the subject of a long-standing LLVM bug:<br></div><div><br></div><div><a href="https://bugs.llvm.org/show_bug.cgi?id=965" target="_blank">https://bugs.llvm.org/show_bug<wbr>.cgi?id=965</a></div><div><br></div><div>I wrote a patch implementing Chandler's idea from the above thread, @llvm.sideeffect, a new intrinsic which is a no-op except that it tells the optimizer to behave as if there were side effects present:<br></div><div><br></div><div><a href="https://reviews.llvm.org/D38336" target="_blank">https://reviews.llvm.org/D3833<wbr>6</a></div><div><br></div><div>Similar results can be achieved with empty inline asms, however they tend to pessimize optimizations. The patch above allows all of the major optimizations to work in the presence of @llvm.sideeffect.</div><div><br></div><div>One of the concerns raised is that front-ends would have to emit a lot of these intrinsics, potentially one in every loop, one in every function (due to opportunistic tail-call optimization), and one in front of every label reachable by goto or similar, if a front-end can't determine when they aren't needed. This is indeed a downside. It's mitigated in this patch by making sure that the major optimization passes aren't pessimized.<br></div><div><br></div><div><div>From the alternatives I've read, the most promising alternative is Reid's proposal here:</div><div><br></div><div><a href="https://bugs.llvm.org/show_bug.cgi?id=965#c25" target="_blank">https://bugs.llvm.org/show_<wbr>bug.cgi?id=965#c25</a><br></div><div><br></div><div>to
make infinite loops defined by default, and
add a "known to be productive" attribute to functions. It would be a more complex change, and could potentially require changes in out-of-tree codebases. And it would be suboptimal in some cases when cross-language inlining. However, it would solve the problem in a much less cluttered way. I'm willing to implement the LLVM portion of this if there's consensus that it's a better approach.<br></div></div><div><br></div><div>Thoughts?<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div>Dan<br><br></font></span></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">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/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>