<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 1, 2016 at 1:39 PM, Akira Hatanaka <span dir="ltr"><<a href="mailto:ahatanak@gmail.com" target="_blank">ahatanak@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">I'd like to get a quick feedback on the lifetime.end metadata kind I'm considering using. I'm planning to use it in cases where lifetime.end intrinsics do not give lifetime bounds that are tight enough.<div><br></div><div>As an example of when lifetime.end cannot provide a tight lifetime bound, consider the following program:</div><div><br></div><span>void </span>test111(int n) {<br><span>  </span><span>if</span><span> (n < </span><span>10</span><span>) {</span><br><span>    string    str = </span><span>"One"</span><span>;</span><br>    cout << str;<br><span>  } </span><span>else</span><span> </span><span>if</span><span> (n < </span><span>100</span><span>) {</span><br><span>    string    str = </span><span>"Two"</span><span>;</span><br>    cout << str;<br><span>  } </span><span>else</span><span> </span><span>if</span><span> (n < </span><span>1000</span><span>) </span><span>{</span><br><span>    string    str = </span><span>"Three"</span><span>;</span><br>    cout << str;<br><span>  </span><span>}</span><div>}</div><div><br></div><div>In the program, the three local variables "str" have lifetimes that do not overlap with each other, so it should be possible to use the same stack slot for all of them to save stack space. However, clang/llvm currently allocates separate slots for each of the three variables because clang doesn't insert lifetime.end markers after the objects are destructed (for example, the destructor of the first string is called in block "lpad" in line 71 of the attached bitcode f1.ll, but there is no lifetime.end marker inserted).</div><div><br></div><div>If we want to insert the missing lifetime.end markers for the strings, we'll have to insert them at the beginning of lpad's successors, %eh.resume and %terminate.lpad, because the destructor call in lpad is an invoke instruction. However, if we insert the lifetime.end markers for all of them, the lifetimes of the strings will overlap clang generates only one resume block and one terminate block per function.</div><div><br></div></div></blockquote><div><br></div><div>This is what I was trying to say:</div><div><br></div><div>"However, if we insert the lifetime.end markers for all of them, the lifetimes of the strings will overlap since clang generates only one resume block and one terminate block per function."</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div></div><div>To get tighter bounds for the strings' lifetimes, I'm considering attaching lifetime.end metadata to the destructor calls in clang:</div><div><br></div><div>invoke void @foo("basic_string"* %str) to label %eh.resume unwind label %terminate.lpad, !lifetime_end !10</div><div><br></div><div>!10 = !{i32 0}</div><div><br></div><div>SelectionDAGBuilder will then insert a lifetime.end node if there is a lifetime.end attached to an invoke instruction.</div><div><br></div><div>Does this sound like a reasonable approach? Or are there better ways to tell the backend that the lifetimes do not overlap?</div></div>
</blockquote></div><br></div></div>