<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 5, 2014 at 3:06 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> It's a weird<br>
> rule, but it's intended to support the use case of stack slot<br>
> colouring, where your starts and ends are paired and tightly wrap<br>
> the point where the variable is live.<br>
<br>
</span>Yes.<br>
<span class=""><br>
><br>
> If you remove that oddity, lifetime.start and lifetime.end become<br>
> semantically equivalent and both just mean "store undef there" and<br>
> become straight-forward to reason about, though harder to use for<br>
> stack slot colouring (it becomes a bidirectional data flow problem,<br>
> which is hard on compile time). At this stage, I think the tradeoff<br>
> is worthwhile.<br>
<br>
</span>I'm unsure, but could easily agree.</blockquote></div><br></div><div class="gmail_extra">I also think I agree that this is the right semantic model.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div></div>