[LLVMdev] Can simplifycfg kill llvm.lifetime intrinsics?

Alexey Samsonov samsonov at google.com
Tue Dec 25 11:31:09 PST 2012


On Tue, Dec 25, 2012 at 11:09 PM, Rafael EspĂ­ndola <
rafael.espindola at gmail.com> wrote:

> 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.
>

Ok, suppose you have the following code:
BB1:
  llvm.lifetime.start(%a)
  store to %a
  llvm.lifetime.end(%a)
  br %BB2

BB2:
  <some code>
  br %BB1

If you remove the first "llvm.lifetime.start", then when you enter
%BB1 for the second time, your "store to %a" can be considered invalid,
as you've already called llvm.lifetime.end for this variable.


>
> 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
>



-- 
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121225/84ab9435/attachment.html>


More information about the llvm-dev mailing list