[LLVMdev] lifetime.start/end clarification

[Chandler Carruth]

On Wed, Nov 5, 2014 at 3:06 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> > It's a weird
> > rule, but it's intended to support the use case of stack slot
> > colouring, where your starts and ends are paired and tightly wrap
> > the point where the variable is live.
>
> Yes.
>
> >
> > If you remove that oddity, lifetime.start and lifetime.end become
> > semantically equivalent and both just mean "store undef there" and
> > become straight-forward to reason about, though harder to use for
> > stack slot colouring (it becomes a bidirectional data flow problem,
> > which is hard on compile time). At this stage, I think the tradeoff
> > is worthwhile.
>
> I'm unsure, but could easily agree.


I also think I agree that this is the right semantic model.

I really do not want to make how we handle lifetime-based optimizations
have anything to do with where the memory comes from. That is a Really Bad
Idea IMO because it couples things that shouldn't be coupled. We could
reasonably want to do stack-to-heap or heap-to-stack changes to allocation
patterns, and those should be totally orthogonal to managing lifetimes.


Also, when we do end up with obviously bracketed regions as expected for
many cases, it should be no harder to detect. We just need to use a
conservatively correct algorithm for matching them up during stack coloring.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141105/17f413f5/attachment.html>