<div dir="ltr">Whatever we choose, i think we need to take a step back and evaluate the larger problem and whether we are solving it in the best way, rather than  just add tons of "check every instruction between hear and there" code :)<div><br></div><div>(If we end up thinking that is truly the best way, great, i'll not object. i'm more concerned that we are just trying to patch what we see as bugs instead of stopping to think about whether the whole thing is just broken and in need of rethinking, because i suspect it is.)<br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 6, 2016 at 4:44 PM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">sanjoy added a subscriber: broune.<br>
sanjoy added a comment.<br>
<br>
One possibility is writing a "strong post dominance" analysis pass that was brought up by @broune earlier [0].  If it looks like a lot of LLVM's transform passes are buggy in the face of `exit(0)` or throwing or inf-looping calls, perhaps we will be okay paying the cost of computing and preserving this analysis?<br>
<br>
We also need some infrastructural work around "halting" or "always_returns" attributes; I suspect the bug you're fixing here will also occur if the function being called does `volatile int i = 0; while (true) i++;` instead of `exit(0)`.<br>
<br>
[0]: <a href="http://lists.llvm.org/pipermail/llvm-dev/2015-July/087744.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2015-July/087744.html</a><br>
<br>
<br>
<a href="http://reviews.llvm.org/D21041" rel="noreferrer" target="_blank">http://reviews.llvm.org/D21041</a><br>
<br>
<br>
<br>
</blockquote></div><br></div>