<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 13, 2015 at 11:03 AM, Kaylor, Andrew <span dir="ltr"><<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>></span> wrote:<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">So there are two issues here.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">1) We need a better way to figure out which blocks should be in which handlers and properly remap the return statements in each handler accordingly.<u></u><u></u></p>
<p class="MsoNormal">2) We need a better way to compute the EH states.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Anyway, I’m working on these problems right now.  I’m still trying to solve the problems without redesigning our current scheme, but I don’t think this is going to be the right long term solution.</p></div></div></blockquote><div><br></div><div>Yeah, we're on the same page. The current scheme is not the right long term solution. The SEH personality functions are not nearly as limiting. I was hoping that, like with SEH, we could completely throw away the information about try nesting and simply emit tables that are functionally correct. We knew it was theoretically impossible to always recover the nested try structure from Itanium-style landingpad IR, but now we know it is also *practically* impossible. :)</div><div><br></div><div>Ultimately, I think something like the dispatchblock scheme I described will work better.</div></div></div></div>