<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>
<div><div><br></div>-- <br><div>Alexey Samsonov, MSK</div>
</div></div>