[LLVMdev] Can simplifycfg kill llvm.lifetime intrinsics?

[Alexey Samsonov]

On Fri, Dec 28, 2012 at 12:35 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> >> Oh, I was reading "precedes/following" as having static (dominance)
> >> meaning. That is, in the above example you could not delete the store
> >> since it is not true that
> >> llvm.lifetime.end dominates it.
> >>
> >> Nick, is this what you had in mind? If not, then we must delete a
> >> matching llvm.lifetime.end, but it is not clear how we define
> >> "matching". In the following code some executions will hit the first
> >> llvm.lifetime.end and others will hit the second one.
> >
> >
> > Yes, I meant at runtime.
> >
>
> OK, thanks. What is the meaning in the case of aliases? Should this work:
>
> llvm.lifetime.start(%x)
>
> ...
>
> llvm.lifetime.end(%y which alias %x sometimes)
>

I'm not sure if "sometimes" actually happens in the wild.
In recent patches to lifetime handling in ASan
I assumed that argument in llvm.lifetime intrinsic
can come from bitcasts or phi nodes, but all its possible values should
originate from the same alloca instruction.


>
> If so, I guess that in order to delete a llvm.lifetime.start we have
> to delete all llvm.lifetime.end that are "directly" reachable from it
> and take an argument that may alias the one passed to
> llvm.lifetime.start. Is that it? What about calling
> llvm.lifetime.start in one function and llvm.lifetime.end in another?
>

I don't see how this can happen, assuming that arguments of llvm.lifetime
can only come from allocas.


>
> It seems that deleting llvm.lifetime.start is impossible in general,
> but it is safe to add one if at least one already exists, is that the
> case?
>
> On the other hand, removing llvm.lifetime.end should always be safe, right?
>
> Cheers,
> Rafael
>



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