<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 30, 2017 at 11:42 PM, David Majnemer <span dir="ltr"><<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hmm. This doesn't jive with my understanding of how things worked.<div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> <br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>I see the lifetime intrinsics as something which _can_ be made conditional on arbitrary control flow.</div></div></blockquote><div><br></div><div>That seems very wrong.</div><div>The whole purpose of them was because the middle end *does not know* more than the frontend about the lifetime starting and ending of memory objects</div><div>They were not supposed to float.</div><div>Much like assume, they were meant to be tethered in place.</div><div>Otherwise, they are literally pointless :)</div><div>·IE in such a world, we should not be stopping licm, etc, from moving them, and we should stop letting them block optimization by being marked as side-effecting.</div><div>Whatever happens to them, happens.</div><div><br></div><div>Further, if i can make them conditional on arbitrary control flow, i can cause all the lifetime starts to die, easily, again, something we are specifically marking them as side-effecting to avoid.</div><div><br></div><div>ie </div><div><br></div><div>lifetime.start</div><div>-></div><div>if (dead condition)</div><div> lifetime.start</div><div>-></div><div>nothing</div><div><br></div><div>Now they are all unpaired :)</div><div><br></div><div>So maybe you meant something other than arbitrary control flow?</div><div>I can probably do worse than this depending on how arbitrary you want (IE shove them into loops in ways that more things are dead than were before)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> I can build a consistent view of them because I also believe the lifetime intrinsics can only make sense when they are paired together.</div></div></blockquote><div><br></div><div>That is also not what our langref says.</div><div>It does not require pairing:</div><div>For example, for lifetime start:<br>"This intrinsic indicates that before this point in the code, the value of the memory pointed to by <code class="gmail-docutils gmail-literal" style="font-family:consolas,"deja vu sans mono","bitstream vera sans mono",monospace;font-size:0.95em"><span class="gmail-pre">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 class="gmail-docutils gmail-literal" style="font-family:consolas,"deja vu sans mono","bitstream vera sans mono",monospace;font-size:0.95em"><span class="gmail-pre">'undef'</span></code>."</div><div><br></div><div>Ignoring "before this point in the code" (which is the argument we have in the first paragraph), nothing about this requires it be paired.</div><div><br></div><div>It would be perfectly reasonable in this definition to have lifetime starts without ends, for things that begin life in the middle of the function but extend past it.</div><div>Or to say that after a function call, lifetime of memory object has ended (without it ever starting).</div><div><br></div><div>Now, i don't claim these are *good* semantics, but if we want to change them, we should change them, not just do something different than we document :)</div><div><br></div><div>(in any case, i believe we are rehashing the fact that we all think these intrinsics are in need of some serious rework to clear up semantics, etc)</div><div><br></div><div class="gmail-section" id="gmail-llvm-lifetime-end-intrinsic"><span id="gmail-int-lifeend" style="color:rgb(0,0,0);font-family:"lucida grande","lucida sans unicode",geneva,verdana,sans-serif;font-size:14px"></span></div></div></div></div>