.. code-block:: none
- uint32 : Reserved (header)
+ Header {
+ uint8 : Stack Map Version (current version is 1)
+ uint8 : Reserved (expected to be 0)
+ uint16 : Reserved (expected to be 0)
+ }
+ uint32 : NumFunctions
uint32 : NumConstants
+ uint32 : NumRecords
+ StkSizeRecord[NumFunctions] {
+ uint64 : Function Address
+ uint64 : Stack Size
+ }
Constants[NumConstants] {
uint64 : LargeConstant
}
- uint32 : NumRecords
StkMapRecord[NumRecords] {
uint64 : PatchPoint ID
uint32 : Instruction Offset
uint16 : Dwarf RegNum
int32 : Offset or SmallConstant
}
+ uint16 : Padding
uint16 : NumLiveOuts
LiveOuts[NumLiveOuts]
uint16 : Dwarf RegNum
uint8 : Reserved
uint8 : Size in Bytes
}
+ uint32 : Padding (only if required to align to 8 byte)
}
The first byte of each location encodes a type that indicates how to
own format. Since the runtime controls the allocation of sections, it
can reuse the same stack map space for multiple modules.
+Stackmap support is currently only implemented for 64-bit
+platforms. However, a 32-bit implementation should be able to use the
+same format with an insignificant amount of wasted space.
+
.. _stackmap-section:
Stack Map Section
To enforce these semantics, stackmap and patchpoint intrinsics are
considered to potentially read and write all memory. This may limit
-optimization more than some clients desire. To address this problem
-meta-data could be added to the intrinsic call to express aliasing,
-thereby allowing optimizations to hoist certain loads above stack
-maps.
+optimization more than some clients desire. This limitation may be
+avoided by marking the call site as "readonly". In the future we may
+also allow meta-data to be added to the intrinsic call to express
+aliasing, thereby allowing optimizations to hoist certain loads above
+stack maps.
Direct Stack Map Entries
^^^^^^^^^^^^^^^^^^^^^^^^