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

Wed Mar 24 14:51:49 PDT 2021

reames created this revision.
reames added reviewers: aqjune, nlopes.
Herald added subscribers: jdoerfert, dantrushin, mcrosier.
Herald added a reviewer: bollu.
reames requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

This is effectively a rework of c821ef451 <https://reviews.llvm.org/rGc821ef451373849c403686042466d30a7bf8138a>.  That change had a major problem in that it contradicted our long standing dereferenceability implementation and turned LICM into an unsound transform.  On the other hand, some of the wording clarifications were helpful.  So, instead of a whole sale revert, I'm posting a potential alternative.

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.

If you read the existing StackColoring.cpp implementation, the degenerate slot section is describing something close to the proposed split here.

I added parties I know to be interested in this area as reviewers.  I would appreciate if one of you would pick up this patch and drive it.  I don't actually care about the lifetime markers at all.  I'm simply posting this to try and drive the discussion into a productive direction.


https://reviews.llvm.org/D99303

Files:
  llvm/docs/LangRef.rst


Index: llvm/docs/LangRef.rst
===================================================================

--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -2576,19 +2576,26 @@
 If a pointer that is not based on the object tries to read or write to the
 object, it is undefined behavior.
 
-A lifetime of a memory object is a property that decides its accessibility.
-Unless stated otherwise, a memory object is alive since its allocation, and
-dead after its deallocation.
-It is undefined behavior to access a memory object that isn't alive, but
-operations that don't dereference it such as
+It is undefined behavior to access a memory object that has been deallocated,
+but operations that don't dereference it such as
 :ref:`getelementptr <i_getelementptr>`, :ref:`ptrtoint <i_ptrtoint>` and
-:ref:`icmp <i_icmp>` return a valid result.
-This explains code motion of these instructions across operations that
-impact the object's lifetime.
+:ref:`icmp <i_icmp>` return a valid result.  This allows code motion
+of such instructions across potential deallocation points.
+
+Distinct from allocation status, we also have the notion of memory object
+lifetime - an object can be either dead or live.
+All reads from a dead object return ``undef`` and all writes are ignored.  
+Unless stated otherwise, a memory object is alive after its allocation, and
+dead after its deallocation.
 A stack object's lifetime can be explicitly specified using
 :ref:`llvm.lifetime.start <int_lifestart>` and
 :ref:`llvm.lifetime.end <int_lifeend>` intrinsic function calls.
 
+Lifetime is essentially a hint to the optimizer that moving allocation or
+deallocation to the liveness transitions may be profitable.
+The optimizer is still responsible for establishing legality - e.g. a
+store to dead object can't fault, unless the object has been deallocated
+
 .. _pointeraliasing:
 
 Pointer Aliasing Rules
@@ -18295,28 +18302,14 @@
 Semantics:
 """"""""""
 
-If ``ptr`` is a stack-allocated object and it points to the first byte of
-the object, the object is initially marked as dead.
-``ptr`` is conservatively considered as a non-stack-allocated object if
-the stack coloring algorithm that is used in the optimization pipeline cannot
-conclude that ``ptr`` is a stack-allocated object.
-
-After '``llvm.lifetime.start``', the stack object that ``ptr`` points is marked
-as alive and has an uninitialized value.
-The stack object is marked as dead when either
-:ref:`llvm.lifetime.end <int_lifeend>` to the alloca is executed or the
-function returns.
+After '``llvm.lifetime.start``', the object that ``ptr`` points is marked
+as alive and has an uninitialized value (e.g. ``undef``).
 
 After :ref:`llvm.lifetime.end <int_lifeend>` is called,
-'``llvm.lifetime.start``' on the stack object can be called again.
+'``llvm.lifetime.start``' on the object can be called again.
 The second '``llvm.lifetime.start``' call marks the object as alive, but it
 does not change the address of the object.
 
-If ``ptr`` is a non-stack-allocated object, it does not point to the first
-byte of the object or it is a stack object that is already alive, it simply
-fills all bytes of the object with ``poison``.
-
-
 .. _int_lifeend:
 
 '``llvm.lifetime.end``' Intrinsic
@@ -18345,19 +18338,11 @@
 Semantics:
 """"""""""
 
-If ``ptr`` is a stack-allocated object and it points to the first byte of the
-object, the object is dead.
-``ptr`` is conservatively considered as a non-stack-allocated object if
-the stack coloring algorithm that is used in the optimization pipeline cannot
-conclude that ``ptr`` is a stack-allocated object.
+After '``llvm.lifetime.end``', the object that ``ptr`` points is marked
+as dead and has an uninitialized value (e.g. ``undef``).
 
 Calling ``llvm.lifetime.end`` on an already dead alloca is no-op.
 
-If ``ptr`` is a non-stack-allocated object or it does not point to the first
-byte of the object, it is equivalent to simply filling all bytes of the object
-with ``poison``.
-
-
 '``llvm.invariant.start``' Intrinsic
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D99303.333136.patch
Type: text/x-patch
Size: 4069 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210324/27789e26/attachment.bin>
