<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:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@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:Consolas;
panose-1:2 11 6 9 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;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#993366;}
span.EmailStyle21
{mso-style-type:personal-compose;
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;}
--></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:#993366">Another idea: since we have llvm::Functions for the personality functions, maybe we could make them more self-describing via attributes? We'd have to come up
with the set of relevant properties that characterize personality functions (the predicates in Analysis/EHPersonalities would be a start, but we'd also have to look at other places testing/switching on the enum), and for each define an attribute that a front-end
could either attach to the personality Function or not to indicate whether that property applies, and we could get rid of the string matching and hard-coded enum. I don't see any need to stop and do that now, but it might be a reasonable long-term plan if
we ever start seeing loads of personalities for some reason.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#993366"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#993366">Thanks<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#993366">-Joseph<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#993366"><o:p> </o:p></span></a></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<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"> Joseph Tremoulet
<br>
<b>Sent:</b> Tuesday, December 8, 2015 1:27 PM<br>
<b>To:</b> 'Chen Li' <meloli87@gmail.com><br>
<b>Subject:</b> RE: Support token type in struct for landingpad<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Yes, that sounds reasonable to me, thanks.<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>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<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"> Chen Li [<a href="mailto:meloli87@gmail.com">mailto:meloli87@gmail.com</a>]
<br>
<b>Sent:</b> Monday, December 7, 2015 3:21 PM<br>
<b>To:</b> Joseph Tremoulet <<a href="mailto:jotrem@microsoft.com">jotrem@microsoft.com</a>><br>
<b>Cc:</b> David Majnemer <<a href="mailto:david.majnemer@gmail.com">david.majnemer@gmail.com</a>>; Igor Laevsky <<a href="mailto:igor@azulsystems.com">igor@azulsystems.com</a>>; llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>;
John McCall <<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>><br>
<b>Subject:</b> Re: Support token type in struct for landingpad<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Dec 5, 2015, at 5:58 PM, Joseph Tremoulet <<a href="mailto:jotrem@microsoft.com">jotrem@microsoft.com</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">It seems a little backwards to me to check the landingpad's type as the first check, since the personality dictates the landingpad's type. That said, yes I see
how #4 is expedient in allowing personalities using the two main types to lump themselves into EHPersonality::Unknown.</span><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>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">As for supporting selector and exception pointer extraction for landingpad of token type, I think you'll want to look at the handling of the @llvm.eh.exceptionpointer
intrinsic that's used with catchpads and basically do the same thing with landingpads.</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I see your point. I think I will take #2 as the first step. I will add a new EHPersonality enum (maybe called Token_LP) which returns NoRegister for
<span style="font-size:8.0pt;font-family:Consolas;background:white">TLI.getExceptionPointerRegister </span>and <span style="font-size:8.0pt;font-family:Consolas;background:white">TLI.getExceptionSelectorRegister</span>. Ideally I think EHPersonality::Unknown
is a better candidate to do this (as you suggested #3), but I don’t want this to be disruptive to other’s codebase. Maybe later we could modify EHPersonality::Unknown and merge this into it. I will create a patch for it and have you review it if this sounds
reasonable to you.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">chen <o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Thanks</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">-Joseph</span><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>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span><o:p></o:p></p>
</div>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<div>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span class="apple-converted-space"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Chen
Li [<a href="mailto:meloli87@gmail.com">mailto:meloli87@gmail.com</a>]<span class="apple-converted-space"> </span><br>
<b>Sent:</b><span class="apple-converted-space"> </span>Saturday, December 5, 2015 12:34 AM<br>
<b>To:</b><span class="apple-converted-space"> </span>Joseph Tremoulet <<a href="mailto:jotrem@microsoft.com">jotrem@microsoft.com</a>><br>
<b>Cc:</b><span class="apple-converted-space"> </span>David Majnemer <<a href="mailto:david.majnemer@gmail.com">david.majnemer@gmail.com</a>>; Igor Laevsky <<a href="mailto:igor@azulsystems.com">igor@azulsystems.com</a>>; llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>;
John McCall <<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>><br>
<b>Subject:</b><span class="apple-converted-space"> </span>Re: Support token type in struct for landingpad</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">On Dec 4, 2015, at 1:27 PM, Joseph Tremoulet <<a href="mailto:jotrem@microsoft.com"><span style="color:purple">jotrem@microsoft.com</span></a>> wrote:<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">><span class="apple-converted-space"> </span></span>I dont have a concrete design right now and I am happy to take any other ideas<o:p></o:p></p>
</div>
</div>
<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>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Three ideas come to mind, none of which are perfect:</span><o:p></o:p></p>
</div>
</div>
<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>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">1) I'm tempted to say that now that we have token type, landingpad should generally produce a token, the pointer should be extracted with the @llvm.eh.exceptionpointer
intrinsic instead of an extractvalue, and the selector should likewise be extracted with a new @llvm.eh.exceptionselector intrinsic instead of extractvalue (and personalities that communicate other things via their landingpads would need to add similar intrinsics
to extract them, like the @llvm.eh.exceptioncode intrinsic that SEH uses). But that would require updating all the front-ends generating landingpads, and be awkward for any target personality routines that literally do pass a struct to the landing pad (are
there any?), and so probably just reflects my bias coming from dealing with a personality using catchpads/cleanuppads instead of landingpads.</span><o:p></o:p></p>
</div>
</div>
<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>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">2) Since you're not actually using the landingpad's exception selector nor, if I understand "</span><span class="apple-converted-space"> </span>This is enough
to support the gc.statepoint work<span class="apple-converted-space"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">" correctly, its
exception pointer, it's possible that<span class="apple-converted-space"> </span></span><span style="font-size:8.0pt;font-family:Consolas;background:white">TLI.getExceptionPointerRegister</span><span class="apple-converted-space"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">and<span class="apple-converted-space"> </span></span><span style="font-size:8.0pt;font-family:Consolas;background:white">TLI.getExceptionSelectorRegister</span><span class="apple-converted-space"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">should
be returning<span class="apple-converted-space"> </span></span><span style="font-size:8.0pt;font-family:Consolas;background:white">NoRegister</span><span class="apple-converted-space"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">for
your personality. That would require modifying the EHPersonality enum and corresponding string matching in Analysis/EHPersonalities.h to recognize your personality, but I think that would be fine (it highlights a potential scaling issue if we add lots of
targets that each need this, but that's a somewhat independent and pre-existing issue, and in reality I doubt you'd be opening a floodgate here).</span><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Yes, we don’t neither the exception selector nor the exception pointer. I’ve taken a similar approach as #2 you suggested, but instead of modifying the personality, I directly add a check in visitLandingPad to see if landingpad is token
type. If so, don’t create DAG node for selector and exception pointer even if <span style="font-size:8.0pt;font-family:Consolas;background:white">TLI.getExceptionPointerRegister </span>and <span style="font-size:8.0pt;font-family:Consolas;background:white">TLI.getExceptionSelectorRegister </span>are
not zero or <span style="font-size:8.0pt;font-family:Consolas;background:white">NoRegister</span>. I think this works correctly and I’ve passed all the tests I have. I plan to check this in as the first step, but I’d like to actually support selector and exception
pointer extraction for landingpad of token type. Personally I like #1 you suggested, but I am also afraid that requires updating all front-ends generating landingpads. I think #4 might be the most practical approach that I could think of.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">thanks,<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">chen<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<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>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">3) Maybe the default should be switched, so that<span class="apple-converted-space"> </span></span><span style="font-size:8.0pt;font-family:Consolas;background:white">TLI.getExceptionPointerRegister</span><span class="apple-converted-space"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">and<span class="apple-converted-space"> </span></span><span style="font-size:8.0pt;font-family:Consolas;background:white">TLI.getExceptionSelectorRegister</span><span class="apple-converted-space"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">return</span><span style="font-size:8.0pt;font-family:Consolas;background:white">NoRegister</span><span class="apple-converted-space"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"> </span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">for
EHPersonality::Unknown, and only return actual registers for personalities they recognized. This would require any targets using landingpads with exception pointers / exception selectors to update their code and add themselves to Analysis/EHPersonalities.h,
similar to how #2 would require adding your personality, so it seems more disruptive if conceptually a touch cleaner than #2.</span><o:p></o:p></p>
</div>
</div>
<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>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">4) Explicitly checking for token type in visitLandingPad as you suggest sounds okay to me as a pragmatic approach, too.</span><o:p></o:p></p>
</div>
</div>
<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>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I'd probably lean toward #2 as being the least disruptive and most explicit/straightforward about the personality's expectations, but I'm curious what others
think.</span><o:p></o:p></p>
</div>
</div>
<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>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Thanks</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">-Joseph</span><o:p></o:p></p>
</div>
</div>
<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>
</div>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span class="apple-converted-space"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></span><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Chen
Li [<a href="mailto:meloli87@gmail.com"><span style="color:purple">mailto:meloli87@gmail.com</span></a>]<span class="apple-converted-space"> </span><br>
<b>Sent:</b><span class="apple-converted-space"> </span>Thursday, December 3, 2015 4:06 PM<br>
<b>To:</b><span class="apple-converted-space"> </span>David Majnemer <<a href="mailto:david.majnemer@gmail.com"><span style="color:purple">david.majnemer@gmail.com</span></a>><br>
<b>Cc:</b><span class="apple-converted-space"> </span>Igor Laevsky <<a href="mailto:igor@azulsystems.com"><span style="color:purple">igor@azulsystems.com</span></a>>; llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org"><span style="color:purple">llvm-dev@lists.llvm.org</span></a>>;
Joseph Tremoulet <<a href="mailto:jotrem@microsoft.com"><span style="color:purple">jotrem@microsoft.com</span></a>><br>
<b>Subject:</b><span class="apple-converted-space"> </span>Re: Support token type in struct for landingpad</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">Hi David and Joseph,<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">I’ve just added landingpad with token type locally and changed gc.relocate to work in the following way:<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> %0 = invoke token (i64, i32, void (i64 addrspace(1)*)*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_isVoidp1i64f(i64 0, i32 0, void (i64 addrspace(1)*)* @some_call, i32 1, i32 0, i64 addrspace(1)* %obj, i32 0, i32 5, i32 0, i32
-1, i32 0, i32 0, i32 0, i64 addrspace(1)* %obj, i64 addrspace(1)* %obj1)<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> to label %invoke_safepoint_normal_dest unwind label %exceptional_return<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">invoke_safepoint_normal_dest:<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> ...<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">exceptional_return:<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> %landing_pad = landingpad token<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> cleanup<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> %obj.relocated1 = call coldcc i64 addrspace(1)* @llvm.experimental.gc.relocate.p1i64(token %landing_pad, i32 13, i32 13)<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> %obj1.relocated1 = call coldcc i64 addrspace(1)* @llvm.experimental.gc.relocate.p1i64(token %landing_pad, i32 14, i32 14)<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> ret i64 addrspace(1)* %obj1.relocated1<o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">Now gc.statepoint return a token type instead of i32 type, and gc.relocate also takes a token type as its first argument (the first argument should either be the corresponding gc.statepoint for call statepoint or invoke statepoint on the
normal path, or a reference that could help find the corresponding gc.statepoint on the unwind the path). And since landingpad produces a token type here as well, it can be passed as the reference to the gc.relocate’s first argument. <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">To make this work, I have changed two parts of the code. First is how gc.relocate looks up for its corresponding gc.statepoint on the unwind path. It used to use the extracted selector value to find the landingpad and then use the landingpad
to find the invoke instruction, which is the gc.statepoint. Now, it can use the landingpad directly to find the invoke instruction. The second part is to make landingpad work with token type. In LLVM’s front end (passes before SelectionDAG), there is no restrictions
on what type a landingpad should have (there are test cases in LLVM that has landingpad of i8 or i32 type). However, in SelectionDAGBuilder::visitLandingPad, it is enforced that landingpad must be two-valued (type of { i8*, i32 }), in which way it can handle
the exception pointer and selector value inside it. As the first step, I’d like to just add a check to see if the landingpad is of token type, and if so stop it and don’t bother to create the DAG nodes for the exception pointer and selector value (same as
what happens during SjLj exceptions). This is enough to support the gc.statepoint work but will not support for C++ style exception handling with gc.statepoint. As for follow-up work, I’d like to add some support to extract selector value from token landingpad.
I think we could either do it explicitly in IR (maybe add a intrinsic call extract.selector or something similar) or implicitly during SelectionDAG (in visitLandingPad, check if it’s token type, and if so add an additional transform to extract the exception
pointer and selector value from the token). I dont have a concrete design right now and I am happy to take any other ideas. My plan is to get the first step checked in and incrementally work on the follow-up work. Does that sound a reasonable approach to you
guys? <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">thanks,<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">chen <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal">On Dec 2, 2015, at 9:47 AM, Chen Li <<a href="mailto:meloli87@gmail.com"><span style="color:purple">meloli87@gmail.com</span></a>> wrote:<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
On Dec 1, 2015, at 11:14 PM, David Majnemer <<a href="mailto:david.majnemer@gmail.com"><span style="color:purple">david.majnemer@gmail.com</span></a>> wrote:</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">While we support 'opaque' types nested within struct types, they are not exactly battle tested:</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">$ cat t.ll</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">%opaque_ty = type opaque</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">%struct_ty = type { i32, %opaque_ty }</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">define %struct_ty @f(%struct_ty* %p) {</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> %load = load %struct_ty, %struct_ty* %p</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> ret %struct_ty %load</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">}</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">$ opt -O2 t.ll -S</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">lib/IR/DataLayout.cpp:623: unsigned int llvm::DataLayout::getAlignment(llvm::Type *, bool) const: Assertion `Ty->isSized() && "Cannot getTypeInfo() on a type that is unsized!"'
failed.</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Thanks David! I’ve actually hacked to add token type into struct type and ended up with the same failure as above. I will take a look at the catchpad and cleanuppad code,
and create a patch to add token landingpad and have you review it.</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">thanks,</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">chen</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">As a practical matter, I fear nesting 'token' types within struct types will have similar issues. Beyond that, the design philosophy behind 'token' is that it is incredibly
opaque and permitting it to nest inside a struct creates scenarios where one might try to GEP to the end of the field right before the token field in an attempt to examine or manipulate the token.</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Your other recommendation, having landingpad produce a token, is quite similar to how we've designed catchpad and cleanuppad. I think that direction will be quite nice.</span><o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">On Tue, Dec 1, 2015 at 8:07 PM, Chen Li<span class="apple-converted-space"> </span><<a href="mailto:meloli87@gmail.com" target="_blank"><span style="color:purple">meloli87@gmail.com</span></a>><span class="apple-converted-space"> </span>wrote:</span><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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Hi David,<br>
<br>
Sorry to bother you, but I would like to get some suggestions on your recent work of token type.<br>
<br>
I’m currently working on changing gc.statepoint to return a token type instead of a i32 type. The reason is that with the current implementation, gc.statepoint could potentially be fed into PHI nodes, and break RewriteStatepointsForGC pass later. Using token
type would help us to avoid this. I have most of the code work but got a problem when gc.statepint is an InvokeInst and has an unwind path.<br>
<br>
Currently, gc.statepoint of InvokeInst works as below (the code snippet is from test/CodeGen/X86/statepoint-invoke.ll):<br>
<br>
%0 = invoke i32 (i64, i32, void (i64 addrspace(1)*)*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_isVoidp1i64f(i64 0, i32 0, void (i64 addrspace(1)*)* @some_call, i32 1, i32 0, i64 addrspace(1)* %obj, i32 0, i32 5, i32 0, i32 -1, i32 0, i32 0, i32
0, i64 addrspace(1)* %obj, i64 addrspace(1)* %obj1)<br>
to label %invoke_safepoint_normal_dest unwind label %exceptional_return<br>
<br>
invoke_safepoint_normal_dest:<br>
…<br>
<br>
exceptional_return:<br>
%landing_pad = landingpad { i8*, i32 }<br>
cleanup<br>
%relocate_token = extractvalue { i8*, i32 } %landing_pad, 1<br>
%obj.relocated1 = call coldcc i64 addrspace(1)* @llvm.experimental.gc.relocate.p1i64(i32 % relocate_token, i32 13, i32 13)<br>
%obj1.relocated1 = call coldcc i64 addrspace(1)* @llvm.experimental.gc.relocate.p1i64(i32 % relocate_token, i32 14, i32 14)<br>
ret i64 addrspace(1)* %obj1.relocated1<br>
<br>
<br>
Each gc.relocate needs to take its corresponding gc.statepoint as its first argument. However, on the unwind path, there is no way to get gc.statepoint directly because the return value of the InvokeInst is undefined there. In this scenario, we tie gc.relocate
to the landingpad, and use the landingpad to find its unique predecessor to get the corresponding gc.statepoint. We pick the selector value from the landingpad to feed into gc.relocate just because it has the same type (i32) as gc.statepoint's return type.
The actual value of the selector doesn’t really matter because gc.relocate only uses it as a reference to find gc.statepoint and not consume it during lowering.<br>
<br>
However, this will no longer work if we change gc.statepoint's return type to token type. To make it work, I could see two potential approaches. 1) add support of token type inside struct type so that we can have a landingpad with result type of { i8*, token
}, or 2) add support of landingpad with a token result type. Approach 1 seems to be easier since all the other parts of statepoint handling does not need to be changed at all, and having a selector of token type also seems reasonable (furthermore, we don’t
ever need to extract selector value to do exception handling in our code base so I think only supporting token type in struct should be enough for us). Approach 2 requires to modify the way how gc.relocate looks up for its corresponding gc.statepoint through
landingpad, but shouldn’t be hard either.<br>
<br>
Does either of the approaches sound reasonable to you? Other ideas are also welcomed :)<br>
<br>
Thank you very much!<br>
<br>
Best,<br>
Chen </span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>