<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi Reid,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I’ve worked through a few scenarios, and I think this is converging. I’m attaching a new example, which extends the one we’ve been working through to handle
a few more cases.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I wasn’t sure what you intended the first i32 argument in an llvm.eh.actions entry to be. I’ve been using it as a place to store the eh state that I’m associating
with the action, but that’s kind of circular because I’m using the information in these tables to calculate that value. I’ll be able to do this calculation in the MSVCEHPrepare pass before these instructions are added, so I can put it there (it’s nice for
readability), but the later pass that generates the tables (assuming we leave that in a later pass) will need information not represented in the action table (at least as I’ve been using it). I’m not 100% sure that this is necessary, but it seemed like the
way things ought to be. I’ll experiment more before anything gets set in stone.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">In addition to the IP-to-state table that we’ve talked about, we also need an unwind table (which has each state, the state it transitions to when it expires
and the unwind handler, if any) and a catch handler table (which has the range of states that can throw to the handlers, the state of the handlers and a map of types handled to their handlers). I’ve got examples of these in the attached example.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">So I now have a firm plan for how to compute these tables from the outlined IR.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I think the algorithm you proposed for computing eh states doesn’t quite work. In particular, if multiple catch handlers get added by the same landing pad
we’ll want to start by assuming that they have the same state. If they end up getting popped at different times then we’ll need to update the eh state of the one that gets popped first. Unfortunately my example doesn’t cover this case, but I worked through
it and my new algorithm (based on your but slightly tweaked) works for that case. Also, unwind handlers get discrete states (they happen when a transition crosses the state, but in the .xdata tables they are represented with a single state). Catch handlers,
on the other hand, do get a range.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Anyway, here’s what I’m doing (by hand so far, I don’t have it coded yet).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">1. Start with an empty stack of actions and an empty master list of eh state.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">2. Visit each landing pad in succession, processing the actions at that landing pad back to front.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">3. Pop actions from the current stack that aren’t in the current landing pad’s action table<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> a. If a catch is popped that had been assumed to have the same state as a catch that isn’t being popped<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> its state number and all state numbers above it need to be incremented<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> b. When a catch is popped, the next available eh_state is assigned to its handler<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">4. As an action is pushed to the current stack, it is assigned an eh_state in the master list<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> a. If the action was an unwind or if it was a cacth after an unwind, the next available eh_state is incremented<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> b. If the action was a catch following a catch that was also just added, it gets the same eh_state as the previous catch<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">5. When all landing pads have been handled, the remaining actions are popped and processed as above.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The “next” state for each eh_state can also be computed during the above process by observing the state of the action on the top of the current action stack
when the action associated with the state is popped. In the case of catch handlers, I think the next state will always be the same as the next state of the corresponding catch action.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">So, I think it makes sense to compute the unwind and catch tables during the MSVCEHPrepare pass, but I wasn’t sure how best to preserve the information once
it was computed. Is it reasonable to stick this in metadata?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">We can keep fine tuning this if you like, but I think it’s looking solid enough that I’m going to start revising my outlining patch to produce the results in
the attached example.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-Andy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Reid Kleckner [mailto:rnk@google.com]
<br>
<b>Sent:</b> Tuesday, January 27, 2015 1:55 PM<br>
<b>To:</b> Kaylor, Andrew<br>
<b>Cc:</b> Bataev, Alexey; Reid Kleckner (reid@kleckner.net); LLVM Developers Mailing List; Anton Korobeynikov; Kreitzer, David L<br>
<b>Subject:</b> Re: [LLVMdev] RFC: Native Windows C++ exception handling<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">On Tue, Jan 27, 2015 at 12:58 PM, Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks, Reid. These are good points.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">So I guess that does take us back to something more like my original proposal.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I like your suggestion of having some kind of “eh.actions” intrinsic to represent the outlining rather
than the extension to landingpad that I had proposed. I was just working on something like that in conjunction with my second alternative idea.</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Great!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">What I’d really like is to have the “eh.actions” intrinsic take a shape that makes it really easy
to construct the .xdata table directly from these calls. As I think I mentioned in my original post, I think I have any idea for how to reconstruct functionally correct eh states (at least for synchronous EH purposes) from the invoke and landingpad instructions.
I would like to continue, as in my original proposal, limiting the unwind representations to those that are unique to a given landing pad. I think with enough documentation I can make that seem sensible.</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">My thinking is that the "eh.actions" list can be transformed into a compact xdata table later, after we've done machine basic block layout.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I think the algorithm will be something like<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">1. Input: already laid out MachineFunction<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2. Call EHStreamer::computeCallSiteTable to populate a LandingPadInfo vector sorted by ascending PC values<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">4. Iterate the LandingPadInfos, comparing the action list of each landing pad with the previous landing pad, assuming an empty action list at function start and end.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">5. Model the action list as a stack, and compute the common suffix of the landing pad action lists<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">6. Each new action pushed represents a new EH state number<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">7. Pushing a cleanup action adds a state table entry that transitions from the current EH state to the previous with a cleanup handler<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">8. Pushing a catch action adds a new unwind table entry with an open range from the current EH state to an unknown EH state. The state after catching is... ???<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">9. Popping a catch action closes an open unwind table range<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So, I think the action list is at least not totally crazy. =)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I’ll start working on a revised proposal. Let me know if you have any more solid ideas.</span><o:p></o:p></p>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>