<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt"><div dir="ltr"><div class="gmail_default" style><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 25, 2012 at 11:09 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@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 class="im">On 24 December 2012 04:02, Alexey Samsonov <<a href="mailto:samsonov@google.com">samsonov@google.com</a>> wrote:<br>

> This looks like a bug in simplifycfg. We should preserve lifetime intrinsics<br>
> due to the reasons I described.<br>
> The code in //lib/Transforms/Utils/Local.cpp:<br>
><br>
>   if (Succ->getSinglePredecessor()) {<br>
>     // BB is the only predecessor of Succ, so Succ will end up with exactly<br>
>     // the same predecessors BB had.<br>
><br>
>     // Copy over any phi, debug or lifetime instruction.<br>
>     BB->getTerminator()->eraseFromParent();<br>
>     Succ->getInstList().splice(Succ->getFirstNonPHI(), BB->getInstList());<br>
>   }<br>
><br>
> does this only when successor of basic block being removed has a single<br>
> predecessor.<br>
> This is not the case even for simple test in<br>
> /test/Transforms/SimplifyCFG/lifetime.ll.<br>
><br>
> That said, I think for now we should just apply the patch attached to this<br>
> mail. Please take a look.<br>
<br>
</div>Sorry I missed this email the first time.<br>
<br>
>From <a href="http://llvm.org/docs/LangRef.html" target="_blank">http://llvm.org/docs/LangRef.html</a> it looks to be valid to delete<br>
only one of the functions. The semantics being<br>
<br>
* only llvm.lifetime.start: Any loads before the call can be replaced<br>
with undef. Since there is no end, all stores must be kept.<br>
* only llvm.lifetime.end: Any stores after this can be deleted. Since<br>
there is no start, all loads must be kept.<br></blockquote><div><br></div><div style>Ok, suppose you have the following code:</div><div style>BB1:</div><div style>  llvm.lifetime.start(%a)</div><div style>  store to %a</div>
<div style>  llvm.lifetime.end(%a)</div><div style>  br %BB2</div><div style><br></div><div style>BB2:</div><div style>  <some code></div><div style>  br %BB1</div><div style><br></div><div style>If you remove the first "llvm.lifetime.start", then when you enter</div>
<div style>%BB1 for the second time, your "store to %a" can be considered invalid,</div><div style>as you've already called llvm.lifetime.end for this variable.</div><div style> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
I guess with asan the "replace with undef/ remove store" become<br>
"diagnose those loads/stores".<br>
<br>
I am pretty sure we should not avoid optimizing because there is a<br>
llvm.lifetime.* in a BB. If we decide that it is invalid to delete one<br>
but not the other, we should change SimplifyCFG to delete both, not<br>
avoid merging the BBs.<br>
<br>
Nick, is the above what you had in mind when you added<br>
llvm.lifetime.*? We should clarify the language ref even if it is<br>
valid to drop only one of the calls.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div>
</div></div></div>