[PATCH] D99303: Reword lifetime description to avoid contradicting long term implementation

[Philip Reames via Phabricator via llvm-commits]

reames added a comment.

Macro point: please consider everything in this response as advisory, and non-blocking.  As mentioned in the related discussion in the commit thread for the original patch, I am planning on removing myself from this discussion going forward, and nothing said here should be considered blocking.  If it's useful, great.  If not, feel free to ignore.

In D99303#2649619 <https://reviews.llvm.org/D99303#2649619>, @aqjune wrote:

> Hi,
>
>> The core notions here are: 1) separate dereferenceability and object lifetime (in the marker intrinsic sense), and 2) unify handling for all memory object types.
>
> I think it is good to separate the two concerns: the second issue already led a long discussion in llvm-dev (this Jan), and it didn't converge as well.

I'm not sure this is really possible.  The example which concerns me is what if we have a lifetime end buried in a callee?  As the current semantics are written, the behavior of such a call depends on the underlying allocation type.  This makes it really hard to either a) reason about the semantics of the function in isolation, or b) perform optimization if we're forced to assume the conservative union of the handling.

> The first issue seems important ATM, so let's make this patch concentrate on that. This will help converge discussion shortly.
> It seems enough to update "Object Lifetime" section to address the dereferenceability issue, what do you think?

I am in general very hesitant about this.

My primary concern is not that the semantics are self consistent or not.  My concern is that the semantics seem not to match the existing implementation in the optimizer.   (Specifically, see the hoisting example I gave elsewhere.)

I can see three possible paths to resolution:

1. change langref in manner to match implementation
2. change implementation to match new langref
3. make an argument that case described is impossible to construct (and thus implementation does actually match new langref wording)

I don't have any preference as to which path is taken.  I'd tend to default to option 1, but that's just what I'd do, not the only reasonable path forward.

> D99135 <https://reviews.llvm.org/D99135> and the llvm-commit mails have many valuable issues recorded about dereferenceability of a dead stack-allocated object, so I'd prefer shortly mentioning the issues here to not lose it.
> Especially, store to an stack-allocated object that is dead may overwrite another stack object's value <- this seems pretty important to me.

Fair, I don't really have a good suggestion as to how to resolve this.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D99303/new/

https://reviews.llvm.org/D99303