[llvm] 3d61836 - [LangRef] mention that the lifetime intrinsics' description in LangRef isn't everything

[Juneyoung Lee via llvm-commits]

Author: Juneyoung Lee
Date: 2021-03-09T11:33:36+09:00
New Revision: 3d6183661d3a2d1e39468a51ebf4cef5bd0a2ed8

URL: https://github.com/llvm/llvm-project/commit/3d6183661d3a2d1e39468a51ebf4cef5bd0a2ed8
DIFF: https://github.com/llvm/llvm-project/commit/3d6183661d3a2d1e39468a51ebf4cef5bd0a2ed8.diff

LOG: [LangRef] mention that the lifetime intrinsics' description in LangRef isn't everything

This is a minor patch that addresses concerns about lifetime in D94002.

We need to mention that what's written in LangRef isn't everything about lifetime.start/end
and its semantics depends on the stack coloring algorithm's pattern matching of a stack pointer.

If the stack coloring algorithm cannot conclude that a pointer is a stack-allocated object, the pointer is conservatively
considered as a non-stack one because stack coloring won't take this lifetime into account while assigning addresses.

A reference from alloca to lifetime.start/end is added as well.

Differential Revision: https://reviews.llvm.org/D98112

Added: 
    

Modified: 
    llvm/docs/LangRef.rst

Removed: 
    


################################################################################
diff  --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 273652f1dbda..c15101c49bf1 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -9369,6 +9369,12 @@ the memory is reclaimed. Allocating zero bytes is legal, but the returned
 pointer may not be unique. The order in which memory is allocated (ie.,
 which way the stack grows) is not specified.
 
+If the returned pointer is used by :ref:`llvm.lifetime.start <int_lifestart>`,
+the returned object is initially dead.
+See :ref:`llvm.lifetime.start <int_lifestart>` and
+:ref:`llvm.lifetime.end <int_lifeend>` for the precise semantics of
+lifetime-manipulating intrinsics.
+
 Example:
 """"""""
 
@@ -18099,6 +18105,10 @@ 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
@@ -18145,6 +18155,10 @@ 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.
+
 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