[LLVMdev] Can simplifycfg kill llvm.lifetime intrinsics?
samsonov at google.com
Thu Dec 27 23:51:00 PST 2012
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.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
> On the other hand, removing llvm.lifetime.end should always be safe, right?
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev