<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.<wbr>html</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">https://bugs.llvm.org/show_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?<br></div><div><br></div>Dan<br><br></div>