<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt"><div dir="ltr"><div class="gmail_default" style>This looks like a bug in simplifycfg. We should preserve lifetime intrinsics due to the reasons I described.</div>
<div class="gmail_default" style>The code in //lib/Transforms/Utils/Local.cpp:</div><div class="gmail_default" style><div class="gmail_default"><br></div><div class="gmail_default">  if (Succ->getSinglePredecessor()) {</div>
<div class="gmail_default">    // BB is the only predecessor of Succ, so Succ will end up with exactly</div><div class="gmail_default">    // the same predecessors BB had.</div><div class="gmail_default"><br></div><div class="gmail_default">
    // Copy over any phi, debug or lifetime instruction.</div><div class="gmail_default">    BB->getTerminator()->eraseFromParent();</div><div class="gmail_default">    Succ->getInstList().splice(Succ->getFirstNonPHI(), BB->getInstList());</div>
<div class="gmail_default">  }</div><div class="gmail_default"><br></div><div class="gmail_default" style>does this only when successor of basic block being removed has a single predecessor.</div><div class="gmail_default" style>
This is not the case even for simple test in /test/Transforms/SimplifyCFG/lifetime.ll.</div><div class="gmail_default" style><br></div><div class="gmail_default" style>That said, I think for now we should just apply the patch attached to this mail. Please take a look.</div>
</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 17, 2012 at 6:59 PM, Alexey Samsonov <span dir="ltr"><<a href="mailto:samsonov@google.com" target="_blank">samsonov@google.com</a>></span> wrote:<br>
<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 style="font-family:arial,helvetica,sans-serif;font-size:10pt">
Hi!<div><br></div><div>I'm working on ASan option that uses llvm.lifetime intrinsics to detect use-after-scope bugs. In short, the idea is to</div>
<div>insert calls into ASan runtime that would mark the memory as "addressable" or "unaddressable".</div><div>I see the following problem with the following "trivial" basic block:</div><div>
<div>
<br></div><div>for.body.lr.ph.i:                                 ; preds = %for.body.i310</div><div>  call void @llvm.lifetime.start(i64 24, i8* %174)</div><div>  call void @llvm.lifetime.start(i64 4, i8* %175)</div><div>

  call void @llvm.lifetime.start(i64 24, i8* %176)</div><div>  br label %for.body.i318</div></div><div><br></div><div>r134182 by Rafael explicitly allows simplifycfg pass to merge this block into its successor, and drop "side-effect free" lifetime.start</div>

<div>intrinsics. However, llvm.lifetime.end intrinsics for the same memory are preserved, which is not only weird, but triggers ASan false positives:</div><div>1) function goes into for-loop with local variable declared in it</div>

<div>2) llvm.lifetime.end() at the end of the loop allows ASan to mark this memory as unaddressable</div><div>3) at the next loop iteration access to this memory will be reported as error.</div><div><br></div><div>Shouldn't simplifycfg somehow preserve / move lifetime intrinsics in its transformations?</div>
<span class=""><font color="#888888">
<div><div><br></div>-- <br><div>Alexey Samsonov, MSK</div>
</div></font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div>
</div></div></div>