Lines Matching full:stack
2 Stack maps and patch points in LLVM
16 A stack map records the location of ``live values`` at a particular
18 LLVM values live across the stack map. Instead, they are only the
22 containing the stack map.
24 LLVM emits stack map data into the object code within a designated
25 :ref:`stackmap-section`. This stack map data contains a record for
26 each stack map. The record stores the stack map's instruction address
28 value's location as a register, stack offset, or constant.
33 convention and may return a value. They also imply stack map
50 used whenever stack maps or code patching are needed. Because the
54 The stack map functionality described in this document is separate
56 :ref:`stack-map`. `GCFunctionMetadata` provides the location of
58 which can also be considered a "stack map". Unlike the stack maps
59 defined above, the `GCFunctionMetadata` stack map interface does not
62 stack map. The stack maps described here could potentially provide
69 The following two kinds of intrinsics can be used to implement stack
72 stack map record, and they both allow some form of code patching. They
74 implicitly generates a stack map without the need for an additional
80 runtime patches code at the stack map's address, it will destructively
88 Each instance of one of these intrinsics generates a stack map record
90 the runtime to uniquely identify the stack map, and the offset within
108 specified values in the stack map without generating any code.
113 The first operand is an ID to be encoded within the stack map. The
117 the ``live values`` for which locations will be recorded in the stack map.
119 To use this intrinsic as a bare-bones stack map, with no code patching
125 The stack map intrinsic generates no code in place, unless nops are
127 function entry is stored in the stack map. This is the relative
129 precede the stack map.
131 The stack map ID allows a runtime to locate the desired stack map
132 record. LLVM passes this ID through directly to the stack map
135 LLVM guarantees a shadow of instructions following the stack map's
140 outside the code. The code for instructions following the stack map
141 may be emitted in the stack map's shadow, and these instructions may
144 current function. We disallow overlapping stack map shadows so that
147 For example, a stack map with 8 byte shadow:
163 0x05 nop <--- stack map address
170 patch 8 bytes of code at the stack map's address at follows:
175 0x05 movl $0xffff, %rax <--- patched code at stack map address
180 stack frame from the values located by the stack map.
202 values in the stack map.
212 the ``live values`` for which locations will be recorded in the stack
218 The patch point intrinsic generates a stack map. It also emits a
236 The location of the arguments are not normally recorded in the stack
239 could be a register, stack location, or constant. A special calling
240 convention has been introduced for use with stack maps, anyregcc,
243 will have their register locations recorded in the stack map in
282 Note that no stack map locations will be recorded. If the patched code
292 The stack map now indicates the location of the %ptr argument and
297 Stack Map: ID=78, Loc0=%r9 Loc1=%r8
313 Stack Map Format
316 The existence of a stack map or patch point intrinsic within an LLVM
323 uint8 : Stack Map Version (current version is 3)
332 uint64 : Stack Size (or UINT64_MAX if not statically known)
376 ``Offset`` field will be zero. Values spilled to the stack are encoded
378 stack address, typically in the form ``[BP + Offset]``. If an
379 ``alloca`` value is passed directly to a stack map intrinsic, then
380 LLVM may fold the frame index into the stack map as an optimization to
381 avoid allocating a register or stack slot. These frame indices will be
383 also optimize constants by emitting them directly in the stack map,
403 The stack map format is a contract between an LLVM SVN revision and
406 important. Consequently, the stack map design is motivated by
411 can reuse the same stack map space for multiple modules.
419 Stack Map Section
429 later parse it to recover the stack map data.
431 For MachO (e.g. on Darwin), the stack map section name is
434 For ELF (e.g. on Linux), the stack map section name is
437 Stack Map Usage
440 The stack map support described in this document can be used to
444 stack map record given only the ID, offset, and the order of the
452 commandeer a stack frame when execution reaches an instruction address
453 associated with a stack map. The runtime must be able to rebuild a
454 stack frame and resume program execution using the information
455 provided by the stack map. For example, execution may resume in an
459 stores across a stack map. However, loads must also be handled
461 above a stack map could be invalid. For example, the runtime may
464 some activation of the load's function exists on the stack, the load
466 load by immediately patching any stack map location that lies between
468 simply patch all stack map locations to invalidate the function). If
469 the compiler had hoisted the load above the stack map, then the
478 stack maps.
480 Direct Stack Map Entries
483 As shown in :ref:`stackmap-section`, a Direct stack map location
486 which refer to a stack locations from which the requested values must
499 stack immediately after compilation, or at any time thereafter. This
502 instruction address of the stack map.
509 stack map's location is a Direct location type.