<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 2, 2014 at 4:15 PM, Vadim Chugunov <span dir="ltr"><<a href="mailto:vadimcn@gmail.com" target="_blank">vadimcn@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div>Hi Reid,<br></div>Is this design supposed to be able to cope with asynchronous exceptions?   I am having trouble imagining how this would work without adding the ability to associate landing pads with scopes in LLVM IR.</div></div></blockquote><div><br></div><div>Yes, but not from within the same function. My proposal is to simply outline __try bodies into another function and invoke it. __try blocks are very uncommon, but C++ destructor cleanups are. Outlining them is prohibitively expensive, and I am not proposing to do this. In other words, faithfully implementing MSVC's -EHa flag is a non-goal.</div><div><br></div><div>If you want a higher fidelity implementation, I would not propose adding unwind edges to basic blocks. This has been suggested in the past, but a lot of LLVM would need to be taught about this implicit control flow.</div><div><br></div><div>Instead, I would propose identifying all trapping instructions and adding intrinsics for them. Intrinsics can be called with invoke, which makes all of the implicit CFG edges explicit. Peter Collingbourne proposed adding iload and istore instructions, and this would basically be a less invasive version of that. Optimizations would obviously suffer on intrinsics instead of instructions, but that's a price you have to pay for async EH anyway.</div></div></div></div>