<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:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
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-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
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 bgcolor=white lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='margin-left:36.0pt'><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> Philip Reames [mailto:listmail@philipreames.com] <br><b>Sent:</b> 05 November 2014 19:25<br><b>To:</b> Reid Kleckner<br><b>Cc:</b> Arnaud De Grandmaison; Nick Lewycky; Rafael Ávila de Espíndola; LLVM Developers Mailing List<br><b>Subject:</b> Re: [LLVMdev] lifetime.start/end clarification<o:p></o:p></span></p></div></div><p class=MsoNormal style='margin-left:36.0pt'><o:p> </o:p></p><p class=MsoNormal style='margin-left:36.0pt'><o:p> </o:p></p><div><p class=MsoNormal style='margin-left:36.0pt'>On 11/05/2014 10:10 AM, Reid Kleckner wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal style='margin-left:36.0pt'>On Wed, Nov 5, 2014 at 10:01 AM, Philip Reames <<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal style='margin-left:36.0pt'>Would one of you mind taking a step back and explaining what you believe the "stack colouring problem" to be? I'm familiar with the general meaning of the term and even some of LLVM's implementation; I'm just not sure what specific issue you're referring to. Having the context would make it much easier to assess your proposals. <o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'>The goal of stack coloring is to reduce stack usage by storing user data with non-overlapping lifetimes in the same stack memory.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'>C/C++ source programs usually have a naturally scoped structure, where the lifetime of data is bounded by curly braces. This information reduces the lifetime that stack coloring sees, so it saves stack memory.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'>When we go to LLVM IR, we lose all that information. We currently try to recapture it with calls to @lifetime.start / end intrinsic calls at the point of declaration and when the variable falls out of scope. Basically we're trying to figure out how to put that scoping information back into the IR without turning it back into a tree.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'>Furthermore, if we had better information about this in the IR, we could augment ASan to detect use-after-scope.<o:p></o:p></p></div></div></div></div></blockquote><p class=MsoNormal style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:36.0pt'>Everything you say here is general goodness. What part of this is problematic today? My belief is that the lifetime markers give you exactly the support you need. Where does this break down? Is the analysis too hard? Is Clang getting the semantics wrong? What's the actually blocking issue?<br><br><span style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Here is the actually blocking issue. Today, the lifetime markers are only inserted if the alloca is big enough (32+ bytes). I tried several times to add the lifetime markers for unnamed temporaries; the patches have been reviewed each time by people knowledgeable with this part of clang. But when we remove the size limit for the lifetime marker insertion, we get miscompiles when bootstrapping clang. This is why I was asking for clarification of the specification, as this is a part I found left room for interpretation.<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:12.0pt;margin-left:36.0pt'><br>Philip<o:p></o:p></p></div></body></html>