Support: Add dwarf::getOperationEncoding()
[oota-llvm.git] / docs / LangRef.rst
index 1735a8920a56904506fcf05024d4f33ed34f128e..f7b865d0de0259a3add7392bcb68fc61c767b451 100644 (file)
@@ -588,7 +588,7 @@ iteration. The maximum alignment is ``1 << 29``.
 
 Globals can also have a :ref:`DLL storage class <dllstorageclass>`.
 
-Variables and aliasaes can have a
+Variables and aliases can have a
 :ref:`Thread Local Storage Model <tls_model>`.
 
 Syntax::
@@ -1236,9 +1236,12 @@ example:
     normally. This produces undefined behavior at runtime if the
     function ever does dynamically return.
 ``nounwind``
-    This function attribute indicates that the function never returns
-    with an unwind or exceptional control flow. If the function does
-    unwind, its runtime behavior is undefined.
+    This function attribute indicates that the function never raises an
+    exception. If the function does raise an exception, its runtime
+    behavior is undefined. However, functions marked nounwind may still
+    trap or generate asynchronous exceptions. Exception handling schemes
+    that are recognized by LLVM to handle asynchronous exceptions, such
+    as SEH, will still provide their implementation defined semantics.
 ``optnone``
     This function attribute indicates that the function is not optimized
     by any optimization or code generator passes with the
@@ -2883,6 +2886,23 @@ attached to the ``add`` instruction using the ``!dbg`` identifier:
 More information about specific metadata nodes recognized by the
 optimizers and code generator is found below.
 
+Specialized Metadata Nodes
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Specialized metadata nodes are custom data structures in metadata (as opposed
+to generic tuples).  Their fields are labelled, and can be specified in any
+order.
+
+MDLocation
+""""""""""
+
+``MDLocation`` nodes represent source debug locations.  The ``scope:`` field is
+mandatory.
+
+.. code-block:: llvm
+
+    !0 = !MDLocation(line: 2900, column: 42, scope: !1, inlinedAt: !2)
+
 '``tbaa``' Metadata
 ^^^^^^^^^^^^^^^^^^^
 
@@ -7281,7 +7301,7 @@ Note that calling this intrinsic does not prevent function inlining or
 other aggressive transformations, so the value returned may not be that
 of the obvious source-language caller.
 
-'``llvm.frameallocate``' and '``llvm.recoverframeallocation``' Intrinsics
+'``llvm.frameallocate``' and '``llvm.framerecover``' Intrinsics
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Syntax:
@@ -7290,13 +7310,13 @@ Syntax:
 ::
 
       declare i8* @llvm.frameallocate(i32 %size)
-      declare i8* @llvm.recoverframeallocation(i8* %func, i8* %fp)
+      declare i8* @llvm.framerecover(i8* %func, i8* %fp)
 
 Overview:
 """""""""
 
 The '``llvm.frameallocate``' intrinsic allocates stack memory at some fixed
-offset from the frame pointer, and the '``llvm.recoverframeallocation``'
+offset from the frame pointer, and the '``llvm.framerecover``'
 intrinsic applies that offset to a live frame pointer to recover the address of
 the allocation. The offset is computed during frame layout of the caller of
 ``llvm.frameallocate``.
@@ -7308,12 +7328,12 @@ The ``size`` argument to '``llvm.frameallocate``' must be a constant integer
 indicating the amount of stack memory to allocate. As with allocas, allocating
 zero bytes is legal, but the result is undefined.
 
-The ``func`` argument to '``llvm.recoverframeallocation``' must be a constant
+The ``func`` argument to '``llvm.framerecover``' must be a constant
 bitcasted pointer to a function defined in the current module. The code
 generator cannot determine the frame allocation offset of functions defined in
 other modules.
 
-The ``fp`` argument to '``llvm.recoverframeallocation``' must be a frame
+The ``fp`` argument to '``llvm.framerecover``' must be a frame
 pointer of a call frame that is currently live. The return value of
 '``llvm.frameaddress``' is one way to produce such a value, but most platforms
 also expose the frame pointer through stack unwinding mechanisms.
@@ -7328,7 +7348,7 @@ memory is only aligned to the ABI-required stack alignment.  Each function may
 only call '``llvm.frameallocate``' one or zero times from the function entry
 block.  The frame allocation intrinsic inhibits inlining, as any frame
 allocations in the inlined function frame are likely to be at a different
-offset from the one used by '``llvm.recoverframeallocation``' called with the
+offset from the one used by '``llvm.framerecover``' called with the
 uninlined function.
 
 .. _int_read_register:
@@ -9862,10 +9882,10 @@ generated for this intrinsic, and instructions that contribute only to the
 provided condition are not used for code generation. If the condition is
 violated during execution, the behavior is undefined.
 
-Please note that optimizer might limit the transformations performed on values
+Note that the optimizer might limit the transformations performed on values
 used by the ``llvm.assume`` intrinsic in order to preserve the instructions
 only used to form the intrinsic's input argument. This might prove undesirable
-if the extra information provided by the ``llvm.assume`` intrinsic does cause
+if the extra information provided by the ``llvm.assume`` intrinsic does not cause
 sufficient overall improvement in code quality. For this reason,
 ``llvm.assume`` should not be used to document basic mathematical invariants
 that the optimizer can otherwise deduce or facts that are of little use to the