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

Juneyoung Lee via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Mar 6 01:54:15 PST 2021


aqjune created this revision.
aqjune added reviewers: nlopes, RalfJung.
Herald added a subscriber: jdoerfert.
aqjune requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

This is a minor patch that addresses concerns about lifetime in D94002 <https://reviews.llvm.org/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.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D98112

Files:
  llvm/docs/LangRef.rst


Index: llvm/docs/LangRef.rst
===================================================================
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -9369,6 +9369,12 @@
 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:
 """"""""
 
@@ -18114,6 +18120,11 @@
 byte of the object or it is a stack object that is already alive, it simply
 fills all bytes of the object with ``poison``.
 
+Detection of the underlying object of ``ptr`` depends on the pattern matching
+in the stack coloring algorithm that is used in the optimization pipeline.
+``ptr`` is conservatively considered as a non-stack-allocated object if
+the stack coloring algorithm cannot conclude that ``ptr`` is a stack-allocated
+object.
 
 .. _int_lifeend:
 
@@ -18151,6 +18162,11 @@
 byte of the object, it is equivalent to simply filling all bytes of the object
 with ``poison``.
 
+Detection of the underlying object of ``ptr`` depends on the pattern matching
+in the stack coloring algorithm that is used in the optimization pipeline.
+``ptr`` is conservatively considered as a non-stack-allocated object if
+the stack coloring algorithm cannot conclude that ``ptr`` is a stack-allocated
+object.
 
 '``llvm.invariant.start``' Intrinsic
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D98112.328750.patch
Type: text/x-patch
Size: 1604 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210306/c24c95f3/attachment.bin>


More information about the llvm-commits mailing list