<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 1, 2016 at 10:12 AM, Xinliang David Li <span dir="ltr"><<a href="mailto:xinliangli@gmail.com" target="_blank">xinliangli@gmail.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"><br><div class="gmail_quote"><span class="">On Mon, Aug 1, 2016 at 8:58 AM, Daniel Berlin via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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">The existing lifetime start/end is not very well defined (by spec, or by code) in what it means, so you could have nested lifetime markers if you wanted.   If you made the spec well-defined, they would be meaningful (for loops, etc).</div><div class="gmail_extra"><br></div><div class="gmail_extra">There are a number of open bugs/complaints about lifetime markers and the fact that the scope is not well defined (the spec says "This intrinsic indicates that before this point in the code, the value of the memory pointed to by <code style="font-family:consolas,"deja vu sans mono","bitstream vera sans mono",monospace;font-size:0.95em"><span>ptr</span></code> is dead. This means that it is known to never be used and has an undefined value. A load from the pointer that precedes this intrinsic can be replaced with <code style="font-family:consolas,"deja vu sans mono","bitstream vera sans mono",monospace;font-size:0.95em"><span>'undef'</span></code>.)</div><div class="gmail_extra"><br></div><div class="gmail_extra">"Before" is not a well-defined term :)  (the end code says after, which has similar problems) </div><div class="gmail_extra"><br></div><div class="gmail_extra">Trivial case: </div><div class="gmail_extra"><br></div><div class="gmail_extra">Two block loop consists, lifetime maker at beginning</div><div class="gmail_extra"><br></div><div class="gmail_extra">A </div><div class="gmail_extra">|  ^</div><div class="gmail_extra">|    \  </div><div class="gmail_extra">|    |</div><div class="gmail_extra">|   |</div><div class="gmail_extra">v /</div><div class="gmail_extra">B</div><div class="gmail_extra"><br></div><div class="gmail_extra">Lifetime marker is at top of A.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Is B before A? (if not, are we using dominates as the definition of "before", because B is a predecessor of A)</div><div class="gmail_extra">Does the answer change if i put a jump to B somewhere above A?</div><div class="gmail_extra">If we use dominates, and i put a jump there, i can make A and B dominator tree siblings.  Is the pointer now invalid? :)</div><div class="gmail_extra"><br></div><div class="gmail_extra">etc</div><div class="gmail_extra"><br></div><div class="gmail_extra">I suspect what is really wanted is "i want lifetime markers to specify that this thing has single-iteration scope, function scope, or SESE/SEME region scope"  (or something).</div></div></blockquote><div><br></div><div><br></div></span><div>Also having lifetime.start marker seems unnecessary and it makes live range analysis less precise actually.  One local var can have one single end marker and multiple implicit start markers (first uses). </div></div></div></div></blockquote><div><br></div><div>The original goal, AFAIK, of lifetime start/end was to say "the frontend put the alloca/etc here, but that's not really where the lifetime starts, so please ignore anything between the thing you think is the start and the real start".</div><div><br></div><div>Extend this to structures, where parts of a structure may get used but other parts still dead for a while.</div><div> <br></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"><div>The end marker should post-dominate all uses. Having one start marker is like defining a least common dominator for all the implicit starts which make the resulting live range strictly 'larger' than necessary.</div></div></div></div></blockquote><div><br></div><div>Yes, it is possible to track and compute more precise ranges than the lifetime start markers give you, *assuming* the actual placement of variables in the IR is accurate to the original block scope (IE nothing generates uninitialized loads to start), and you compute the ranges before anything messes that up (IE moves the uses up) :).<br></div><div><br></div><div>Right now, i believe the lifetime start markers are what block things from moving those loads up, because they just get deleted as undefined :)</div><div><br></div><div>In any case, i think this is going to derail chandler's question if we continue on this thread and not a new one :)</div><div><br></div><div>--Dan </div><div><br></div></div></div></div>