maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity

[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
This commit is contained in:
Juneyoung Lee 2021-03-09 11:33:31 +09:00
parent c5c6f187a3
commit 3d6183661d
1 changed files with 14 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
llvm/docs/LangRef.rst
View File

@ -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., pointer may not be unique. The order in which memory is allocated (ie.,
which way the stack grows) is not specified. 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: Example:
"""""""" """"""""
@ -18099,6 +18105,10 @@ Semantics:
If ``ptr`` is a stack-allocated object and it points to the first byte of If ``ptr`` is a stack-allocated object and it points to the first byte of
the object, the object is initially marked as dead. 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 After '``llvm.lifetime.start``', the stack object that ``ptr`` points is marked
as alive and has an uninitialized value. as alive and has an uninitialized value.
The stack object is marked as dead when either 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 If ``ptr`` is a stack-allocated object and it points to the first byte of the
object, the object is dead. 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. 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 If ``ptr`` is a non-stack-allocated object or it does not point to the first