<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Mar 1, 2016 at 2:52 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Tue, Mar 1, 2016 at 1:39 PM, Akira Hatanaka via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<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>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></blockquote><div><br></div></span><div>In C++11, destructors are noexcept by default, so I'm not sure this really matters that much going forward. You can still declare your destructor noexcept(false), in which case, maybe we don't care as much about optimizing your stack slot usage.</div><span><div> </div></span></div></div></div></blockquote><div><br></div><div>Ah, that's a good point. I still have to investigate whether the code is or can be compiled with -std=c++11, but if that is the case, lifetime.end metadata won't be needed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><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><br></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></span></div><br></div><div class="gmail_extra">I think there are issues with this proposal. How does this approach interact with IPO like inlining? Would we insert lifetime.end in the inliner? What if we delete the dtor because it has no side effects, do we lose the lifetime info?</div><div class="gmail_extra"><br></div><div class="gmail_extra">LLVM CFG soup makes this stuff kind of awkward. :(<br></div></div>
</blockquote></div><br></div><div class="gmail_extra">I think we would have to make changes to insert a lifetime.end marker when the destructor function is inlined or is deleted. In the worst case, if the call to the destructor is deleted and a marker isn't inserted, the StackColoring will not be able to merge the stack slots but will still generate functionally correct code.</div></div>