<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, May 16, 2018 at 5:53 PM Hal Finkel via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As you likely already know, I'm not a fan of having calls that might<br>
unwind, or otherwise have implicit edges, in the middle of basic blocks.<br>
I continue to believe that they should be terminators. As such, while I<br>
realize that there are definite efficiency concerns about doing this in<br>
general (and, perhaps, a bunch of optimizations that would need to start<br>
looking across multiple blocks to maintain feature parity), I'm fully<br>
supportive of this change (I'm assuming that you've not found any<br>
serious compile-time implications in this regard).<br></blockquote><div><br></div><div>Without being on the hook to do any of the work or hard thinking, I can say I agree. :)<br></div><div><br></div><div>We might be able to paper over a lot of these concerns about missed optimizations with some new ExtendedBasicBlock helpers that iterate instructions across single-successor single-predecessor BB edges from potentially throwing calls and trivially simplifiable unconditional branches.</div><div><br></div><div>We can reuse the "unwind to caller" spelling that we already use in WinEH, so potentially throwing calls with no landingpad would look like:</div><div>  invoke void @foo()</div><div>    to label %normal unwind to caller</div><div><br></div><div>We could either null out the unwind label operand of today's InvokeInst or find a way to not avoid allocating it in the first place. That would require a fair amount of rework, though. I'd probably just null it out for now.</div></div></div>