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

[Juneyoung Lee via Phabricator via llvm-commits]

aqjune added a comment.

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, and it didn't converge as well.
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" to address the dereferenceability issue, what do you think?

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.



================
Comment at: llvm/docs/LangRef.rst:2591
 :ref:`llvm.lifetime.end <int_lifeend>` intrinsic function calls.
 
 .. _pointeraliasing:
----------------
I think this dereferenceability issue is more related to stack-allocated objects than heap/global objects. I couldn't write a program/find an existing optimization that has the dereferenceability issue with heap/global objects. Do you have any?

If it is, what do you think about changing this paragraph instead of the above paragraph to say everything that should be addressed? This paragraph is a good place to talk about stack thingy.


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

https://reviews.llvm.org/D99303