X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FStackMaps.rst;h=43c60c9e7850dbeba38a33bc313cf5adb3891f4e;hb=890a876e0e16cf3b6cbcd69ebdfc75608fbc2537;hp=57c37ea2f5ca2798dfb62fe70c8fd0549023cdfd;hpb=014fdcdaf0cf194ec6c265647197dee8f589fac4;p=oota-llvm.git diff --git a/docs/StackMaps.rst b/docs/StackMaps.rst index 57c37ea2f5c..43c60c9e785 100644 --- a/docs/StackMaps.rst +++ b/docs/StackMaps.rst @@ -221,6 +221,13 @@ lowered according to the calling convention specified at the intrinsic's callsite. Variants of the intrinsic with non-void return type also return a value according to calling convention. +On PowerPC, note that ```` must be the actual intended target of +the indirect call. Specifically, even when compiling for the ELF V1 ABI, +```` is not the function-descriptor address normally used as the C/C++ +function-pointer representation. As a result, the call target must be local +because no adjustment or restoration of the TOC pointer (in register r2) will +be performed. + Requesting zero patch point arguments is valid. In this case, all variable operands are handled just like ``llvm.experimental.stackmap.*``. The difference is that space will @@ -313,17 +320,21 @@ format of this section follows: .. 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] { - uint32 : Function Offset - uint32 : Stack Size + uint64 : Function Address + uint64 : Stack Size } - uint32 : NumConstants Constants[NumConstants] { uint64 : LargeConstant } - uint32 : NumRecords StkMapRecord[NumRecords] { uint64 : PatchPoint ID uint32 : Instruction Offset @@ -335,12 +346,14 @@ format of this section follows: 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 @@ -394,6 +407,10 @@ immediately after compiling a module and encode the information in its 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 @@ -448,10 +465,11 @@ program could crash before the runtime could take back control. 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 ^^^^^^^^^^^^^^^^^^^^^^^^