<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;}
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">Does this plan prevent the allocas used for the formal argument of multiple exception handlers from being coalesced into a single stack location when possible?<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">This definitely seems like an improvement, and the amount of code that drops away from WinEHPrepare because of this change is definitely a good sign.<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"><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""> llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu]
<b>On Behalf Of </b>Chandler Carruth<br>
<b>Sent:</b> Wednesday, March 04, 2015 12:56 AM<br>
<b>To:</b> John McCall<br>
<b>Cc:</b> LLVM Developers Mailing List<br>
<b>Subject:</b> Re: [LLVMdev] RFC: Better alternative to llvm.frameallocate for use in Windows EH<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, Mar 4, 2015 at 12:36 AM, John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">> On Mar 3, 2015, at 2:25 PM, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>
><br>
> I realized that WinEH preparation can probably be a lot less invasive than it is currently.<br>
><br>
> Initially, when I was thinking about recovering the address of an object in a parent stack frame, I thought about it in terms of "let's allocate something at a fixed offset from ebp to keep things simple". That line of thinking suggested that we needed this
thing to be fundamentally different from a normal alloca. I was going to make sure it was allocated early in the prologue, for example.<br>
><br>
> However, this never happened, and having a fixed offset isn't very simple. I ended up ditching the fixed offset and using assembly label assignments to communicate frame index offsets between parent functions and outlined subfunctions. This technique easily
generalizes to support referencing an arbitrary number of allocations in the parent frame, and I think we should go ahead and do that.<br>
><br>
> The current approach has downsides that we take a bunch of vanilla allocas and SSA values in the parent function and mash them into a single allocation, and replace the accesses with GEPs of an intrinsic result. This is a lot of funky looking IR for something
that should be really simple. We also already have good isel for accessing allocas, and we lose that when we switch to an intrinsic.<br>
><br>
> So instead, let's go back to using normal allocas and "blessing" each of them as escaped allocations that can be referenced from EH helpers. Here's what it would look like:<br>
><br>
> define i32 @parent() {<br>
> %a = alloca i32<br>
> %b = alloca i32<br>
> call void (...)* @llvm.frameescape(i32* %a, i32* %b)<br>
> %fp = call i8* @llvm.frameaddress(i32 0)<br>
> call void @helper_func(i8* %fp)<br>
> %a_val = load i32, i32* %a<br>
> %b_val = load i32, i32* %b<br>
> %r = add i32 %a_val, %b_val<br>
> ret i32 %r<br>
> }<br>
><br>
> define void @helper_func(i8* %fp) {<br>
> %a.i8 = call i8* @llvm.framerecover(i8* bitcast (i32 ()* @parent to i8*), i8* %fp, i32 0)<br>
> %b.i8 = call i8* @llvm.framerecover(i8* bitcast (i32 ()* @parent to i8*), i8* %fp, i32 1)<br>
> %a = bitcast i8* %a.i8 to i32*<br>
> %b = bitcast i8* %b.i8 to i32*<br>
> store i32 1, i32* %a<br>
> store i32 2, i32* %b<br>
> ret void<br>
> }<br>
><br>
> declare i8* @llvm.frameaddress(i32)<br>
> declare i8* @llvm.framerecover(i8*, i8*, i32)<br>
> declare void @llvm.frameescape(...)<br>
><br>
> In this example, 'helper_func' is able to access the frame of 'parent'. 'parent' should return 3.<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">This seems like a nice IR.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Completely agree. This is much better than our original idea. I really like just packing the escaped bits into various arguments of the intrinsic call without rearranging anything.<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">
<p class="MsoNormal"> This would only actually be formed very late during codegen preparation, right? It’ll kill data-flow optimizations, but if it’s only introduced late, that doesn’t matter.<o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">That is my understanding.<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>