[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