X-Git-Url: http://plrg.eecs.uci.edu/git/?a=blobdiff_plain;f=docs%2FStackMaps.rst;h=5bdae38b699dfbb40c8a7f1d79d9761b4ea95192;hb=5143703795b66599df93a9f35462e522f925c0f8;hp=57c37ea2f5ca2798dfb62fe70c8fd0549023cdfd;hpb=2baaf25bf507f441a6d4580fe11dcb23a9ea0c1d;p=oota-llvm.git

diff --git a/docs/StackMaps.rst b/docs/StackMaps.rst
index 57c37ea2f5c..5bdae38b699 100644
--- a/docs/StackMaps.rst
+++ b/docs/StackMaps.rst
@@ -221,6 +221,11 @@ 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 ``<target>`` must be the ABI function pointer for the
+intended target of the indirect call. Specifically, when compiling for the
+ELF V1 ABI, ``<target>`` is the function-descriptor address normally used as
+the C/C++ function-pointer representation.
+
 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 +318,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 +344,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 +405,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 +463,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
 ^^^^^^^^^^^^^^^^^^^^^^^^
@@ -483,3 +499,13 @@ the same requirement imposed by the llvm.gcroot intrinsic.) LLVM
 transformations must not substitute the alloca with any intervening
 value. This can be verified by the runtime simply by checking that the
 stack map's location is a Direct location type.
+
+
+Supported Architectures
+=======================
+
+Support for StackMap generation and the related intrinsics requires 
+some code for each backend.  Today, only a subset of LLVM's backends 
+are supported.  The currently supported architectures are X86_64, 
+PowerPC, and Aarch64.
+