[PATCH] D43269: [MemorySSA] Be less aggressive with @llvm.lifetime.start

[Daniel Berlin via Phabricator via llvm-commits]

dberlin added a comment.

To be clear, i think the lifetime system has enough issues that trying to cover it with MemorySSA as it currently exists wouldn't end up well.
Things that want to care about and try to optimize around lifetimes can do that.  
Intermixing object lifetime and aliasing results in the same system will, IMHO, give you a bad time.

(though we could provide a separate def-use chain in memoryssa to try to make sense of the lifetimes if we wanted to, but it'd be hard to update given lifetimes are not that well specified)

As far as i'm aware, it's legal to do whatever you want and then drop the intrinsics
IE reuse of a load after lifetime.end is fine as long as you kill the lifetime.end

If not, IMHO, we have bigger problems.

@nlopes It's worse than you might think. We allow, and try to make sense of, stuff like this:

    A
  /   \
  B   C
  \   /
    D 
    |
    E

A:
lifetime.start(16, %foo)
B: 
lifetime.end(16, %foo)
lifetime.start(16, %foo)
C:
D:
use %foo
E:
lifetime.end(16, %foo)

It's your job to realize the lifetime.end in %E ends the lifetime of two completely different memory objects.. 
Or does it?
Who knows!

There's a significant set of hacks in stack coloring/etc to handle the degenerate cases.
Splitting can also occur by accident. There is no lifetime verifier or anything, so what has been allowed has degraded over time.

Hopefully some day someone will clean this up with a well defined lifetime system, using explicit tokens and a verifier.


Repository:
  rL LLVM

https://reviews.llvm.org/D43269