<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 18, 2014 at 5:52 PM, Kaylor, Andrew <span dir="ltr"><<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.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 lang="EN-US" link="blue" vlink="purple">
<div><span class="">
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> For DWARF EH and SjLj, the backend is responsible for handling most of the EH work. It seems like it would be a more consistent design for SEH to do the same.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
</span><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Looking beyond SEH to C++ exception handling for a moment, it seems to me that clang may be handling more than it should there.  For instance, calls like “__cxa_allocate_exception”
 and “__cxa_throw_exception” are baked into the clang IR output, which seems to assume that the backend is going to be using libc++abi for its implementation.  Yet it has enough awareness that this won’t always be true that it coughs up an ErrorUnsupported
 failure for “isWindowsMSVCEnvironment” targets when asked to emit code for “try” or “throw”.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Should this be generalized with intrinsics?</span></p></div></div></blockquote><div><br></div><div>We should just teach Clang to emit calls to the appropriate runtime functions. This isn't needed for SEH because you don't "throw", you just crash.</div><div> <span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span></div><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 lang="EN-US" link="blue" vlink="purple"><div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Also, I’m starting to dig into the outlining implementation and there are some things there that worry me.  I haven’t compared any existing code that might
 be doing similar things, so maybe these issues will become clear as I get further into it, but it seemed worth bringing it up now to smooth the progress.  I’m trying to put together a general algorithm that starts at the landing pad instruction and groups
 the subsequent instructions as cleanup code or parts of catch handlers.  This is easy enough to do as a human reading the code, but the way that I’m doing so seems to rely fairly heavily on the names of symbols and labels. </span></p></div></div></blockquote><div> </div><div>Look at lib/Transforms/Utils/CloneFunction.cpp. Most of that code should be factored appropriately and reused. It uses a ValueMapping that we should be able to apply to the landing pad instruction to map the ehselector.slot to a constant, and propagating that through.</div><div> </div><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 lang="EN-US" link="blue" vlink="purple"><p class="MsoNormal"></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">For instance, following the landingpad instruction I expect to find an extract and store of “exn.slot” and “ehselector.slot” then everything between that and
 wherever the catch dispatch begins must be (I think) cleanup code.  The catch handlers I’m identifying as a sequence that starts with a load of “exn.slot” and a call to __cxa_begin_catch and continues until it reaches a call to __cxa_end_catch.</span></p></div></blockquote><div><br></div><div>I think we'll have to intrinsic-ify __cxa_end_catch when targeting *-windows-msvc to get this right. If we don't, exception rethrows will probably not work. We don't really need an equivalent of __cxa_begin_catch because there's no thread-local EH state to update, it's already managed by the caller of the catch handler.</div><div><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span></div><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 lang="EN-US" link="blue" vlink="purple">
<p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">The calls to begin/end catch are pretty convenient bookends, but identifying the catch dispatch code and pairing catch handlers with the clauses they represent
 seems to depend on recognizing the pattern of loading the ehselector, getting a typeid then comparing and branching.  I suppose that will work, but it feels a bit brittle.  Then there’s the cleanup code, which I’m not yet convinced has a consistent location
 relative to the catch dispatching and I fear may be moved around by various optimizations before the outlining and will potentially be partially shared with cleanup for other landing pads.</span></p></div></blockquote><div><br></div><div>We either have to pattern match the selector == typeid pattern in the EH preparation pass, or come up with a new representation. I'm hesitant to add a new EH representation that only MSVC compatible EH uses, because it will probably trip up existing optimizations. I was hoping that something like the pruning logic in "llvm::CloneAndPruneFunctionInto" would allow us to prune the selector comparison branches reliably.</div></div></div></div>