<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 6, 2016 at 5:15 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</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 class="gmail_extra"><div class="gmail_quote"><span class="">On Mon, Jun 6, 2016 at 4:38 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.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>On Mon, Jun 6, 2016 at 4:06 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</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">eli.friedman added a comment.<br>
<br>
It probably doesn't make sense to turn every `call` instruction into an `invoke` or equivalent; that would cause the size of the IR to explode,</blockquote><div><br></div></span><div>I'm going to disagree.  GCC has EH/abnormal "fake" edges to handle these cases, and works much better than LLVM in this regard, and has no such explosion problem on normal C++ code. In fact, it's going to be faster.</div><div>  </div><div>If we have a modeling problem, we should fix the modeling problem.</div><div>You can abstract this to the block level.  The block has an EH successor,   That just means in some fashion, the block may go to this EH edge.</div><div>It does not require you terminate the block at every mayThrow instruction.</div></div></div></div></blockquote><div><br></div></span><div>Oh... so instead of precisely tracking the CFG inside the block, you just approximate and say "this block as a whole can terminate early"?  That makes sense, especially for stuff like loop optimization.<br></div></div></div></div></blockquote><div><br></div><div>Yes.</div><div>The downside is that it pretty much has to appear as a successor/predecessor edge to make it just work in infrastructure.</div><div><br></div><div>This is probably easily achievable by always creating an empty return block giving may-throw calls a fake edge to it.</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><br></div><div class="gmail_quote">There are some places that want more precise tracking, though;</div></div></div></blockquote><div><br></div><div>Sure, and if you discover "it super matters whether i can put it here or not", you can look closer.</div><div>But you don't *always* have to look closer.</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"> I ended up rewriting my patch for DSE to precisely track unwind edges.  Maybe that isn't common enough to be worth worrying about.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div class="gmail_quote">-Eli<br></div></font></span></div></div>
</blockquote></div><br></div></div>