<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";}
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";
mso-fareast-language:EN-US;}
@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 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><p class=MsoNormal style='margin-left:36.0pt'><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Reid Kleckner [mailto:rnk@google.com] <br><b>Sent:</b> 05 November 2014 22:49<br><b>To:</b> Philip Reames<br><b>Cc:</b> Arnaud De Grandmaison; LLVM Developers Mailing List<br><b>Subject:</b> Re: [LLVMdev] lifetime.start/end clarification<o:p></o:p></span></p><p class=MsoNormal style='margin-left:36.0pt'><o:p> </o:p></p><div><div><div><p class=MsoNormal style='margin-left:36.0pt'>On Wed, Nov 5, 2014 at 11:17 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'><o:p> </o:p></p><div><p class=MsoNormal style='margin-left:36.0pt'>On 11/05/2014 10:54 AM, Reid Kleckner wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><div><p class=MsoNormal style='margin-left:36.0pt'>This seems fine to me. The optimizer can (soundly) conclude that %p is dead after the "lifetime.end" (for the two instructions), and dead before the "lifetime.start" (for the *single* instruction in that basic block, *not* for the previous BB). This seems like the proper result for this example, am I missing something?<o:p></o:p></p></div></blockquote><div><p class=MsoNormal style='margin-left:36.0pt'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'>What if I put that in a loop, unroll it once, and prove that the lifetime.start is unreachable? We would end up with IR like:<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'>loop:<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'> ... use %p<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'> call void @lifetime.end( %p )<o:p></o:p></p></div><div><div><p class=MsoNormal style='margin-left:36.0pt'> ... use %p<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'> call void @lifetime.end( %p )<o:p></o:p></p></div></div><div><p class=MsoNormal style='margin-left:36.0pt'> br i1 %c, label %loop, label %exit<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'>Are the second uses of %p uses of dead memory?<o:p></o:p></p></div></div></div></div></blockquote><p class=MsoNormal style='margin-left:36.0pt'>It's hard to discuss this without being specific about the starting IR and transforms. My general response is that either a) such a transform wouldn't be valid or b) the behaviour of the original program was undefined. <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 starting IR would be something that jumps into the middle of a lifetime region, like the example that Arnaud gave. This was assuming the current state of the world where we haven't added a second lifetime start call prior to the goto branch.<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'>Start with something like:<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'>void f(int x) {<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'> while (x) {<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'> goto skip_start;<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'> int y; // lifetime.start<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'>skip_start:<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'> y = g();<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'> x -= y;<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'> // lifetime.end<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:36.0pt'> }<br> }<br>}<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 block containing the lifetime start of y is unreachable and can be deleted.<o:p></o:p></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'>On this example, I think the critical edge to the skip_start label need to get a lifetime.start inserted (btw, we already insert there a gep to the alloca to solve a dominator issue), and this makes sense because such an edge also contains (in essence) the trivial constructors of the scope where the label is.<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 looks to me as a hint that when they are used with an alloca, lifetime.start/end really have to be paired, and that all possible uses of the alloca should be covered by a [start,end] :<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> - In the above testcase, when the path from lifetime.end is walked-up the cfg, it reaches the alloca, and this is weird.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> - In my testcase, when the paths from lifetime.start and lifetime.end are walked-up the cfg, it becomes inconsistent in the entry block: one path will tell it’s dead, the other it’s alive.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>This puts the burden onto clang to generate consistent marker info, which sounds reasonable after all.<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'>I can probably add some checks to enforce this in llvm, or at least detect such cases: this will definitely help me to spot candidates for the miscompilation I observe, which by the way is not caused by unnamed temporaries, but by standard VarDecl + lifetime markers. I do not know yet where though. It means that we have a lurking bug today in-tree, and changing the size threshold for marker insertion is enough to trigger it.<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'>Cheers,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Arnaud<o:p></o:p></span></p></div></div></div></div></div></body></html>