Remove the 's' DataLayout specification

[oota-llvm.git] / docs / LangRef.rst

diff --git a/docs/LangRef.rst b/docs/LangRef.rst
index 483bea2a9a2d7de23b990dccec160a79dc4d26ad..c9ea23af7a35af9a239a7e3fa9d7ebaf7418972e 100644 (file)
--- a/docs/LangRef.rst
+++ b/docs/LangRef.rst
@@ -366,6 +366,18 @@ added in the future:
     accessed runtime components pinned to specific hardware registers.
     At the moment only X86 supports this convention (both 32 and 64
     bit).
+"``webkit_jscc``" - WebKit's JavaScript calling convention
+    This calling convention has been implemented for `WebKit FTL JIT
+    <https://trac.webkit.org/wiki/FTLJIT>`_. It passes arguments on the
+    stack right to left (as cdecl does), and returns a value in the
+    platform's customary return register.
+"``anyregcc``" - Dynamic calling convention for code patching
+    This is a special convention that supports patching an arbitrary code
+    sequence in place of a call site. This convention forces the call
+    arguments into registers but allows them to be dynamcially
+    allocated. This can currently only be used with calls to
+    llvm.experimental.patchpoint because only this intrinsic records
+    the location of its arguments in a side table. See :doc:`StackMaps`.
 "``cc <n>``" - Numbered convention
     Any calling convention may be specified by number, allowing
     target-specific calling conventions to be used. Target specific
@@ -697,6 +709,39 @@ Currently, only the following parameter attributes are defined:
     site. If the alignment is not specified, then the code generator
     makes a target-specific assumption.
 
+.. _attr_inalloca:
+
+``inalloca``
+
+.. Warning:: This feature is unstable and not fully implemented.
+
+    The ``inalloca`` argument attribute allows the caller to get the
+    address of an outgoing argument to a ``call`` or ``invoke`` before
+    it executes.  It is similar to ``byval`` in that it is used to pass
+    arguments by value, but it guarantees that the argument will not be
+    copied.
+
+    To be :ref:`well formed <wellformed>`, the caller must pass in an
+    alloca value into an ``inalloca`` parameter, and an alloca may be
+    used as an ``inalloca`` argument at most once.  The attribute can
+    only be applied to parameters that would be passed in memory and not
+    registers.  The ``inalloca`` attribute cannot be used in conjunction
+    with other attributes that affect argument storage, like ``inreg``,
+    ``nest``, ``sret``, or ``byval``.  The ``inalloca`` stack space is
+    considered to be clobbered by any call that uses it, so any
+    ``inalloca`` parameters cannot be marked ``readonly``.
+
+    Allocas passed with ``inalloca`` to a call must be in the opposite
+    order of the parameter list, meaning that the rightmost argument
+    must be allocated first.  If a call has inalloca arguments, no other
+    allocas can occur between the first alloca used by the call and the
+    call site, unless they are are cleared by calls to
+    :ref:`llvm.stackrestore <int_stackrestore>`.  Violating these rules
+    results in undefined behavior at runtime.
+
+    See :doc:`InAlloca` for more information on how to use this
+    attribute.
+
 ``sret``
     This indicates that the pointer parameter specifies the address of a
     structure that is the return value of the function in the source
@@ -1115,9 +1160,6 @@ as follows:
 ``a<size>:<abi>:<pref>``
     This specifies the alignment for an aggregate type of a given bit
     ``<size>``.
-``s<size>:<abi>:<pref>``
-    This specifies the alignment for a stack object of a given bit
-    ``<size>``.
 ``n<size1>:<size2>:<size3>...``
     This specifies a set of native integer widths for the target CPU in
     bits. For example, it might contain ``n32`` for 32-bit PowerPC,
@@ -1147,7 +1189,7 @@ specifications are given in this list:
 -  ``f128:128:128`` - quad is 128-bit aligned
 -  ``v64:64:64`` - 64-bit vector is 64-bit aligned
 -  ``v128:128:128`` - 128-bit vector is 128-bit aligned
--  ``a0:0:64`` - aggregates are 64-bit aligned
+-  ``a:0:64`` - aggregates are 64-bit aligned
 
 When LLVM is determining the alignment for a given type, it uses the
 following rules:
@@ -8419,6 +8461,8 @@ Memory Use Markers
 This class of intrinsics exists to information about the lifetime of
 memory objects and ranges where variables are immutable.
 
+.. _int_lifestart:
+
 '``llvm.lifetime.start``' Intrinsic
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -8450,6 +8494,8 @@ of the memory pointed to by ``ptr`` is dead. This means that it is known
 to never be used and has an undefined value. A load from the pointer
 that precedes this intrinsic can be replaced with ``'undef'``.
 
+.. _int_lifeend:
+
 '``llvm.lifetime.end``' Intrinsic
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -8875,3 +8921,10 @@ Semantics:
 
 This intrinsic does nothing, and it's removed by optimizers and ignored
 by codegen.
+
+Stack Map Intrinsics
+--------------------
+
+LLVM provides experimental intrinsics to support runtime patching
+mechanisms commonly desired in dynamic language JITs. These intrinsics
+are described in :doc:`StackMaps`.