llvm dev - Dec 2012 - [LLVMdev] Can simplifycfg kill llvm.lifetime intrinsics?

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


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


Cheers,
Rafael

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

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

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?

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