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