[LLVMdev] lifetime.start/end clarification

[Reid Kleckner]

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

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

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

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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141105/e7736105/attachment.html>