[CMake] llvm_process_sources: Introduce a parameter, ADDITIONAL_HEADERS.

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

diff --git a/docs/LangRef.rst b/docs/LangRef.rst
index 39948f4b083ce9ac0820be3b10aca260b09b0d8f..8bb834b45ed36aa8a2458801a5db0d653454b62e 100644 (file)
--- a/docs/LangRef.rst
+++ b/docs/LangRef.rst
@@ -312,7 +312,8 @@ added in the future:
     so that the call does not break any live ranges in the caller side.
     This calling convention does not support varargs and requires the
     prototype of all callees to exactly match the prototype of the
-    function definition.
+    function definition. Furthermore the inliner doesn't consider such function
+    calls for inlining.
 "``cc 10``" - GHC convention
     This calling convention has been implemented specifically for use by
     the `Glasgow Haskell Compiler (GHC) <http://www.haskell.org/ghc>`_.
@@ -375,7 +376,13 @@ added in the future:
     that have a hot path and a cold path. The hot path is usually a small piece
     of code that doesn't many registers. The cold path might need to call out to
     another function and therefore only needs to preserve the caller-saved
-    registers, which haven't already been saved by the caller.
+    registers, which haven't already been saved by the caller. The
+    `PreserveMost` calling convention is very similar to the `cold` calling
+    convention in terms of caller/callee-saved registers, but they are used for
+    different types of function calls. `coldcc` is for function calls that are
+    rarely executed, whereas `preserve_mostcc` function calls are intended to be
+    on the hot path and definitely executed a lot. Furthermore `preserve_mostcc`
+    doesn't prevent the inliner from inlining the function call.
 
     This calling convention will be used by a future version of the ObjectiveC
     runtime and should therefore still be considered experimental at this time.
@@ -771,19 +778,16 @@ Currently, only the following parameter attributes are defined:
 .. Warning:: This feature is unstable and not fully implemented.
 
     The ``inalloca`` argument attribute allows the caller to take the
-    address of all stack-allocated arguments 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>`, an alloca may be used as an
-    ``inalloca`` argument at most once.  The attribute can only be
-    applied to the last parameter, and it guarantees that they are
-    passed in memory.  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``.
+    address of outgoing stack arguments.  An ``inalloca`` argument must
+    be a pointer to stack memory produced by an ``alloca`` instruction.
+    The alloca, or argument allocation, must also be tagged with the
+    inalloca keyword.  Only the past argument may have the ``inalloca``
+    attribute, and that argument is guaranteed to be passed in memory.
+
+    An argument allocation may be used by a call at most once because
+    the call may deallocate it.  The ``inalloca`` attribute cannot be
+    used in conjunction with other attributes that affect argument
+    storage, like ``inreg``, ``nest``, ``sret``, or ``byval``.
 
     When the call site is reached, the argument allocation must have
     been the most recent stack allocation that is still live, or the
@@ -4686,7 +4690,7 @@ Syntax:
 
 ::
 
-      <result> = alloca <type>[, <ty> <NumElements>][, align <alignment>]     ; yields {type*}:result
+      <result> = alloca <type>[, inalloca][, <ty> <NumElements>][, align <alignment>]     ; yields {type*}:result
 
 Overview:
 """""""""