<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">This seems fine to me.  The optimizer can (soundly) conclude that %p
    is dead after the "lifetime.end" (for the two instructions), and
    dead before the "lifetime.start" (for the *single* instruction in
    that basic block, *not* for the previous BB).  This seems like the
    proper result for this example, am I missing something?</div></blockquote><div><br></div><div>What if I put that in a loop, unroll it once, and prove that the lifetime.start is unreachable? We would end up with IR like:</div><div><br></div><div>loop:</div><div>  ... use %p</div><div>  call void @lifetime.end( %p )</div><div><div>  ... use %p</div><div>  call void @lifetime.end( %p )</div></div><div>  br i1 %c, label %loop, label %exit</div><div><br></div><div>Are the second uses of %p uses of dead memory?</div><div><br></div><div>We have similar issues if the optimizer somehow removes the lifetime end and keeps the start:</div><div><br></div><div><div>loop:</div><div>  call void @lifetime.start( %p )<br></div><div>  ... use %p</div><div>  call void @lifetime.start( %p )<br></div><div><div>  ... use %p</div></div><div>  br i1 %c, label %loop, label %exit</div></div><div><br></div><div>For this reason, it has been suggested that these intrinsics are horribly broken, and both should be remodeled to just mean "store of undef bytes to this memory". If "use %p" is a load, for example, in both cases we can safely say it returns undef, because it's a use-after-scope.</div><div><br></div><div>I think coming up with a new representation with simpler semantics is the way to go. One allocation or lifetime start, and one deallocation and end.</div><div><br></div><div>Implementing this in Clang will be tricky, though. Clang's IRGen is supposed to be a dumb AST walk, but it has already strayed from that path. Needs more thought...</div></div></div></div>