[LLVMdev] Can simplifycfg kill llvm.lifetime intrinsics?

[Nick Lewycky]

On 12/26/2012 12:25 PM, Rafael Espíndola wrote:
>> 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.
>
> 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.

> BB0:
> ...
> llvm.lifetime.start(%a)
> ...
> br i1 %foo, label %BB1, label %BB2
>
> BB1:
> ...
> llvm.lifetime.end(%a)
> ...
> br label %bar
>
> BB2:
> ...
> llvm.lifetime.end(%a)
> ...
> br label %zed

I don't like this because I fear proliferation of all of these 
intrinsics everywhere. They were really intended for smaller things -- 
an interpreter with a stack that it wants to 'pop' off of, so that piece 
of memory is no longer meaningfully defined, just as if you freed it.

Regardless, yes, this behaves the way it looks.

Nick