[LLVMdev] Can simplifycfg kill llvm.lifetime intrinsics?

[Rafael Espíndola]

On 24 December 2012 04:02, Alexey Samsonov <samsonov at google.com> wrote:
> This looks like a bug in simplifycfg. We should preserve lifetime intrinsics
> due to the reasons I described.
> The code in //lib/Transforms/Utils/Local.cpp:
>
>   if (Succ->getSinglePredecessor()) {
>     // BB is the only predecessor of Succ, so Succ will end up with exactly
>     // the same predecessors BB had.
>
>     // Copy over any phi, debug or lifetime instruction.
>     BB->getTerminator()->eraseFromParent();
>     Succ->getInstList().splice(Succ->getFirstNonPHI(), BB->getInstList());
>   }
>
> does this only when successor of basic block being removed has a single
> predecessor.
> This is not the case even for simple test in
> /test/Transforms/SimplifyCFG/lifetime.ll.
>
> That said, I think for now we should just apply the patch attached to this
> mail. Please take a look.

Sorry I missed this email the first time.

>From http://llvm.org/docs/LangRef.html it looks to be valid to delete
only one of the functions. The semantics being

* only llvm.lifetime.start: Any loads before the call can be replaced
with undef. Since there is no end, all stores must be kept.
* only llvm.lifetime.end: Any stores after this can be deleted. Since
there is no start, all loads must be kept.

I guess with asan the "replace with undef/ remove store" become
"diagnose those loads/stores".

I am pretty sure we should not avoid optimizing because there is a
llvm.lifetime.* in a BB. If we decide that it is invalid to delete one
but not the other, we should change SimplifyCFG to delete both, not
avoid merging the BBs.

Nick, is the above what you had in mind when you added
llvm.lifetime.*? We should clarify the language ref even if it is
valid to drop only one of the calls.

Cheers,
Rafael