<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=us-ascii">
<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:PMingLiU;
panose-1:2 2 5 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;}
@font-face
{font-family:"\@PMingLiU";
panose-1:2 1 6 1 0 1 1 1 1 1;}
@font-face
{font-family:"Segoe UI";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
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:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:216673184;
mso-list-type:hybrid;
mso-list-template-ids:2137451236 1497001486 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:4;
mso-level-number-format:bullet;
mso-level-text:\F0D8;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;
mso-fareast-font-family:PMingLiU;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;
mso-bidi-font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;
mso-bidi-font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;
mso-bidi-font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;
mso-bidi-font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;
mso-bidi-font-family:Wingdings;}
@list l1
{mso-list-id:1729524823;
mso-list-type:hybrid;
mso-list-template-ids:2136919444 382921748 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-start-at:4;
mso-level-number-format:bullet;
mso-level-text:\F0D8;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;
font-family:Wingdings;
mso-fareast-font-family:PMingLiU;
mso-bidi-font-family:Calibri;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.25in;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.75in;
text-indent:-.25in;
font-family:Wingdings;
mso-bidi-font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.25in;
text-indent:-.25in;
font-family:Symbol;
mso-bidi-font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.75in;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.25in;
text-indent:-.25in;
font-family:Wingdings;
mso-bidi-font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.75in;
text-indent:-.25in;
font-family:Symbol;
mso-bidi-font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:4.25in;
text-indent:-.25in;
font-family:"Courier New";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:4.75in;
text-indent:-.25in;
font-family:Wingdings;
mso-bidi-font-family:Wingdings;}
@list l2
{mso-list-id:1946377652;
mso-list-type:hybrid;
mso-list-template-ids:-1625129496 705075440 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l2:level1
{mso-level-text:"\(%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal" style="margin-left:.5in;text-indent:-.25in"><o:p> </o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo3"><span style="color:black;background:white">Take your example, replace “_try” with C++ “try”, replace the “_finally” with “catch(….)” with a “throw;” at the end of the catch block,
replace the “_except()” with “catch(…)”, and see what clang currently generates. That seems roughly equivalent to what you’re trying to do. Extending this scheme to encompass try/finally seems like it shouldn’t require new datastructures in clang’s AST, or
new entrypoints in the C runtime.</span><span style="background:white"><o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo3"><span style="background:white"><o:p> </o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo3"><span style="color:black;background:white">But I could be missing something; I’m not deeply familiar with the differences between C++ and SEH unwind handlers.</span><span style="background:white"><o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo3"><o:p> </o:p></li></ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Right, you are missing something. The semantic of a “goto” from a SEH _finally is totally different from it’s in EH Catch handler. It’s why I have illustrated the semantic of “jumping-out-of-a _finally” in the first example in the document.
<o:p></o:p></p>
<p class="MsoNormal">When a goto in a _finally occurs, we must “unwind” to the target code, not just “jump” to target label. This is why it’s called “local_unwind()”, depending on the EH state of the target, local_unwind() runtime invokes _finally properly
alone the way to final target. Again, take the case #2 as example, the outer _finally must be invoked before control goes to $t10.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo3"><span style="color:black;background:white">To be clear, we’re talking about making all memory accesses, including accesses to local variables, in the try block “volatile”? So the compiler
can’t do any optimization on them? That gets you some fraction of the way there; there are no issues with SSA registers if there aren’t any live SSA across the edge. And the compiler can’t move volatile operations around each other. That leaves open the
question about what to do about calls; we don’t have any generic way to mark a call “volatile”. I guess we could add something. At that point, basically every memory operation and variable would be completely opaque to the compiler, which would sort of force
everything to work, I guess. But at the cost of terrible performance if there’s any non-trivial code in the block. (And it’s still not theoretically sound, because the compiler can introduce local variables.)</span><span style="background:white"><o:p></o:p></span></li></ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The call inside a _try is an invoke with EH edge. So it’s perfectly modeled. A HW exception occurs in callee will be properly caught and handled. <o:p></o:p></p>
<p class="MsoNormal">Volatizing the _try block is done in Clang FE. So LLVM BE temporary variables will not be volatile.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Finally I would not say it’s at the cost of terrible performance because:<o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level1 lfo4">Again, in really world code, it’s very small amount of code are directly inside a _try, and they are mostly not performance critical.<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level1 lfo4">If the HW exception flow is perfectly modeled with iload/istore or with pointer-test explicit flow model, likely optimizations will be severely hindered. The result code will be probably
not much better than volatile code. <o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">--Ten<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Eli Friedman <efriedma@quicinc.com> <br>
<b>Sent:</b> Wednesday, April 1, 2020 5:41 PM<br>
<b>To:</b> Ten Tzen <tentzen@microsoft.com>; llvm-dev <llvm-dev@lists.llvm.org><br>
<b>Cc:</b> Aaron Smith <aaron.smith@microsoft.com><br>
<b>Subject:</b> [EXTERNAL] RE: [llvm-dev] [RFC] [Windows SEH] Local_Unwind (Jumping out of a _finally) and -EHa (Hardware Exception Handling)<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Reply inline<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b>From:</b> Ten Tzen <<a href="mailto:tentzen@microsoft.com">tentzen@microsoft.com</a>>
<br>
<b>Sent:</b> Wednesday, April 1, 2020 3:54 PM<br>
<b>To:</b> Eli Friedman <<a href="mailto:efriedma@quicinc.com">efriedma@quicinc.com</a>>; llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
<b>Cc:</b> <a href="mailto:aaron.smith@microsoft.com">aaron.smith@microsoft.com</a><br>
<b>Subject:</b> [EXT] RE: [llvm-dev] [RFC] [Windows SEH] Local_Unwind (Jumping out of a _finally) and -EHa (Hardware Exception Handling)<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:1.0in"><o:p> </o:p></p>
<p class="MsoListParagraph" style="margin-left:1.25in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-family:Wingdings"><span style="mso-list:Ignore">Ø<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>For goto in finally, why are you inventing a completely new mechanism for handling this sort of construct? What makes this different from our existing handling of goto out of catch blocks? Maybe there’s something obvious here
I’m missing, but it looks like essentially the same problem, and I don’t see any reason why we can’t use the existing solution.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white">No, no new mechanism is invented. The design employs the existing mechanism to model the third exception path caused
by _<i>local</i>_unwind (in addition to normal execution and exception handling flow). In earlier discussion with Joseph, adding second EH edge to InvokeInst was briefly discussed, but was quickly dropped as it’s clearly a long shot.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="background:white"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black;background:white">Yes, right, it’s not really a big extension of the fundamental model. It still seems like you’re doing more than what’s necessary.</span><span style="background:white"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white">The extended model intends to solve the third control-flow that doesn’t seem representable today. <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white">Take case #2 of the first example in wiki page as an example,
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white">the control flowing from normal execution of inner _finlly, passing through outer _finally, and landing in $t10 cannot
be represented by LLVM IR. <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white">Or could you elaborate how to achieve it? (Bear with me as I’m new in Clang&LLVM world).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="background:white"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="background:white"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black;background:white">Take your example, replace “_try” with C++ “try”, replace the “_finally” with “catch(….)” with a “throw;” at the end of the catch block, replace the “_except()” with “catch(…)”, and see what clang
currently generates. That seems roughly equivalent to what you’re trying to do. Extending this scheme to encompass try/finally seems like it shouldn’t require new datastructures in clang’s AST, or new entrypoints in the C runtime.</span><span style="background:white"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="background:white"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black;background:white">But I could be missing something; I’m not deeply familiar with the differences between C++ and SEH unwind handlers.</span><span style="background:white"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:1.25in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:12.0pt;font-family:Wingdings;color:#24292E"><span style="mso-list:Ignore">Ø<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>..In general, UB means the program can do anything. <span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white">Sorry, what is UB?
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="background:white"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black;background:white">Undefined behavior.</span><span style="background:white"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white">Right we are not modeling HW exception in control-flow as it’s not necessary.
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white">For C++ code, we don’t care about the value in register, local variable, SSA and so on. All we need is that “live
local-objects got dtored properly when HW exception is unwound and handled”. </span>
<span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;background:white"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white">For C code, only those code under _try construct is affected. Agree that making memory accesses there volatile is
sub-optimal. But it should not have correctness issue. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="background:white"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black;background:white">To be clear, we’re talking about making all memory accesses, including accesses to local variables, in the try block “volatile”? So the compiler can’t do any optimization on them? That gets you
some fraction of the way there; there are no issues with SSA registers if there aren’t any live SSA across the edge. And the compiler can’t move volatile operations around each other. That leaves open the question about what to do about calls; we don’t have
any generic way to mark a call “volatile”. I guess we could add something. At that point, basically every memory operation and variable would be completely opaque to the compiler, which would sort of force everything to work, I guess. But at the cost of
terrible performance if there’s any non-trivial code in the block. (And it’s still not theoretically sound, because the compiler can introduce local variables.)</span><span style="background:white"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="background:white"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white">In MSVC, there is one less restricted “write-through” concept for memory access inside a _try. But I think the benefit
of it is minor and it’s not worth it as the amount of code directly under _try is very small, and usually is not performance critical code.
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:1.25in;text-indent:-.25in;mso-list:l1 level1 lfo2">
<![if !supportLists]><span style="font-size:12.0pt;font-family:Wingdings;color:#24292E"><span style="mso-list:Ignore">Ø<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]>..I don’t want to add another way for unmodeled control flow to break code.<span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white">I would really love to hear (and find a way to improve) if there is any place in this design & implementation which
is not sound or robust.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E;background:white">--Ten<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b>From:</b> Eli Friedman <<a href="mailto:efriedma@quicinc.com">efriedma@quicinc.com</a>>
<br>
<b>Sent:</b> Wednesday, April 1, 2020 1:20 PM<br>
<b>To:</b> Ten Tzen <<a href="mailto:tentzen@microsoft.com">tentzen@microsoft.com</a>>; llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
<b>Cc:</b> Aaron Smith <<a href="mailto:aaron.smith@microsoft.com">aaron.smith@microsoft.com</a>><br>
<b>Subject:</b> [EXTERNAL] RE: [llvm-dev] [RFC] [Windows SEH] Local_Unwind (Jumping out of a _finally) and -EHa (Hardware Exception Handling)<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">Resending; I accidentally dropped llvm-dev.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">-Eli<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:1.0in"><b>From:</b> Eli Friedman <br>
<b>Sent:</b> Wednesday, April 1, 2020 1:01 PM<br>
<b>To:</b> Ten Tzen <<a href="mailto:tentzen@microsoft.com">tentzen@microsoft.com</a>><br>
<b>Cc:</b> <a href="mailto:aaron.smith@microsoft.com">aaron.smith@microsoft.com</a><br>
<b>Subject:</b> RE: [EXT] [llvm-dev] [RFC] [Windows SEH] Local_Unwind (Jumping out of a _finally) and -EHa (Hardware Exception Handling)<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:1.0in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:1.0in">This looks like it outlines the implementation pretty well.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:1.0in">For goto in finally, why are you inventing a completely new mechanism for handling this sort of construct? What makes this different from our existing handling of goto out of catch blocks? Maybe there’s something
obvious here I’m missing, but it looks like essentially the same problem, and I don’t see any reason why we can’t use the existing solution.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:1.0in">For hardware exceptions, the proposal seems to have big fundamental problems. I see two basic problems:<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:1.0in">How do you actually generate an exception? In general, UB means the program can do anything. So unless you define some rule that says otherwise, the only defined way to trigger an exception is using Windows API
calls. If you want something else, we need to define new rules. At the C level, we need to redefine some specific constructs to trigger an exception instead of UB. And at the IR level, we need to annotate specific IR instructions in a way that passes can
reasonably check, and add new LangRef rules describing those semantics. I mean, you can try to sort of hand-wave this and say it should “just work” if code happens to trigger a hardware exception. But if there aren’t actually any rules, I’m afraid we’ll
end up with an infinitely long tail of “optimization X breaks some customer’s code, so add a hack to disable it in EHa mode”.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:1.0in">If we’re not modeling the control flow implied by an exception, how do we ensure that local variables and SSA registers have the right values when the exception is caught? Sure, invoke is clunky, but it’s at least
makes control flow well-defined. Adding “volatile” to every IR load and store instruction, including accesses to local variables, seems terrible for both optimization and correctness. Our handling of setjmp is already a complete mess; I don’t want to add
another way for unmodeled control flow to break code. (See also <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnondot.org%2Fsabre%2FLLVMNotes%2FExceptionHandlingChanges.txt&data=02%7C01%7Ctentzen%40microsoft.com%7C236f7648ead248c3a15b08d7d69e7980%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637213848450415103&sdata=XQAyvsAhp%2BnRAwq%2F2wYz9S9prC8fs0yWVzgy0RvHlpw%3D&reserved=0">
http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt</a>, for a proposal to make invoke less messy.)<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:1.0in">-Eli <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.0in"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:1.5in"><b>From:</b> llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org">llvm-dev-bounces@lists.llvm.org</a>>
<b>On Behalf Of </b>Ten Tzen via llvm-dev<br>
<b>Sent:</b> Tuesday, March 31, 2020 9:13 PM<br>
<b>To:</b> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<b>Cc:</b> <a href="mailto:aaron.smith@microsoft.com">aaron.smith@microsoft.com</a><br>
<b>Subject:</b> [EXT] [llvm-dev] [RFC] [Windows SEH] Local_Unwind (Jumping out of a _finally) and -EHa (Hardware Exception Handling)<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:1.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:1.5in">Hi, all,<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:1.5in">The intend of this thread is to complete the support for Windows SEH.
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.5in">Currently there are two major missing features: Jumping out of a _finally and Hardware exception handling. <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:1.5in">The document below is my proposed design and implementation to fully support SEH on LLVM.
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.5in">I have completely implemented this design on a branch in repo: <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftentzen%2Fllvm-project&data=02%7C01%7Ctentzen%40microsoft.com%7C236f7648ead248c3a15b08d7d69e7980%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637213848450415103&sdata=S6bNeVNMvvSIi3W3Fv%2F0U5PfRP39fEhUzED%2Fw%2F3fSdM%3D&reserved=0">https://github.com/tentzen/llvm-project</a>.
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.5in">It now passes MSVC’s in-house SEH suite.
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:1.5in">Sorry for this long write-up. For better readability, please read it on
<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftentzen%2Fllvm-project%2Fwiki&data=02%7C01%7Ctentzen%40microsoft.com%7C236f7648ead248c3a15b08d7d69e7980%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637213848450425058&sdata=5dLPotLop8R2DZRpJmoglae0%2FdCT3b9fjJonr8uV8TA%3D&reserved=0">
https://github.com/tentzen/llvm-project/wiki</a><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:1.5in">Special thanks to Joseph Tremoulet for his earlier comments and suggestions.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:1.5in">Note: I just subscribed llvm-dev, probably not in the list yet. So please reply with my email address (<a href="mailto:tentzen@microsoft.com">tentzen@microsoft.com</a>) explicitly in To-list. <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.5in">Thanks,<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:1.5in">--Ten<span lang="EN" style="font-size:12.0pt;font-family:"Segoe UI",sans-serif;color:#24292E"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.5in"><span lang="EN"><o:p> </o:p></span></p>
</div>
</body>
</html>