[LLVMdev] lifetime.start/end clarification

[Philip Reames]

On 11/05/2014 10:54 AM, Reid Kleckner wrote:
>
>     This seems fine to me.  The optimizer can (soundly) conclude that
>     %p is dead after the "lifetime.end" (for the two instructions),
>     and dead before the "lifetime.start" (for the *single* instruction
>     in that basic block, *not* for the previous BB).  This seems like
>     the proper result for this example, am I missing something?
>
>
> What if I put that in a loop, unroll it once, and prove that the 
> lifetime.start is unreachable? We would end up with IR like:
>
> loop:
>   ... use %p
>   call void @lifetime.end( %p )
>   ... use %p
>   call void @lifetime.end( %p )
>   br i1 %c, label %loop, label %exit
>
> Are the second uses of %p uses of dead memory?
It's hard to discuss this without being specific about the starting IR 
and transforms.  My general response is that either a) such a transform 
wouldn't be valid or b) the behaviour of the original program was 
undefined.

In the particular final IR result you gave, the second use of %p would 
be dead.  Moreover, if the optimizer can prove this loop iterates at 
least once, *all access* to %p in the loop is dead. This is exactly the 
semantics you want.
>
> We have similar issues if the optimizer somehow removes the lifetime 
> end and keeps the start:
>
> loop:
>   call void @lifetime.start( %p )
>   ... use %p
>   call void @lifetime.start( %p )
>   ... use %p
>   br i1 %c, label %loop, label %exit
But we can't just drop arbitrary calls.  Doing so is unsound.
>
> For this reason, it has been suggested that these intrinsics are 
> horribly broken, and both should be remodeled to just mean "store of 
> undef bytes to this memory". If "use %p" is a load, for example, in 
> both cases we can safely say it returns undef, because it's a 
> use-after-scope.
I'm not actually intrinsically opposed to just an alternative.  I would 
like to see a concrete example justifying the proposal though.  Nothing 
said in this thread to date warrants redefining these intrinsics.

Worth stating explicitly: your proposed semantics are strictly *less 
powerful* than the current ones.  They may be "simpler", but you loose 
optimization possibilities.
>
> I think coming up with a new representation with simpler semantics is 
> the way to go. One allocation or lifetime start, and one deallocation 
> and end.
At least so far, I disagree.  I am open to being convinced though. :)
>
> Implementing this in Clang will be tricky, though. Clang's IRGen is 
> supposed to be a dumb AST walk, but it has already strayed from that 
> path. Needs more thought...
Do you have motivating cases other than a goto into a scoped region?  
That seems like a fairly straight forward "special case". How far would 
you get by special casing a few cases that matter and leaving the 
general problem unsolved?  At worst, you're missing an optimization here.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141105/ffb4dd4b/attachment.html>