[llvm-dev] [RFC] lifetime.end metadata

[Reid Kleckner via llvm-dev]

On Tue, Mar 1, 2016 at 1:39 PM, Akira Hatanaka via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
> 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.
>

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.


>
> To get tighter bounds for the strings' lifetimes, I'm considering
> attaching lifetime.end metadata to the destructor calls in clang:
>
> invoke void @foo("basic_string"* %str) to label %eh.resume unwind label
> %terminate.lpad, !lifetime_end !10
>
> !10 = !{i32 0}
>
> SelectionDAGBuilder will then insert a lifetime.end node if there is a
> lifetime.end attached to an invoke instruction.
>
> Does this sound like a reasonable approach? Or are there better ways to
> tell the backend that the lifetimes do not overlap?
>

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?

LLVM CFG soup makes this stuff kind of awkward. :(
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160301/3fce6b2f/attachment.html>