<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 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 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;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
.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">>
</span>teach the inliner how to undo framerecover and let the optimization fall out that way<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">You'd still have the problem that the referenced variables were frameescaped and appear to be read/written at unrelated calls.<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">>
</span>__finally is pretty rare<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">`__finally` may be rare in SEH code, but `finally` is quite common in .Net code, so we're going to need a solution that avoids early `finally` outlining for
the same reasons we're avoiding early `catch` outlining.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">While we do need something that's amenable to duplicating `finally` code on hot/non-EH paths (since this is an important optimization for .Net code), I think
there also needs to be a path that can be taken for very cold code / very large cleanups / very deeply-nested cleanups to avoid quadratic code expansion on those cases. Early outlining of just those cases could maybe be made to work, but would require that
the decision be made early; it would be much more palatable to make the decision in the natural course of optimization (e.g. some sort of tail duplication).<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 we should have a way to enter/exit cleanup blocks on non-EH paths.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The smallest change to your proposal that comes to mind which would allow this would be:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - a normal branch can target a cleanupblock<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - the resume/unwind terminator that ends a cleanup would have another optional target label (%normalsucc). The semantics would be that the EH edge to %nextaction
would be taken if the cleanupblock were entered by an EH edge, and the normal edge to %normalsucc would be taken otherwise.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - converting this to landingpads would manifest an i1 that would need to be set before branching to the cleanupblock, and turn the unwind/resume into a condbr
on that<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - codegen for windows could turn the branch to cleanupblock into a call to the handler followed by a jump to the %normalsucc<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">A change that I'd consider preferable since it avoids the need for an auxiliary switch in the non-EH code would be:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - some new terminator along the lines of 'entercleanup %cleanupblock recover to %recoverblock', rather than a plain branch, can target cleanupblocks<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - the resume/unwind terminator that ends a cleanup would have any number of additional successors, and just like the rule that the EH target must match
the %nextaction referenced on the cleanupblock, the non-EH targets would need to match one of the %recoverblocks specified on one of the entercleanups targeting the cleanupblock<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - converting this to landingpads would manifest an int that would need to be set before branching to the cleanupblock, and turn the unwind/resume into a
switch<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> - codegen for windows could turn entercleanup into a call to the handler followed by a jump to the %recoverblock<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Those are the first two options that come to mind, anyway. I'm sure there are other options, but the key points are:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">1) can avoid early outlining of finally bodies, and<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">2) can avoid runaway code expansions<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">Regarding naming, I like your new suggestions (though the changes I'm suggesting to cleanup-ending terminators are a mix between recover and unwind… FWIW, 'endfinally'
would be a natural name for that in my world </span><span style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">J</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">. Personally I wouldn't hate something verbose like
recover_or_unwind for the forms that may be doing either. 'endcleanup' also comes to mind.).<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">Thanks<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">-Joseph<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"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></a></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> Reid Kleckner [mailto:rnk@google.com]
<br>
<b>Sent:</b> Tuesday, May 19, 2015 3:40 PM<br>
<b>To:</b> Joseph Tremoulet<br>
<b>Cc:</b> LLVM Developers Mailing List; Bill Wendling; Nick Lewycky; Kaylor, Andrew<br>
<b>Subject:</b> Re: [LLVMdev] RFC: New EH representation for MSVC compatibility<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">On Mon, May 18, 2015 at 8:40 PM, Joseph Tremoulet <<a href="mailto:jotrem@microsoft.com" target="_blank">jotrem@microsoft.com</a>> wrote:<o:p></o:p></p>
</div>
<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>
<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">>
</span>I want to have separate normal and exceptional codepaths<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 assume you at least mean that's what you'll be doing in Clang's initial IR generation. Do you
also mean to impose this as a restriction on other IR generators, and as a property that IR transformations must preserve? I.e., is this something that EH preparation can assume?</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">EH preparation should not assume that each basic block lives in exactly one funclet. People seem to get really upset when I suggest that we change the language rules to maintain that invariant. :-)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Instead, the EH preparation pass is responsible for establishing that invariant by duplicating blocks, but it should be *way* easier with real basic block terminator instructions to mark handler transitions.<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>
<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">>
</span>For __finally, we outline the finally body early in clang and emit two calls to it as before, but passing in the frameaddress as an argument<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">But then you have to frameescape any __finally-referenced local before optimization, and doesn't
that defeat the purpose of delaying funclet outlining to EH preparation?</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">True. I'm not committed to this approach, I just want to preserve functionality until we implement the de-commoning part of EH preparation, which I figured we could do later, since it's one of the more obscure corner cases.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Also, __finally is pretty rare, so it's not too crazy to teach the inliner how to undo framerecover and let the optimization fall out that way.<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>
<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">>
</span>tail merging could kick in like you mention. Undoing this would be and currently is the job of WinEHPrepare. I guess I felt like the extra representational complexity wasn't worth the confidence that it would buy us<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">For one, it seems counterproductive to let tail merge think it can kick in when it's doomed to be
undone.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm only saying that the tail merging is legal, and not that it is desirable. We can teach simplifycfg that tail merging 'resume' instructions is a waste of time, for example.<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>
<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">For another, if we're talking about a setup where EH paths might mingle with non-EH paths but the
funclet will only be invoked for the EH cases, then I believe this would help the "</span>pruning as many unreachable CFG edges as possible<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> " step be more effective -- after finding
out which blocks are reachable from a catch/cleanup, you could intersect that with the set of blocks from which a corresponding resume can be reached. Any funclet blocks ending in condbr/switch that only wind up with one successor in the funclet could then
have their terminators rewritten as unconditional branches, without needing to recover dataflow and chase constants through phis and resolve compares/switches and all that.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">For discussion purposes, let's imagine that 'resume' takes a 'from' label which must be an EH block (it starts with one of these new instructions). The nice thing about using a label here is that, unlike most SSA values, labels cannot be
phi'd. Now tail merging will have to give up or insert an i1 ph and a conditional branch on the resume instruction, which realistically it won't since it's not a clear win.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Originally, I was thinking that this extra funclet cloning precision wasn't worth it, because we'd arrange the frontend and optimizers to make it unlikely, but I'm coming around to it. It mirrors the EH pointer value required by Itanium
EH.<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">></span> I'm not married to reusing 'resume', other candidate names include 'unwind' and 'continue',
and I'd like more ideas<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">The first thing that comes to mind is 'endatch/exitcatch', but to use that you'd need to rename other
things since it would be confusing vis-à-vis catchendblock and lack symmetry with catchblock that isn't prefixed with begin/enter.</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">You could consider 'filter' (or 'filterblock') for 'catchblock', since conceptually it plays the
role of a filter (typically one which consults type information; I've seen such things called "typetestfilter" before). Or 'dispatch'/'dispatchblock'/'exceptiondispatch'/'dispatchexception' (isn't that what Clang names the blocks it creates for the explicit
dispatch code?); 'catchendblock' would then be something like 'unwinddispatch' or 'continuedispatch' or 'resumedispatch' and the resume that returns to normal execution could be 'exitdispatch' or 'exitcatch' or even 'uncatch'.</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">For the resumes that end cleanups, something like 'endcleanup' might work.</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">Names are hard…</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">'dispatch' might work for the instruction which transitions from a cleanup to the next EH block. :) I don't really see how to work filter in, especially since we've already used it for landingpad filters, which exist to support exception
specifications.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Chatting around the office, we came up with 'recover' and 'unwind' for ending catch and cleanup blocks respectively.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A 'recover' instruction would end a catch block, and would target the block where the exception is over. This instruction would modify memory, because it destroys the exception object. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">An 'unwind' instruction would end a cleanup block, and would target the next action. I like this because I talk a lot about "unwind edges" in the CFG, and a cleanup finishing feels like an unwind edge. I could also see 'dispatch' here.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Some possible new syntax:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">recover from label %<a href="http://maycatch.int">maycatch.int</a> to label %endcatchbb<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">unwind from label %cleanup.obj to label %nextaction<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">unwind from label %cleanup.obj ; unwinds out of the function, hook it up to the unwind edge of an inlined call site<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">For Itanium, tail merging is profitable and doable with phis, so we might want to do this instead:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">recover to label %endcatchbb<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">unwind i8* %ehptr to label %nextaction<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">unwind i8* %ehptr ; unwinds out of the function, hook it up to the unwind edge of an inlined call site<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Itanium requires threading the active exception pointer through to the next action or _Unwind_Resume, so it passes along an SSA value. MSVC needs this weird kind of control dependence instead. We could drop the 'from' token as unnecessary,
but I want to make it easier to reason about the textual representation.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>