Update to LLVM 3.5a.

Change-Id: Ifadecab779f128e62e430c2b4f6ddd84953ed617

57 files changed, 3540 insertions, 1937 deletions

diff --git a/docs/BitCodeFormat.rst b/docs/BitCodeFormat.rst
index d9d1df0..86436ff 100644
--- a/docs/BitCodeFormat.rst
+++ b/docs/BitCodeFormat.rst
@@ -658,7 +658,7 @@ for each library name referenced.
 MODULE_CODE_GLOBALVAR Record
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-``[GLOBALVAR, pointer type, isconst, initid, linkage, alignment, section, visibility, threadlocal, unnamed_addr]``
+``[GLOBALVAR, pointer type, isconst, initid, linkage, alignment, section, visibility, threadlocal, unnamed_addr, dllstorageclass]``
 
 The ``GLOBALVAR`` record (code 7) marks the declaration or definition of a
 global variable. The operand fields are:
@@ -688,7 +688,8 @@ global variable. The operand fields are:
   * ``weak_odr``: code 10
   * ``linkonce_odr``: code 11
   * ``available_externally``: code 12
-  * ``linker_private``: code 13
+  * deprecated : code 13
+  * deprecated : code 14
 
 * alignment*: The logarithm base 2 of the variable's requested alignment, plus 1
 
@@ -713,12 +714,20 @@ global variable. The operand fields are:
 * *unnamed_addr*: If present and non-zero, indicates that the variable has
   ``unnamed_addr``
 
+.. _dllstorageclass:
+
+* *dllstorageclass*: If present, an encoding of the DLL storage class of this variable:
+
+  * ``default``: code 0
+  * ``dllimport``: code 1
+  * ``dllexport``: code 2
+
 .. _FUNCTION:
 
 MODULE_CODE_FUNCTION Record
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-``[FUNCTION, type, callingconv, isproto, linkage, paramattr, alignment, section, visibility, gc, prefix]``
+``[FUNCTION, type, callingconv, isproto, linkage, paramattr, alignment, section, visibility, gc, prefix, dllstorageclass]``
 
 The ``FUNCTION`` record (code 8) marks the declaration or definition of a
 function. The operand fields are:
@@ -729,11 +738,17 @@ function. The operand fields are:
   * ``ccc``: code 0
   * ``fastcc``: code 8
   * ``coldcc``: code 9
+  * ``webkit_jscc``: code 12
+  * ``anyregcc``: code 13
+  * ``preserve_mostcc``: code 14
+  * ``preserve_allcc``: code 15
   * ``x86_stdcallcc``: code 64
   * ``x86_fastcallcc``: code 65
   * ``arm_apcscc``: code 66
   * ``arm_aapcscc``: code 67
   * ``arm_aapcs_vfpcc``: code 68
+  * ``x86_thiscallcc``: code 70
+  * ``x86_cdeclmethodcc``: code 80
 
 * isproto*: Non-zero if this entry represents a declaration rather than a
   definition
@@ -760,10 +775,12 @@ function. The operand fields are:
 * *prefix*: If non-zero, the value index of the prefix data for this function,
   plus 1.
 
+* *dllstorageclass*: An encoding of the `dllstorageclass`_ of this function
+
 MODULE_CODE_ALIAS Record
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
-``[ALIAS, alias type, aliasee val#, linkage, visibility]``
+``[ALIAS, alias type, aliasee val#, linkage, visibility, dllstorageclass]``
 
 The ``ALIAS`` record (code 9) marks the definition of an alias. The operand
 fields are
@@ -776,6 +793,8 @@ fields are
 
 * *visibility*: If present, an encoding of the `visibility`_ of the alias
 
+* *dllstorageclass*: If present, an encoding of the `dllstorageclass`_ of the alias
+
 MODULE_CODE_PURGEVALS Record
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -1076,7 +1095,7 @@ named type.
 VALUE_SYMTAB_BLOCK Contents
 ---------------------------
 
-The ``VALUE_SYMTAB_BLOCK`` block (id 14) ... 
+The ``VALUE_SYMTAB_BLOCK`` block (id 14) ...
 
 .. _METADATA_BLOCK:
 
diff --git a/docs/CMake.rst b/docs/CMake.rst
index c9fe538..cbca1db 100644
--- a/docs/CMake.rst
+++ b/docs/CMake.rst
@@ -211,6 +211,9 @@ LLVM-specific variables
 **LLVM_ENABLE_THREADS**:BOOL
   Build with threads support, if available. Defaults to ON.
 
+**LLVM_ENABLE_CXX11**:BOOL
+  Build in C++11 mode, if available. Defaults to OFF.
+
 **LLVM_ENABLE_ASSERTIONS**:BOOL
   Enables code assertions. Defaults to OFF if and only if ``CMAKE_BUILD_TYPE``
   is *Release*.
@@ -263,7 +266,7 @@ LLVM-specific variables
 **LLVM_EXTERNAL_{CLANG,LLD,POLLY}_SOURCE_DIR**:PATH
   Path to ``{Clang,lld,Polly}``\'s source directory. Defaults to
   ``tools/{clang,lld,polly}``. ``{Clang,lld,Polly}`` will not be built when it
-  is empty or it does not point valid path.
+  is empty or it does not point to a valid path.
 
 **LLVM_USE_OPROFILE**:BOOL
   Enable building OProfile JIT support. Defaults to OFF
@@ -280,6 +283,50 @@ LLVM-specific variables
   are ``Address``, ``Memory`` and ``MemoryWithOrigins``. Defaults to empty
   string.
 
+**LLVM_ENABLE_DOXYGEN**:BOOL
+  Enables the generation of browsable HTML documentation using doxygen.
+  Defaults to OFF.
+
+**LLVM_ENABLE_DOXYGEN_QT_HELP**:BOOL
+  Enables the generation of a Qt Compressed Help file. Defaults to OFF.
+  This affects the make target ``doxygen-llvm``. When enabled, apart from
+  the normal HTML output generated by doxygen, this will produce a QCH file
+  named ``org.llvm.qch``. You can then load this file into Qt Creator.
+  This option is only useful in combination with ``-DLLVM_ENABLE_DOXYGEN=ON``;
+  otherwise this has no effect.
+
+**LLVM_DOXYGEN_QCH_FILENAME**:STRING
+  The filename of the Qt Compressed Help file that will be genrated when
+  ``-DLLVM_ENABLE_DOXYGEN=ON`` and 
+  ``-DLLVM_ENABLE_DOXYGEN_QT_HELP=ON`` are given. Defaults to
+  ``org.llvm.qch``.
+  This option is only useful in combination with
+  ``-DLLVM_ENABLE_DOXYGEN_QT_HELP=ON``;
+  otherwise this has no effect.
+
+**LLVM_DOXYGEN_QHP_NAMESPACE**:STRING
+  Namespace under which the intermediate Qt Help Project file lives. See `Qt
+  Help Project <http://qt-project.org/doc/qt-4.8/qthelpproject.html#namespace>`_
+  for more information. Defaults to "org.llvm". This option is only useful in
+  combination with ``-DLLVM_ENABLE_DOXYGEN_QT_HELP=ON``; otherwise
+  this has no effect.
+    
+**LLVM_DOXYGEN_QHP_CUST_FILTER_NAME**:STRING
+  See `Qt Help Project
+  <http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-filters>`_ for
+  more information. Defaults to the CMake variable ``${PACKAGE_STRING}`` which
+  is a combination of the package name and version string. This filter can then
+  be used in Qt Creator to select only documentation from LLVM when browsing
+  through all the help files that you might have loaded. This option is only
+  useful in combination with ``-DLLVM_ENABLE_DOXYGEN_QT_HELP=ON``;
+  otherwise this has no effect.
+
+**LLVM_DOXYGEN_QHELPGENERATOR_PATH**:STRING
+  The path to the ``qhelpgenerator`` executable. Defaults to whatever CMake's
+  ``find_program()`` can find. This option is only useful in combination with
+  ``-DLLVM_ENABLE_DOXYGEN_QT_HELP=ON``; otherwise this has no
+  effect.
+
 Executing the test suite
 ========================
 
diff --git a/docs/CMakeLists.txt b/docs/CMakeLists.txt
index 8c49aa5..f0aa9c2 100644
--- a/docs/CMakeLists.txt
+++ b/docs/CMakeLists.txt
@@ -22,6 +22,40 @@ if (LLVM_ENABLE_DOXYGEN)
     set(extra_search_mappings "")
   endif()
   
+  # If asked, configure doxygen for the creation of a Qt Compressed Help file.
+  option(LLVM_ENABLE_DOXYGEN_QT_HELP
+    "Generate a Qt Compressed Help file." OFF)
+  if (LLVM_ENABLE_DOXYGEN_QT_HELP)
+    set(LLVM_DOXYGEN_QCH_FILENAME "org.llvm.qch" CACHE STRING
+      "Filename of the Qt Compressed help file")
+    set(LLVM_DOXYGEN_QHP_NAMESPACE "org.llvm" CACHE STRING 
+      "Namespace under which the intermediate Qt Help Project file lives")
+    set(LLVM_DOXYGEN_QHP_CUST_FILTER_NAME "${PACKAGE_STRING}" CACHE STRING
+      "See http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-filters")
+    set(LLVM_DOXYGEN_QHP_CUST_FILTER_ATTRS "${PACKAGE_NAME},${PACKAGE_VERSION}" CACHE STRING
+      "See http://qt-project.org/doc/qt-4.8/qthelpproject.html#filter-attributes")
+    find_program(LLVM_DOXYGEN_QHELPGENERATOR_PATH qhelpgenerator 
+      DOC "Path to the qhelpgenerator binary")
+    if (NOT LLVM_DOXYGEN_QHELPGENERATOR_PATH)
+      message(FATAL_ERROR "Failed to find qhelpgenerator binary")
+    endif()
+
+    set(llvm_doxygen_generate_qhp "YES")
+    set(llvm_doxygen_qch_filename "${LLVM_DOXYGEN_QCH_FILENAME}")
+    set(llvm_doxygen_qhp_namespace "${LLVM_DOXYGEN_QHP_NAMESPACE}")
+    set(llvm_doxygen_qhelpgenerator_path "${LLVM_DOXYGEN_QHELPGENERATOR_PATH}")
+    set(llvm_doxygen_qhp_cust_filter_name "${LLVM_DOXYGEN_QHP_CUST_FILTER_NAME}")
+    set(llvm_doxygen_qhp_cust_filter_attrs "${LLVM_DOXYGEN_QHP_CUST_FILTER_ATTRS}")
+
+  else()
+    set(llvm_doxygen_generate_qhp "NO")
+    set(llvm_doxygen_qch_filename "")
+    set(llvm_doxygen_qhp_namespace "")
+    set(llvm_doxygen_qhelpgenerator_path "")
+    set(llvm_doxygen_qhp_cust_filter_name "")
+    set(llvm_doxygen_qhp_cust_filter_attrs "")
+  endif()
+  
   configure_file(${CMAKE_CURRENT_SOURCE_DIR}/doxygen.cfg.in
     ${CMAKE_CURRENT_BINARY_DIR}/doxygen.cfg @ONLY)
 
@@ -33,6 +67,12 @@ if (LLVM_ENABLE_DOXYGEN)
   set(enable_server_based_search)
   set(enable_external_search)
   set(extra_search_mappings)
+  set(llvm_doxygen_generate_qhp)
+  set(llvm_doxygen_qch_filename)
+  set(llvm_doxygen_qhp_namespace)
+  set(llvm_doxygen_qhelpgenerator_path)
+  set(llvm_doxygen_qhp_cust_filter_name)
+  set(llvm_doxygen_qhp_cust_filter_attrs)
 
   add_custom_target(doxygen-llvm
     COMMAND ${DOXYGEN_EXECUTABLE} ${CMAKE_CURRENT_BINARY_DIR}/doxygen.cfg
diff --git a/docs/CodeGenerator.rst b/docs/CodeGenerator.rst
index c87a628..d7d98bc 100644
--- a/docs/CodeGenerator.rst
+++ b/docs/CodeGenerator.rst
@@ -434,12 +434,12 @@ For example, consider this simple LLVM example:
 .. code-block:: llvm
 
   define i32 @test(i32 %X, i32 %Y) {
-    %Z = udiv i32 %X, %Y
+    %Z = sdiv i32 %X, %Y
     ret i32 %Z
   }
 
-The X86 instruction selector produces this machine code for the ``div`` and
-``ret`` (use "``llc X.bc -march=x86 -print-machineinstrs``" to get this):
+The X86 instruction selector might produce this machine code for the ``div`` and
+``ret``:
 
 .. code-block:: llvm
 
@@ -454,8 +454,8 @@ The X86 instruction selector produces this machine code for the ``div`` and
   %EAX = mov %reg1026           ;; 32-bit return value goes in EAX
   ret
 
-By the end of code generation, the register allocator has coalesced the
-registers and deleted the resultant identity moves producing the following
+By the end of code generation, the register allocator would coalesce the
+registers and delete the resultant identity moves producing the following
 code:
 
 .. code-block:: llvm
@@ -2145,6 +2145,10 @@ The following target-specific calling conventions are known to backend:
   others via stack. Callee is responsible for stack cleaning. This convention is
   used by MSVC by default for methods in its ABI (CC ID = 70).
 
+* **X86_CDeclMethod** --- Identical to the standard x86_32 C calling convention,
+  except that an sret paramter, if present, is placed on the stack after the
+  second parameter, which must an integer or pointer.  (CC ID = 80).
+
 .. _X86 addressing mode:
 
 Representing X86 addressing modes in MachineInstrs
diff --git a/docs/CodingStandards.rst b/docs/CodingStandards.rst
index 9418680..2ebdfbc 100644
--- a/docs/CodingStandards.rst
+++ b/docs/CodingStandards.rst
@@ -14,9 +14,9 @@ absolute requirements to be followed in all instances, coding standards are
 particularly important for large-scale code bases that follow a library-based
 design (like LLVM).
 
-This document intentionally does not prescribe fixed standards for religious
-issues such as brace placement and space usage.  For issues like this, follow
-the golden rule:
+While this document may provide guidance for some mechanical formatting issues,
+whitespace, or other "microscopic details", these are not fixed standards.
+Always follow the golden rule:
 
 .. _Golden Rule:
 
@@ -43,6 +43,135 @@ The ultimate goal of these guidelines is the increase readability and
 maintainability of our common source base. If you have suggestions for topics to
 be included, please mail them to `Chris <mailto:sabre@nondot.org>`_.
 
+Languages, Libraries, and Standards
+===================================
+
+Most source code in LLVM and other LLVM projects using these coding standards
+is C++ code. There are some places where C code is used either due to
+environment restrictions, historical restrictions, or due to third-party source
+code imported into the tree. Generally, our preference is for standards
+conforming, modern, and portable C++ code as the implementation language of
+choice.
+
+C++ Standard Versions
+---------------------
+
+LLVM, Clang, and LLD are currently written using C++11 conforming code,
+although we restrict ourselves to features which are available in the major
+toolchains supported as host compilers. The LLDB project is even more
+aggressive in the set of host compilers supported and thus uses still more
+features. Regardless of the supported features, code is expected to (when
+reasonable) be standard, portable, and modern C++11 code. We avoid unnecessary
+vendor-specific extensions, etc.
+
+C++ Standard Library
+--------------------
+
+Use the C++ standard library facilities whenever they are available for
+a particular task. LLVM and related projects emphasize and rely on the standard
+library facilities for as much as possible. Common support libraries providing
+functionality missing from the standard library for which there are standard
+interfaces or active work on adding standard interfaces will often be
+implemented in the LLVM namespace following the expected standard interface.
+
+There are some exceptions such as the standard I/O streams library which are
+avoided. Also, there is much more detailed information on these subjects in the
+`Programmer's Manual`_.
+
+.. _Programmer's Manual:
+  http://llvm.org/docs/ProgrammersManual.html
+
+Supported C++11 Language and Library Features
+---------------------------------------------
+
+While LLVM, Clang, and LLD use C++11, not all features are available in all of
+the toolchains which we support. The set of features supported for use in LLVM
+is the intersection of those supported in MSVC 2012, GCC 4.7, and Clang 3.1.
+The ultimate definition of this set is what build bots with those respective
+toolchains accept. Don't argue with the build bots. However, we have some
+guidance below to help you know what to expect.
+
+Each toolchain provides a good reference for what it accepts:
+
+* Clang: http://clang.llvm.org/cxx_status.html
+* GCC: http://gcc.gnu.org/projects/cxx0x.html
+* MSVC: http://msdn.microsoft.com/en-us/library/hh567368.aspx
+
+In most cases, the MSVC list will be the dominating factor. Here is a summary
+of the features that are expected to work. Features not on this list are
+unlikely to be supported by our host compilers.
+
+* Rvalue references: N2118_
+
+  * But *not* Rvalue references for ``*this`` or member qualifiers (N2439_)
+
+* Static assert: N1720_
+* ``auto`` type deduction: N1984_, N1737_
+* Trailing return types: N2541_
+* Lambdas: N2927_
+
+  * But *not* ``std::function``, until Clang implements `MSVC-compatible RTTI`_.
+
+* ``decltype``: N2343_
+* Nested closing right angle brackets: N1757_
+* Extern templates: N1987_
+* ``nullptr``: N2431_
+* Strongly-typed and forward declarable enums: N2347_, N2764_
+* Local and unnamed types as template arguments: N2657_
+* Range-based for-loop: N2930_
+* ``override`` and ``final``: N2928_, N3206_, N3272_
+* Atomic operations and the C++11 memory model: N2429_
+
+.. _N2118: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html
+.. _N2439: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm
+.. _N1720: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1720.html
+.. _N1984: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf
+.. _N1737: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1737.pdf
+.. _N2541: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2541.htm
+.. _N2927: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2927.pdf
+.. _N2343: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2343.pdf
+.. _N1757: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html
+.. _N1987: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1987.htm
+.. _N2431: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf
+.. _N2347: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf
+.. _N2764: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2764.pdf
+.. _N2657: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2657.htm
+.. _N2930: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2930.html
+.. _N2928: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2928.htm
+.. _N3206: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3206.htm
+.. _N3272: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3272.htm
+.. _N2429: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2429.htm
+.. _MSVC-compatible RTTI: http://llvm.org/PR18951
+
+The supported features in the C++11 standard libraries are less well tracked,
+but also much greater. Most of the standard libraries implement most of C++11's
+library. The most likely lowest common denominator is Linux support. For
+libc++, the support is just poorly tested and undocumented but expected to be
+largely complete. YMMV. For libstdc++, the support is documented in detail in
+`the libstdc++ manual`_. There are some very minor missing facilities that are
+unlikely to be common problems, and there are a few larger gaps that are worth
+being aware of:
+
+* Not all of the type traits are implemented
+* No regular expression library.
+* While most of the atomics library is well implemented, the fences are
+  missing. Fortunately, they are rarely needed.
+* The locale support is incomplete.
+* ``std::initializer_list`` (and the constructors and functions that take it as
+  an argument) are not always available, so you cannot (for example) initialize
+  a ``std::vector`` with a braced initializer list.
+
+Other than these areas you should assume the standard library is available and
+working as expected until some build bot tells you otherwise. If you're in an
+uncertain area of one of the above points, but you cannot test on a Linux
+system, your best approach is to minimize your use of these features, and watch
+the Linux build bots to find out if your usage triggered a bug. For example, if
+you hit a type trait which doesn't work we can then add support to LLVM's
+traits header to emulate it.
+
+.. _the libstdc++ manual:
+  http://gcc.gnu.org/onlinedocs/gcc-4.7.3/libstdc++/manual/manual/status.html#status.iso.2011
+
 Mechanical Source Issues
 ========================
 
@@ -335,11 +464,88 @@ Indent Code Consistently
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 Okay, in your first year of programming you were told that indentation is
-important.  If you didn't believe and internalize this then, now is the time.
-Just do it.
+important. If you didn't believe and internalize this then, now is the time.
+Just do it. With the introduction of C++11, there are some new formatting
+challenges that merit some suggestions to help have consistent, maintainable,
+and tool-friendly formatting and indentation.
+
+Format Lambdas Like Blocks Of Code
+""""""""""""""""""""""""""""""""""
+
+When formatting a multi-line lambda, format it like a block of code, that's
+what it is. If there is only one multi-line lambda in a statement, and there
+are no expressions lexically after it in the statement, drop the indent to the
+standard two space indent for a block of code, as if it were an if-block opened
+by the preceding part of the statement:
+
+.. code-block:: c++
+
+  std::sort(foo.begin(), foo.end(), [&](Foo a, Foo b) -> bool {
+    if (a.blah < b.blah)
+      return true;
+    if (a.baz < b.baz)
+      return true;
+    return a.bam < b.bam;
+  });
+
+To take best advantage of this formatting, if you are designing an API which
+accepts a continuation or single callable argument (be it a functor, or
+a ``std::function``), it should be the last argument if at all possible.
+
+If there are multiple multi-line lambdas in a statement, or there is anything
+interesting after the lambda in the statement, indent the block two spaces from
+the indent of the ``[]``:
+
+.. code-block:: c++
+
+  dyn_switch(V->stripPointerCasts(),
+             [] (PHINode *PN) {
+               // process phis...
+             },
+             [] (SelectInst *SI) {
+               // process selects...
+             },
+             [] (LoadInst *LI) {
+               // process loads...
+             },
+             [] (AllocaInst *AI) {
+               // process allocas...
+             });
+
+Braced Initializer Lists
+""""""""""""""""""""""""
+
+With C++11, there are significantly more uses of braced lists to perform
+initialization. These allow you to easily construct aggregate temporaries in
+expressions among other niceness. They now have a natural way of ending up
+nested within each other and within function calls in order to build up
+aggregates (such as option structs) from local variables. To make matters
+worse, we also have many more uses of braces in an expression context that are
+*not* performing initialization.
+
+The historically common formatting of braced initialization of aggregate
+variables does not mix cleanly with deep nesting, general expression contexts,
+function arguments, and lambdas. We suggest new code use a simple rule for
+formatting braced initialization lists: act as-if the braces were parentheses
+in a function call. The formatting rules exactly match those already well
+understood for formatting nested function calls. Examples:
+
+.. code-block:: c++
+
+  foo({a, b, c}, {1, 2, 3});
 
-Compiler Issues
----------------
+  llvm::Constant *Mask[] = {
+      llvm::ConstantInt::get(llvm::Type::getInt32Ty(getLLVMContext()), 0),
+      llvm::ConstantInt::get(llvm::Type::getInt32Ty(getLLVMContext()), 1),
+      llvm::ConstantInt::get(llvm::Type::getInt32Ty(getLLVMContext()), 2)};
+
+This formatting scheme also makes it particularly easy to get predictable,
+consistent, and automatic formatting with tools like `Clang Format`_.
+
+.. _Clang Format: http://clang.llvm.org/docs/ClangFormat.html
+
+Language and Compiler Issues
+----------------------------
 
 Treat Compiler Warnings Like Errors
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -451,12 +657,110 @@ members public by default.
 
 Unfortunately, not all compilers follow the rules and some will generate
 different symbols based on whether ``class`` or ``struct`` was used to declare
-the symbol.  This can lead to problems at link time.
+the symbol (e.g., MSVC).  This can lead to problems at link time.
+
+* All declarations and definitions of a given ``class`` or ``struct`` must use
+  the same keyword.  For example:
+
+.. code-block:: c++
+
+  class Foo;
+
+  // Breaks mangling in MSVC.
+  struct Foo { int Data; };
+
+* As a rule of thumb, ``struct`` should be kept to structures where *all*
+  members are declared public.
+
+.. code-block:: c++
+
+  // Foo feels like a class... this is strange.
+  struct Foo {
+  private:
+    int Data;
+  public:
+    Foo() : Data(0) { }
+    int getData() const { return Data; }
+    void setData(int D) { Data = D; }
+  };
+
+  // Bar isn't POD, but it does look like a struct.
+  struct Bar {
+    int Data;
+    Foo() : Data(0) { }
+  };
+
+Do not use Braced Initializer Lists to Call a Constructor
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In C++11 there is a "generalized initialization syntax" which allows calling
+constructors using braced initializer lists. Do not use these to call
+constructors with any interesting logic or if you care that you're calling some
+*particular* constructor. Those should look like function calls using
+parentheses rather than like aggregate initialization. Similarly, if you need
+to explicitly name the type and call its constructor to create a temporary,
+don't use a braced initializer list. Instead, use a braced initializer list
+(without any type for temporaries) when doing aggregate initialization or
+something notionally equivalent. Examples:
+
+.. code-block:: c++
+
+  class Foo {
+  public:
+    // Construct a Foo by reading data from the disk in the whizbang format, ...
+    Foo(std::string filename);
+
+    // Construct a Foo by looking up the Nth element of some global data ...
+    Foo(int N);
+
+    // ...
+  };
+
+  // The Foo constructor call is very deliberate, no braces.
+  std::fill(foo.begin(), foo.end(), Foo("name"));
+
+  // The pair is just being constructed like an aggregate, use braces.
+  bar_map.insert({my_key, my_value});
+
+If you use a braced initializer list when initializing a variable, use an equals before the open curly brace:
+
+.. code-block:: c++
+
+  int data[] = {0, 1, 2, 3};
+
+Use ``auto`` Type Deduction to Make Code More Readable
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Some are advocating a policy of "almost always ``auto``" in C++11, however LLVM
+uses a more moderate stance. Use ``auto`` if and only if it makes the code more
+readable or easier to maintain. Don't "almost always" use ``auto``, but do use
+``auto`` with initializers like ``cast<Foo>(...)`` or other places where the
+type is already obvious from the context. Another time when ``auto`` works well
+for these purposes is when the type would have been abstracted away anyways,
+often behind a container's typedef such as ``std::vector<T>::iterator``.
+
+Beware unnecessary copies with ``auto``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The convenience of ``auto`` makes it easy to forget that its default behavior
+is a copy.  Particularly in range-based ``for`` loops, careless copies are
+expensive.
+
+As a rule of thumb, use ``auto &`` unless you need to copy the result, and use
+``auto *`` when copying pointers.
+
+.. code-block:: c++
 
-So, the rule for LLVM is to always use the ``class`` keyword, unless **all**
-members are public and the type is a C++ `POD
-<http://en.wikipedia.org/wiki/Plain_old_data_structure>`_ type, in which case
-``struct`` is allowed.
+  // Typically there's no reason to copy.
+  for (const auto &Val : Container) { observe(Val); }
+  for (auto &Val : Container) { Val.change(); }
+
+  // Remove the reference if you really want a new copy.
+  for (auto Val : Container) { Val.change(); saveSomewhere(Val); }
+
+  // Copy pointers, but make it clear that they're pointers.
+  for (const auto *Ptr : Container) { observe(*Ptr); }
+  for (auto *Ptr : Container) { Ptr->change(); }
 
 Style Issues
 ============
@@ -844,7 +1148,7 @@ Here are more examples:
 
 .. code-block:: c++
 
-  assert(Ty->isPointerType() && "Can't allocate a non pointer type!");
+  assert(Ty->isPointerType() && "Can't allocate a non-pointer type!");
 
   assert((Opcode == Shl || Opcode == Shr) && "ShiftInst Opcode invalid!");
 
@@ -1190,46 +1494,10 @@ Namespace Indentation
 
 In general, we strive to reduce indentation wherever possible.  This is useful
 because we want code to `fit into 80 columns`_ without wrapping horribly, but
-also because it makes it easier to understand the code.  Namespaces are a funny
-thing: they are often large, and we often desire to put lots of stuff into them
-(so they can be large).  Other times they are tiny, because they just hold an
-enum or something similar.  In order to balance this, we use different
-approaches for small versus large namespaces.
-
-If a namespace definition is small and *easily* fits on a screen (say, less than
-35 lines of code), then you should indent its body.  Here's an example:
-
-.. code-block:: c++
-
-  namespace llvm {
-    namespace X86 {
-      /// \brief An enum for the x86 relocation codes.  Note that
-      /// the terminology here doesn't follow x86 convention - word means
-      /// 32-bit and dword means 64-bit.
-      enum RelocationType {
-        /// \brief PC relative relocation, add the relocated value to
-        /// the value already in memory, after we adjust it for where the PC is.
-        reloc_pcrel_word = 0,
-
-        /// \brief PIC base relative relocation, add the relocated value to
-        /// the value already in memory, after we adjust it for where the
-        /// PIC base is.
-        reloc_picrel_word = 1,
-
-        /// \brief Absolute relocation, just add the relocated value to the
-        /// value already in memory.
-        reloc_absolute_word = 2,
-        reloc_absolute_dword = 3
-      };
-    }
-  }
-
-Since the body is small, indenting adds value because it makes it very clear
-where the namespace starts and ends, and it is easy to take the whole thing in
-in one "gulp" when reading the code.  If the blob of code in the namespace is
-larger (as it typically is in a header in the ``llvm`` or ``clang`` namespaces),
-do not indent the code, and add a comment indicating what namespace is being
-closed.  For example:
+also because it makes it easier to understand the code. To facilitate this and
+avoid some insanely deep nesting on occasion, don't indent namespaces. If it
+helps readability, feel free to add a comment indicating what namespace is
+being closed by a ``}``.  For example:
 
 .. code-block:: c++
 
@@ -1251,12 +1519,12 @@ closed.  For example:
   } // end namespace knowledge
   } // end namespace llvm
 
-Because the class is large, we don't expect that the reader can easily
-understand the entire concept in a glance, and the end of the file (where the
-namespaces end) may be a long ways away from the place they open.  As such,
-indenting the contents of the namespace doesn't add any value, and detracts from
-the readability of the class.  In these cases it is best to *not* indent the
-contents of the namespace.
+
+Feel free to skip the closing comment when the namespace being closed is
+obvious for any reason. For example, the outer-most namespace in a header file
+is rarely a source of confusion. But namespaces both anonymous and named in
+source files that are being closed half way through the file probably could use
+clarification.
 
 .. _static:
 
@@ -1285,12 +1553,12 @@ good:
 .. code-block:: c++
 
   namespace {
-    class StringSort {
-    ...
-    public:
-      StringSort(...)
-      bool operator<(const char *RHS) const;
-    };
+  class StringSort {
+  ...
+  public:
+    StringSort(...)
+    bool operator<(const char *RHS) const;
+  };
   } // end anonymous namespace
 
   static void runHelper() { 
@@ -1306,6 +1574,7 @@ This is bad:
 .. code-block:: c++
 
   namespace {
+
   class StringSort {
   ...
   public:
diff --git a/docs/CommandGuide/index.rst b/docs/CommandGuide/index.rst
index d50542d..ab4788a 100644
--- a/docs/CommandGuide/index.rst
+++ b/docs/CommandGuide/index.rst
@@ -22,10 +22,10 @@ Basic Commands
    llvm-link
    llvm-ar
    llvm-nm
-   llvm-prof
    llvm-config
    llvm-diff
    llvm-cov
+   llvm-profdata
    llvm-stress
    llvm-symbolizer
 
diff --git a/docs/CommandGuide/llc.rst b/docs/CommandGuide/llc.rst
index 02ad798..8d5c9ce 100644
--- a/docs/CommandGuide/llc.rst
+++ b/docs/CommandGuide/llc.rst
@@ -45,7 +45,7 @@ End-user Options
 
  Generate code at different optimization levels.  These correspond to the
  ``-O0``, ``-O1``, ``-O2``, and ``-O3`` optimization levels used by
- :program:`llvm-gcc` and :program:`clang`.
+ :program:`clang`.
 
 .. option:: -mtriple=<target triple>
 
@@ -112,11 +112,6 @@ End-user Options
  optimizations allow the code generator to make use of some instructions which
  would otherwise not be usable (such as ``fsin`` on X86).
 
-.. option:: --enable-correct-eh-support
-
- Instruct the **lowerinvoke** pass to insert code for correct exception
- handling support.  This is expensive and is by default omitted for efficiency.
-
 .. option:: --stats
 
  Print statistics recorded by code-generation passes.
diff --git a/docs/CommandGuide/lli.rst b/docs/CommandGuide/lli.rst
index a9aaf31..502fbd6 100644
--- a/docs/CommandGuide/lli.rst
+++ b/docs/CommandGuide/lli.rst
@@ -190,12 +190,6 @@ CODE GENERATION OPTIONS
 
 
 
-**-enable-correct-eh-support**
-
- Make the -lowerinvoke pass insert expensive, but correct, EH code.
-
-
-
 **-jit-enable-eh**
 
  Exception handling should be enabled in the just-in-time compiler.
diff --git a/docs/CommandGuide/llvm-prof.rst b/docs/CommandGuide/llvm-prof.rst
deleted file mode 100644
index e8d0b19..0000000
--- a/docs/CommandGuide/llvm-prof.rst
+++ /dev/null
@@ -1,63 +0,0 @@
-llvm-prof - print execution profile of LLVM program
-===================================================
-
-
-SYNOPSIS
---------
-
-
-**llvm-prof** [*options*] [*bitcode file*] [*llvmprof.out*]
-
-
-DESCRIPTION
------------
-
-
-The **llvm-prof** tool reads in an *llvmprof.out* file (which can
-optionally use a specific file with the third program argument), a bitcode file
-for the program, and produces a human readable report, suitable for determining
-where the program hotspots are.
-
-This program is often used in conjunction with the *utils/profile.pl*
-script.  This script automatically instruments a program, runs it with the JIT,
-then runs **llvm-prof** to format a report.  To get more information about
-*utils/profile.pl*, execute it with the **-help** option.
-
-
-OPTIONS
--------
-
-
-
-**--annotated-llvm** or **-A**
-
- In addition to the normal report printed, print out the code for the
- program, annotated with execution frequency information. This can be
- particularly useful when trying to visualize how frequently basic blocks
- are executed.  This is most useful with basic block profiling
- information or better.
-
-
-
-**--print-all-code**
-
- Using this option enables the **--annotated-llvm** option, but it
- prints the entire module, instead of just the most commonly executed
- functions.
-
-
-
-**--time-passes**
-
- Record the amount of time needed for each pass and print it to standard
- error.
-
-
-
-
-EXIT STATUS
------------
-
-
-**llvm-prof** returns 1 if it cannot load the bitcode file or the profile
-information. Otherwise, it exits with zero.
diff --git a/docs/CommandGuide/llvm-profdata.rst b/docs/CommandGuide/llvm-profdata.rst
new file mode 100644
index 0000000..6b8e4d7
--- /dev/null
+++ b/docs/CommandGuide/llvm-profdata.rst
@@ -0,0 +1,29 @@
+llvm-profdata - work with profile data
+======================================
+
+SYNOPSIS
+--------
+
+:program:`llvm-profdata` [-output=output] file1 file2
+
+DESCRIPTION
+-----------
+
+The experimental :program:`llvm-profdata` tool reads two profile data files
+generated by PGO instrumentation and generates a file with merged data.
+
+The profile data format itself is currently textual.
+
+OPTIONS
+-------
+
+.. option:: -output=output
+
+ This option selects the output filename.  If not specified, output is to
+ stdout.
+
+EXIT STATUS
+-----------
+
+:program:`llvm-profdata` returns 1 if it cannot read input files or there is a
+mismatch between their data.
diff --git a/docs/CommandGuide/llvm-symbolizer.rst b/docs/CommandGuide/llvm-symbolizer.rst
index e03be9b..dfbdb3a 100644
--- a/docs/CommandGuide/llvm-symbolizer.rst
+++ b/docs/CommandGuide/llvm-symbolizer.rst
@@ -10,7 +10,9 @@ DESCRIPTION
 -----------
 
 :program:`llvm-symbolizer` reads object file names and addresses from standard
-input and prints corresponding source code locations to standard output. This
+input and prints corresponding source code locations to standard output.
+If object file is specified in command line, :program:`llvm-symbolizer` reads
+only addresses from standard input. This
 program uses debug info sections and symbol table in the object files.
 
 EXAMPLE
@@ -45,10 +47,22 @@ EXAMPLE
 
   _main
   /tmp/source_x86_64.cc:8
+  $ cat addr2.txt
+  0x4004f4
+  0x401000
+  $ llvm-symbolizer -obj=a.out < addr2.txt
+  main
+  /tmp/a.cc:4
+
+  foo(int)
+  /tmp/a.cc:12
 
 OPTIONS
 -------
 
+.. option:: -obj
+  Path to object file to be symbolized.
+
 .. option:: -functions
 
   Print function names as well as source file/line locations. Defaults to true.
diff --git a/docs/CommandGuide/opt.rst b/docs/CommandGuide/opt.rst
index 179c297..3fed684 100644
--- a/docs/CommandGuide/opt.rst
+++ b/docs/CommandGuide/opt.rst
@@ -65,9 +65,8 @@ OPTIONS
 .. option:: -std-compile-opts
 
  This is short hand for a standard list of *compile time optimization* passes.
- This is typically used to optimize the output from the llvm-gcc front end.  It
- might be useful for other front end compilers as well.  To discover the full
- set of options available, use the following command:
+ It might be useful for other front end compilers as well.  To discover the
+ full set of options available, use the following command:
 
  .. code-block:: sh
 
diff --git a/docs/CommandLine.rst b/docs/CommandLine.rst
index 4c84d23..1b342e3 100644
--- a/docs/CommandLine.rst
+++ b/docs/CommandLine.rst
@@ -1276,7 +1276,7 @@ The ``cl::getRegisteredOptions`` function
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The ``cl::getRegisteredOptions`` function is designed to give a programmer
-access to declared non positional command line options so that how they appear
+access to declared non-positional command line options so that how they appear
 in ``-help`` can be modified prior to calling `cl::ParseCommandLineOptions`_.
 Note this method should not be called during any static initialisation because
 it cannot be guaranteed that all options will have been initialised. Hence it
diff --git a/docs/CompilerWriterInfo.rst b/docs/CompilerWriterInfo.rst
index 7b02a78..240271a 100644
--- a/docs/CompilerWriterInfo.rst
+++ b/docs/CompilerWriterInfo.rst
@@ -80,8 +80,9 @@ R600
 SPARC
 -----
 
-* `SPARC resources <http://www.sparc.org/resource.htm>`_
-* `SPARC standards <http://www.sparc.org/standards.html>`_
+* `SPARC standards <http://sparc.org/standards>`_
+* `SPARC V9 ABI <http://sparc.org/standards/64.psabi.1.35.ps.Z>`_
+* `SPARC V8 ABI <http://sparc.org/standards/psABI3rd.pdf>`_
 
 SystemZ
 -------
@@ -108,6 +109,12 @@ Other x86-specific information
 
 * `Calling conventions for different C++ compilers and operating systems  <http://www.agner.org/optimize/calling_conventions.pdf>`_
 
+XCore
+-----
+
+* `The XMOS XS1 Architecture (ISA) <https://www.xmos.com/en/download/public/The-XMOS-XS1-Architecture%28X7879A%29.pdf>`_
+* `Tools Developement Guide (includes ABI) <https://www.xmos.com/download/public/Tools-Development-Guide%28X9114A%29.pdf>`_
+
 Other relevant lists
 --------------------
 
diff --git a/docs/DeveloperPolicy.rst b/docs/DeveloperPolicy.rst
index ea5a7d1..b9ac576 100644
--- a/docs/DeveloperPolicy.rst
+++ b/docs/DeveloperPolicy.rst
@@ -74,8 +74,8 @@ that notices of confidentiality or non-disclosure cannot be respected.
 .. _patch:
 .. _one-off patches:
 
-Making a Patch
---------------
+Making and Submitting a Patch
+-----------------------------
 
 When making a patch for review, the goal is to make it as easy for the reviewer
 to read it as possible.  As such, we recommend that you:
@@ -97,6 +97,12 @@ to read it as possible.  As such, we recommend that you:
    script, please separate out those changes into a separate patch from the rest
    of your changes.
 
+Once your patch is ready, submit it by emailing it to the appropriate project's
+commit mailing list (or commit it directly if applicable). Alternatively, some
+patches get sent to the project's development list or component of the LLVM bug
+tracker, but the commit list is the primary place for reviews and should
+generally be preferred.
+
 When sending a patch to a mailing list, it is a good idea to send it as an
 *attachment* to the message, not embedded into the text of the message.  This
 ensures that your mailer will not mangle the patch when it sends it (e.g. by
@@ -125,7 +131,8 @@ software. We generally follow these policies:
 #. All developers are required to have significant changes reviewed before they
    are committed to the repository.
 
-#. Code reviews are conducted by email, usually on the llvm-commits list.
+#. Code reviews are conducted by email on the relevant project's commit mailing
+   list, or alternatively on the project's development list or bug tracker.
 
 #. Code can be reviewed either before it is committed or after.  We expect major
    changes to be reviewed before being committed, but smaller changes (or
@@ -205,13 +212,10 @@ features added.  Some tips for getting your testcase approved:
   directory. The appropriate sub-directory should be selected (see the
   :doc:`Testing Guide <TestingGuide>` for details).
 
-* Test cases should be written in `LLVM assembly language <LangRef.html>`_
-  unless the feature or regression being tested requires another language
-  (e.g. the bug being fixed or feature being implemented is in the llvm-gcc C++
-  front-end, in which case it must be written in C++).
+* Test cases should be written in :doc:`LLVM assembly language <LangRef>`.
 
 * Test cases, especially for regressions, should be reduced as much as possible,
-  by `bugpoint <Bugpoint.html>`_ or manually. It is unacceptable to place an
+  by :doc:`bugpoint <Bugpoint>` or manually. It is unacceptable to place an
   entire failing program into ``llvm/test`` as this creates a *time-to-test*
   burden on all developers. Please keep them short.
 
@@ -413,15 +417,24 @@ to go about making the change.
 Attribution of Changes
 ----------------------
 
-We believe in correct attribution of contributions to their contributors.
-However, we do not want the source code to be littered with random attributions
-"this code written by J. Random Hacker" (this is noisy and distracting).  In
-practice, the revision control system keeps a perfect history of who changed
-what, and the CREDITS.txt file describes higher-level contributions.  If you
-commit a patch for someone else, please say "patch contributed by J. Random
-Hacker!" in the commit message.
+When contributors submit a patch to an LLVM project, other developers with
+commit access may commit it for the author once appropriate (based on the
+progression of code review, etc.). When doing so, it is important to retain
+correct attribution of contributions to their contributors. However, we do not
+want the source code to be littered with random attributions "this code written
+by J. Random Hacker" (this is noisy and distracting). In practice, the revision
+control system keeps a perfect history of who changed what, and the CREDITS.txt
+file describes higher-level contributions. If you commit a patch for someone
+else, please say "patch contributed by J. Random Hacker!" in the commit
+message. Overall, please do not add contributor names to the source code.
+
+Also, don't commit patches authored by others unless they have submitted the
+patch to the project or you have been authorized to submit them on their behalf
+(you work together and your company authorized you to contribute the patches,
+etc.). The author should first submit them to the relevant project's commit
+list, development list, or LLVM bug tracker component. If someone sends you
+a patch privately, encourage them to submit it to the appropriate list first.
 
-Overall, please do not add contributor names to the source code.
 
 .. _copyright-license-patents:
 
@@ -501,12 +514,12 @@ to move code from (e.g.)  libc++ to the LLVM core without concern, but that code
 cannot be moved from the LLVM core to libc++ without the copyright owner's
 permission.
 
-Note that the LLVM Project does distribute llvm-gcc and dragonegg, **which are
-GPL.** This means that anything "linked" into llvm-gcc must itself be compatible
+Note that the LLVM Project does distribute dragonegg, **which is
+GPL.** This means that anything "linked" into dragonegg must itself be compatible
 with the GPL, and must be releasable under the terms of the GPL.  This implies
-that **any code linked into llvm-gcc and distributed to others may be subject to
+that **any code linked into dragonegg and distributed to others may be subject to
 the viral aspects of the GPL** (for example, a proprietary code generator linked
-into llvm-gcc must be made available under the GPL).  This is not a problem for
+into dragonegg must be made available under the GPL).  This is not a problem for
 code already distributed under a more liberal license (like the UIUC license),
 and GPL-containing subprojects are kept in separate SVN repositories whose
 LICENSE.txt files specifically indicate that they contain GPL code.
diff --git a/docs/ExceptionHandling.rst b/docs/ExceptionHandling.rst
index 0a86607..64edca7 100644
--- a/docs/ExceptionHandling.rst
+++ b/docs/ExceptionHandling.rst
@@ -142,7 +142,7 @@ continuation points:
 #. where to continue if the call raises an exception, either by a throw or the
    unwinding of a throw
 
-The term used to define a the place where an ``invoke`` continues after an
+The term used to define the place where an ``invoke`` continues after an
 exception is called a *landing pad*. LLVM landing pads are conceptually
 alternative function entry points where an exception structure reference and a
 type info index are passed in as arguments. The landing pad saves the exception
@@ -157,12 +157,61 @@ the *selector value* respectively.
 The ``landingpad`` instruction takes a reference to the personality function to
 be used for this ``try``/``catch`` sequence. The remainder of the instruction is
 a list of *cleanup*, *catch*, and *filter* clauses. The exception is tested
-against the clauses sequentially from first to last. The selector value is a
-positive number if the exception matched a type info, a negative number if it
-matched a filter, and zero if it matched a cleanup. If nothing is matched, the
-behavior of the program is `undefined`_. If a type info matched, then the
-selector value is the index of the type info in the exception table, which can
-be obtained using the `llvm.eh.typeid.for`_ intrinsic.
+against the clauses sequentially from first to last. The clauses have the
+following meanings:
+
+-  ``catch <type> @ExcType``
+
+   - This clause means that the landingpad block should be entered if the
+     exception being thrown is of type ``@ExcType`` or a subtype of
+     ``@ExcType``. For C++, ``@ExcType`` is a pointer to the ``std::type_info``
+     object (an RTTI object) representing the C++ exception type.
+
+   - If ``@ExcType`` is ``null``, any exception matches, so the landingpad
+     should always be entered. This is used for C++ catch-all blocks ("``catch
+     (...)``").
+
+   - When this clause is matched, the selector value will be equal to the value
+     returned by "``@llvm.eh.typeid.for(i8* @ExcType)``". This will always be a
+     positive value.
+
+-  ``filter <type> [<type> @ExcType1, ..., <type> @ExcTypeN]``
+
+   - This clause means that the landingpad should be entered if the exception
+     being thrown does *not* match any of the types in the list (which, for C++,
+     are again specified as ``std::type_info`` pointers).
+
+   - C++ front-ends use this to implement C++ exception specifications, such as
+     "``void foo() throw (ExcType1, ..., ExcTypeN) { ... }``".
+
+   - When this clause is matched, the selector value will be negative.
+
+   - The array argument to ``filter`` may be empty; for example, "``[0 x i8**]
+     undef``". This means that the landingpad should always be entered. (Note
+     that such a ``filter`` would not be equivalent to "``catch i8* null``",
+     because ``filter`` and ``catch`` produce negative and positive selector
+     values respectively.)
+
+-  ``cleanup``
+
+   - This clause means that the landingpad should always be entered.
+
+   - C++ front-ends use this for calling objects' destructors.
+
+   - When this clause is matched, the selector value will be zero.
+
+   - The runtime may treat "``cleanup``" differently from "``catch <type>
+     null``".
+
+     In C++, if an unhandled exception occurs, the language runtime will call
+     ``std::terminate()``, but it is implementation-defined whether the runtime
+     unwinds the stack and calls object destructors first. For example, the GNU
+     C++ unwinder does not call object destructors when an unhandled exception
+     occurs. The reason for this is to improve debuggability: it ensures that
+     ``std::terminate()`` is called from the context of the ``throw``, so that
+     this context is not lost by unwinding the stack. A runtime will typically
+     implement this by searching for a matching non-``cleanup`` clause, and
+     aborting if it does not find one, before entering any landingpad blocks.
 
 Once the landing pad has the type info selector, the code branches to the code
 for the first catch. The catch then checks the value of the type info selector
@@ -278,10 +327,19 @@ This intrinsic returns the type info index in the exception table of the current
 function.  This value can be used to compare against the result of
 ``landingpad`` instruction.  The single argument is a reference to a type info.
 
+Uses of this intrinsic are generated by the C++ front-end.
+
+SJLJ Intrinsics
+---------------
+
+The ``llvm.eh.sjlj`` intrinsics are used internally within LLVM's
+backend.  Uses of them are generated by the backend's
+``SjLjEHPrepare`` pass.
+
 .. _llvm.eh.sjlj.setjmp:
 
 ``llvm.eh.sjlj.setjmp``
------------------------
+~~~~~~~~~~~~~~~~~~~~~~~
 
 .. code-block:: llvm
 
@@ -303,7 +361,7 @@ available for use in a target-specific manner.
 .. _llvm.eh.sjlj.longjmp:
 
 ``llvm.eh.sjlj.longjmp``
-------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. code-block:: llvm
 
@@ -316,7 +374,7 @@ pointer are restored from the buffer, then control is transferred to the
 destination address.
 
 ``llvm.eh.sjlj.lsda``
----------------------
+~~~~~~~~~~~~~~~~~~~~~
 
 .. code-block:: llvm
 
@@ -328,7 +386,7 @@ function. The SJLJ front-end code stores this address in the exception handling
 function context for use by the runtime.
 
 ``llvm.eh.sjlj.callsite``
--------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. code-block:: llvm
 
diff --git a/docs/Extensions.rst b/docs/Extensions.rst
index e308dbc..7d8c521 100644
--- a/docs/Extensions.rst
+++ b/docs/Extensions.rst
@@ -37,7 +37,7 @@ X86/COFF-Dependent
 Relocations
 ^^^^^^^^^^^
 
-The following additional relocation type is supported:
+The following additional relocation types are supported:
 
 **@IMGREL** (AT&T syntax only) generates an image-relative relocation that
 corresponds to the COFF relocation types ``IMAGE_REL_I386_DIR32NB`` (32-bit) or
@@ -54,6 +54,22 @@ corresponds to the COFF relocation types ``IMAGE_REL_I386_DIR32NB`` (32-bit) or
     .long (fun@imgrel + 0x3F)
     .long $unwind$fun@imgrel
 
+**.secrel32** generates a relocation that corresponds to the COFF relocation
+types ``IMAGE_REL_I386_SECREL`` (32-bit) or ``IMAGE_REL_AMD64_SECREL`` (64-bit).
+
+**.secidx** relocation generates an index of the section that contains
+the target.  It corresponds to the COFF relocation types
+``IMAGE_REL_I386_SECTION`` (32-bit) or ``IMAGE_REL_AMD64_SECTION`` (64-bit).
+
+.. code-block:: gas
+
+  .section .debug$S,"rn"
+    .long 4
+    .long 242
+    .long 40
+    .secrel32 _function_name
+    .secidx   _function_name
+    ...
 
 ``.linkonce`` Directive
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -127,9 +143,9 @@ MC supports passing the information in ``.linkonce`` at the end of
   Symbol1:
   .long 1
 
-Note that in the combined form the COMDAT symbol is explict. This
-extension exits to support multiple sections with the same name in
-different comdats:
+Note that in the combined form the COMDAT symbol is explicit. This
+extension exists to support multiple sections with the same name in
+different COMDATs:
 
 
 .. code-block:: gas
diff --git a/docs/FAQ.rst b/docs/FAQ.rst
index e4ab2c1..8db94c6 100644
--- a/docs/FAQ.rst
+++ b/docs/FAQ.rst
@@ -184,14 +184,6 @@ This is `a bug in GCC <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13392>`_,
 and affects projects other than LLVM.  Try upgrading or downgrading your GCC.
 
 
-Compiling LLVM with GCC succeeds, but the resulting tools do not work, what can be wrong?
------------------------------------------------------------------------------------------
-Several versions of GCC have shown a weakness in miscompiling the LLVM
-codebase.  Please consult your compiler version (``gcc --version``) to find
-out whether it is `broken <GettingStarted.html#brokengcc>`_.  If so, your only
-option is to upgrade GCC to a known good version.
-
-
 After Subversion update, rebuilding gives the error "No rule to make target".
 -----------------------------------------------------------------------------
 If the error is of the form:
diff --git a/docs/GarbageCollection.rst b/docs/GarbageCollection.rst
index 73bc5ee..323a6ea 100644
--- a/docs/GarbageCollection.rst
+++ b/docs/GarbageCollection.rst
@@ -500,8 +500,7 @@ This boilerplate collector does nothing.  More specifically:
 
 * The stack map is not compiled into the executable.
 
-Using the LLVM makefiles (like the `sample project
-<http://llvm.org/viewvc/llvm-project/llvm/trunk/projects/sample/>`__), this code
+Using the LLVM makefiles, this code
 can be compiled as a plugin using a simple makefile:
 
 .. code-block:: make
diff --git a/docs/GetElementPtr.rst b/docs/GetElementPtr.rst
index 306a2a8..91025d8 100644
--- a/docs/GetElementPtr.rst
+++ b/docs/GetElementPtr.rst
@@ -77,7 +77,7 @@ therefore be indexed and requires an index operand. Consider this example:
   ...
   munge(Array);
 
-In this "C" example, the front end compiler (llvm-gcc) will generate three GEP
+In this "C" example, the front end compiler (Clang) will generate three GEP
 instructions for the three indices through "P" in the assignment statement.  The
 function argument ``P`` will be the first operand of each of these GEP
 instructions.  The second operand indexes through that pointer.  The third
diff --git a/docs/GettingStarted.rst b/docs/GettingStarted.rst
index 2a6b637..3d2ec1e 100644
--- a/docs/GettingStarted.rst
+++ b/docs/GettingStarted.rst
@@ -87,10 +87,6 @@ Here's the short story for getting up and running quickly with LLVM:
    * ``make check-all`` --- This run the regression tests to ensure everything
      is in working order.
 
-   * ``make update`` --- This command is used to update all the svn repositories
-     at once, rather then having to ``cd`` into the individual repositories and
-     running ``svn update``.
-
    * It is also possible to use CMake instead of the makefiles. With CMake it is
      possible to generate project files for several IDEs: Xcode, Eclipse CDT4,
      CodeBlocks, Qt-Creator (use the CodeBlocks generator), KDevelop3.
@@ -113,75 +109,32 @@ software you will need.
 Hardware
 --------
 
-LLVM is known to work on the following platforms:
-
-+-----------------+----------------------+-------------------------+
-|OS               |  Arch                | Compilers               |
-+=================+======================+=========================+
-|AuroraUX         | x86\ :sup:`1`        | GCC                     |
-+-----------------+----------------------+-------------------------+
-|Linux            | x86\ :sup:`1`        | GCC                     |
-+-----------------+----------------------+-------------------------+
-|Linux            | amd64                | GCC                     |
-+-----------------+----------------------+-------------------------+
-|Linux            | ARM\ :sup:`13`       | GCC                     |
-+-----------------+----------------------+-------------------------+
-|Solaris          | V9 (Ultrasparc)      | GCC                     |
-+-----------------+----------------------+-------------------------+
-|FreeBSD          | x86\ :sup:`1`        | GCC                     |
-+-----------------+----------------------+-------------------------+
-|FreeBSD          | amd64                | GCC                     |
-+-----------------+----------------------+-------------------------+
-|MacOS X\ :sup:`2`| PowerPC              | GCC                     |
-+-----------------+----------------------+-------------------------+
-|MacOS X\ :sup:`9`| x86                  | GCC                     |
-+-----------------+----------------------+-------------------------+
-|Cygwin/Win32     | x86\ :sup:`1, 8, 11` | GCC 3.4.X, binutils 2.20|
-+-----------------+----------------------+-------------------------+
-
-LLVM has partial support for the following platforms:
-
-+-------------------+----------------------+-------------------------------------------+
-|OS                 |  Arch                | Compilers                                 |
-+===================+======================+===========================================+
-| Windows           | x86\ :sup:`1`        | Visual Studio 2000 or higher\ :sup:`4,5`  |
-+-------------------+----------------------+-------------------------------------------+
-| AIX\ :sup:`3,4`   | PowerPC              | GCC                                       |
-+-------------------+----------------------+-------------------------------------------+
-| Linux\ :sup:`3,5` | PowerPC              | GCC                                       |
-+-------------------+----------------------+-------------------------------------------+
-| Linux\ :sup:`7`   | Alpha                | GCC                                       |
-+-------------------+----------------------+-------------------------------------------+
-| Linux\ :sup:`7`   | Itanium (IA-64)      | GCC                                       |
-+-------------------+----------------------+-------------------------------------------+
-| HP-UX\ :sup:`7`   | Itanium (IA-64)      | HP aCC                                    |
-+-------------------+----------------------+-------------------------------------------+
-| Windows x64       | x86-64               | mingw-w64's GCC-4.5.x\ :sup:`12`          |
-+-------------------+----------------------+-------------------------------------------+
+LLVM is known to work on the following host platforms:
+
+================== ===================== =============
+OS                 Arch                  Compilers               
+================== ===================== =============
+AuroraUX           x86\ :sup:`1`         GCC                     
+Linux              x86\ :sup:`1`         GCC, Clang              
+Linux              amd64                 GCC, Clang              
+Linux              ARM\ :sup:`4`         GCC, Clang              
+Linux              PowerPC               GCC, Clang              
+Solaris            V9 (Ultrasparc)       GCC                     
+FreeBSD            x86\ :sup:`1`         GCC, Clang              
+FreeBSD            amd64                 GCC, Clang              
+MacOS X\ :sup:`2`  PowerPC               GCC                     
+MacOS X            x86                   GCC, Clang              
+Cygwin/Win32       x86\ :sup:`1, 3`      GCC                     
+Windows            x86\ :sup:`1`         Visual Studio           
+Windows x64        x86-64                Visual Studio           
+================== ===================== =============
 
 .. note::
 
   #. Code generation supported for Pentium processors and up
   #. Code generation supported for 32-bit ABI only
-  #. No native code generation
-  #. Build is not complete: one or more tools do not link or function
-  #. The GCC-based C/C++ frontend does not build
-  #. The port is done using the MSYS shell.
-  #. Native code generation exists but is not complete.
-  #. Binutils 2.20 or later is required to build the assembler generated by LLVM properly.
-  #. Xcode 2.5 and gcc 4.0.1 (Apple Build 5370) will trip internal LLVM assert
-     messages when compiled for Release at optimization levels greater than 0
-     (i.e., ``-O1`` and higher).  Add ``OPTIMIZE_OPTION="-O0"`` to the build
-     command line if compiling for LLVM Release or bootstrapping the LLVM
-     toolchain.
-  #. For MSYS/MinGW on Windows, be sure to install the MSYS version of the perl
-     package, and be sure it appears in your path before any Windows-based
-     versions such as Strawberry Perl and ActivePerl, as these have
-     Windows-specifics that will cause the build to fail.
   #. To use LLVM modules on Win32-based system, you may configure LLVM
      with ``--enable-shared``.
-  #. To compile SPU backend, you need to add ``LDFLAGS=-Wl,--stack,16777216`` to
-     configure.
   #. MCJIT not working well pre-v7, old JIT engine not supported any more.
 
 Note that you will need about 1-3 GB of space for a full LLVM build in Debug
@@ -206,44 +159,30 @@ for the software package that LLVM depends on. The Version column provides
 "known to work" versions of the package. The Notes column describes how LLVM
 uses the package and provides other details.
 
-+--------------------------------------------------------------+-----------------+---------------------------------------------+
-| Package                                                      | Version         | Notes                                       |
-+==============================================================+=================+=============================================+
-| `GNU Make <http://savannah.gnu.org/projects/make>`_          | 3.79, 3.79.1    | Makefile/build processor                    |
-+--------------------------------------------------------------+-----------------+---------------------------------------------+
-| `GCC <http://gcc.gnu.org/>`_                                 | 3.4.2           | C/C++ compiler\ :sup:`1`                    |
-+--------------------------------------------------------------+-----------------+---------------------------------------------+
-| `TeXinfo <http://www.gnu.org/software/texinfo/>`_            | 4.5             | For building the CFE                        |
-+--------------------------------------------------------------+-----------------+---------------------------------------------+
-| `SVN <http://subversion.tigris.org/project_packages.html>`_  | >=1.3           | Subversion access to LLVM\ :sup:`2`         |
-+--------------------------------------------------------------+-----------------+---------------------------------------------+
-| `python <http://www.python.org/>`_                           | >=2.5           | Automated test suite\ :sup:`3`              |
-+--------------------------------------------------------------+-----------------+---------------------------------------------+
-| `GNU M4 <http://savannah.gnu.org/projects/m4>`_              | 1.4             | Macro processor for configuration\ :sup:`4` |
-+--------------------------------------------------------------+-----------------+---------------------------------------------+
-| `GNU Autoconf <http://www.gnu.org/software/autoconf/>`_      | 2.60            | Configuration script builder\ :sup:`4`      |
-+--------------------------------------------------------------+-----------------+---------------------------------------------+
-| `GNU Automake <http://www.gnu.org/software/automake/>`_      | 1.9.6           | aclocal macro generator\ :sup:`4`           |
-+--------------------------------------------------------------+-----------------+---------------------------------------------+
-| `libtool <http://savannah.gnu.org/projects/libtool>`_        | 1.5.22          | Shared library manager\ :sup:`4`            |
-+--------------------------------------------------------------+-----------------+---------------------------------------------+
-| `zlib <http://zlib.net>`_                                    | >=1.2.3.4       | Compression library\ :sup:`5`               |
-+--------------------------------------------------------------+-----------------+---------------------------------------------+
+=========================================================== ============ ==========================================
+Package                                                     Version      Notes
+=========================================================== ============ ==========================================
+`GNU Make <http://savannah.gnu.org/projects/make>`_         3.79, 3.79.1 Makefile/build processor
+`GCC <http://gcc.gnu.org/>`_                                >=4.7.0      C/C++ compiler\ :sup:`1`
+`python <http://www.python.org/>`_                          >=2.5        Automated test suite\ :sup:`2`
+`GNU M4 <http://savannah.gnu.org/projects/m4>`_             1.4          Macro processor for configuration\ :sup:`3`
+`GNU Autoconf <http://www.gnu.org/software/autoconf/>`_     2.60         Configuration script builder\ :sup:`3`
+`GNU Automake <http://www.gnu.org/software/automake/>`_     1.9.6        aclocal macro generator\ :sup:`3`
+`libtool <http://savannah.gnu.org/projects/libtool>`_       1.5.22       Shared library manager\ :sup:`3`
+`zlib <http://zlib.net>`_                                   >=1.2.3.4    Compression library\ :sup:`4`
+=========================================================== ============ ==========================================
 
 .. note::
 
    #. Only the C and C++ languages are needed so there's no need to build the
       other languages for LLVM's purposes. See `below` for specific version
       info.
-   #. You only need Subversion if you intend to build from the latest LLVM
-      sources. If you're working from a release distribution, you don't need
-      Subversion.
    #. Only needed if you want to run the automated test suite in the
       ``llvm/test`` directory.
    #. If you want to make changes to the configure scripts, you will need GNU
       autoconf (2.60), and consequently, GNU M4 (version 1.4 or higher). You
       will also need automake (1.9.6). We only use aclocal from that package.
-   #. Optional, adds compression/uncompression capabilities to selected LLVM
+   #. Optional, adds compression / uncompression capabilities to selected LLVM
       tools.
 
 Additionally, your compilation host is expected to have the usual plethora of
@@ -277,92 +216,32 @@ Unix utilities. Specifically:
 .. _below:
 .. _check here:
 
-Broken versions of GCC and other tools
---------------------------------------
+Host C++ Toolchain, both Compiler and Standard Library
+------------------------------------------------------
 
 LLVM is very demanding of the host C++ compiler, and as such tends to expose
-bugs in the compiler.  In particular, several versions of GCC crash when trying
-to compile LLVM.  We routinely use GCC 4.2 (and higher) or Clang.  Other
-versions of GCC will probably work as well.  GCC versions listed here are known
-to not work.  If you are using one of these versions, please try to upgrade your
-GCC to something more recent.  If you run into a problem with a version of GCC
-not listed here, please `let us know <mailto:llvmdev@cs.uiuc.edu>`_.  Please use
-the "``gcc -v``" command to find out which version of GCC you are using.
-
-**GCC versions prior to 3.0**: GCC 2.96.x and before had several problems in the
-STL that effectively prevent it from compiling LLVM.
-
-**GCC 3.2.2 and 3.2.3**: These versions of GCC fails to compile LLVM with a
-bogus template error.  This was fixed in later GCCs.
-
-**GCC 3.3.2**: This version of GCC suffered from a `serious bug
-<http://gcc.gnu.org/PR13392>`_ which causes it to crash in the
-"``convert_from_eh_region_ranges_1``" GCC function.
-
-**Cygwin GCC 3.3.3**: The version of GCC 3.3.3 commonly shipped with Cygwin does
-not work.
-
-**SuSE GCC 3.3.3**: The version of GCC 3.3.3 shipped with SuSE 9.1 (and possibly
-others) does not compile LLVM correctly (it appears that exception handling is
-broken in some cases).  Please download the FSF 3.3.3 or upgrade to a newer
-version of GCC.
-
-**GCC 3.4.0 on linux/x86 (32-bit)**: GCC miscompiles portions of the code
-generator, causing an infinite loop in the llvm-gcc build when built with
-optimizations enabled (i.e. a release build).
-
-**GCC 3.4.2 on linux/x86 (32-bit)**: GCC miscompiles portions of the code
-generator at -O3, as with 3.4.0.  However gcc 3.4.2 (unlike 3.4.0) correctly
-compiles LLVM at -O2.  A work around is to build release LLVM builds with
-"``make ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION=-O2 ...``"
-
-**GCC 3.4.x on X86-64/amd64**: GCC `miscompiles portions of LLVM
-<http://llvm.org/PR1056>`__.
-
-**GCC 3.4.4 (CodeSourcery ARM 2005q3-2)**: this compiler miscompiles LLVM when
-building with optimizations enabled.  It appears to work with "``make
-ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION=-O1``" or build a debug build.
-
-**IA-64 GCC 4.0.0**: The IA-64 version of GCC 4.0.0 is known to miscompile LLVM.
-
-**Apple Xcode 2.3**: GCC crashes when compiling LLVM at -O3 (which is the
-default with ENABLE_OPTIMIZED=1.  To work around this, build with
-"``ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION=-O2``".
+bugs in the compiler. We are also planning to follow improvements and
+developments in the C++ language and library reasonably closely. As such, we
+require a modern host C++ toolchain, both compiler and standard library, in
+order to build LLVM.
 
-**GCC 4.1.1**: GCC fails to build LLVM with template concept check errors
-compiling some files.  At the time of this writing, GCC mainline (4.2) did not
-share the problem.
+For the most popular host toolchains we check for specific minimum versions in
+our build systems:
 
-**GCC 4.1.1 on X86-64/amd64**: GCC `miscompiles portions of LLVM
-<http://llvm.org/PR1063>`__ when compiling llvm itself into 64-bit code.  LLVM
-will appear to mostly work but will be buggy, e.g. failing portions of its
-testsuite.
+* Clang 3.1
+* GCC 4.7
+* Visual Studio 2012
 
-**GCC 4.1.2 on OpenSUSE**: Seg faults during libstdc++ build and on x86_64
-platforms compiling md5.c gets a mangled constant.
+Anything older than these toolchains *may* work, but will require forcing the
+build system with a special option and is not really a supported host platform.
+Also note that older versions of these compilers have often crashed or
+miscompiled LLVM.
 
-**GCC 4.1.2 (20061115 (prerelease) (Debian 4.1.1-21)) on Debian**: Appears to
-miscompile parts of LLVM 2.4. One symptom is ValueSymbolTable complaining about
-symbols remaining in the table on destruction.
+For less widely used host toolchains such as ICC or xlC, be aware that a very
+recent version may be required to support all of the C++ features used in LLVM.
 
-**GCC 4.1.2 20071124 (Red Hat 4.1.2-42)**: Suffers from the same symptoms as the
-previous one. It appears to work with ENABLE_OPTIMIZED=0 (the default).
-
-**Cygwin GCC 4.3.2 20080827 (beta) 2**: Users `reported
-<http://llvm.org/PR4145>`_ various problems related with link errors when using
-this GCC version.
-
-**Debian GCC 4.3.2 on X86**: Crashes building some files in LLVM 2.6.
-
-**GCC 4.3.3 (Debian 4.3.3-10) on ARM**: Miscompiles parts of LLVM 2.6 when
-optimizations are turned on. The symptom is an infinite loop in
-``FoldingSetImpl::RemoveNode`` while running the code generator.
-
-**SUSE 11 GCC 4.3.4**: Miscompiles LLVM, causing crashes in ValueHandle logic.
-
-**GCC 4.3.5 and GCC 4.4.5 on ARM**: These can miscompile ``value >> 1`` even at
-``-O0``. A test failure in ``test/Assembler/alignstack.ll`` is one symptom of
-the problem.
+We track certain versions of software that are *known* to fail when used as
+part of the host toolchain. These even include linkers at times.
 
 **GCC 4.6.3 on ARM**: Miscompiles ``llvm-readobj`` at ``-O3``. A test failure
 in ``test/Object/readobj-shared-object.test`` is one symptom of the problem.
@@ -391,6 +270,81 @@ recommend using the system GCC to compile LLVM and Clang in this case.
 **Clang 3.0 on Mageia 2**.  There's a packaging issue: Clang can not find at
 least some (``cxxabi.h``) libstdc++ headers.
 
+**Clang in C++11 mode and libstdc++ 4.7.2**.  This version of libstdc++
+contained `a bug <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53841>`__ which
+causes Clang to refuse to compile condition_variable header file.  At the time
+of writing, this breaks LLD build.
+
+Getting a Modern Host C++ Toolchain
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+This section mostly applies to Linux and older BSDs. On Mac OS X, you should
+have a sufficiently modern Xcode, or you will likely need to upgrade until you
+do. On Windows, just use Visual Studio 2012 as the host compiler, it is
+explicitly supported and widely available. FreeBSD 10.0 and newer have a modern
+Clang as the system compiler.
+
+However, some Linux distributions and some other or older BSDs sometimes have
+extremely old versions of GCC. These steps attempt to help you upgrade you
+compiler even on such a system. However, if at all possible, we encourage you
+to use a recent version of a distribution with a modern system compiler that
+meets these requirements. Note that it is tempting to to install a prior
+version of Clang and libc++ to be the host compiler, however libc++ was not
+well tested or set up to build on Linux until relatively recently. As
+a consequence, this guide suggests just using libstdc++ and a modern GCC as the
+initial host in a bootstrap, and then using Clang (and potentially libc++).
+
+The first step is to get a recent GCC toolchain installed. The most common
+distribution on which users have struggled with the version requirements is
+Ubuntu Precise, 12.04 LTS. For this distribution, one easy option is to install
+the `toolchain testing PPA`_ and use it to install a modern GCC. There is
+a really nice discussions of this on the `ask ubuntu stack exchange`_. However,
+not all users can use PPAs and there are many other distributions, so it may be
+necessary (or just useful, if you're here you *are* doing compiler development
+after all) to build and install GCC from source. It is also quite easy to do
+these days.
+
+.. _toolchain testing PPA:
+  https://launchpad.net/~ubuntu-toolchain-r/+archive/test
+.. _ask ubuntu stack exchange:
+  http://askubuntu.com/questions/271388/how-to-install-gcc-4-8-in-ubuntu-12-04-from-the-terminal
+
+Easy steps for installing GCC 4.8.2:
+
+.. code-block:: console
+
+  % wget ftp://ftp.gnu.org/gnu/gcc/gcc-4.8.2/gcc-4.8.2.tar.bz2
+  % tar -xvjf gcc-4.8.2.tar.bz2
+  % cd gcc-4.8.2
+  % ./contrib/download_prerequisites
+  % cd ..
+  % mkdir gcc-4.8.2-build
+  % cd gcc-4.8.2-build
+  % $PWD/../gcc-4.8.2/configure --prefix=$HOME/toolchains --enable-languages=c,c++
+  % make -j$(nproc)
+  % make install
+
+For more details, check out the excellent `GCC wiki entry`_, where I got most
+of this information from.
+
+.. _GCC wiki entry:
+  http://gcc.gnu.org/wiki/InstallingGCC
+
+Once you have a GCC toolchain, use it as your host compiler. Things should
+generally "just work". You may need to pass a special linker flag,
+``-Wl,-rpath,$HOME/toolchains/lib`` or some variant thereof to get things to
+find the libstdc++ DSO in this toolchain.
+
+When you build Clang, you will need to give *it* access to modern C++11
+standard library in order to use it as your new host in part of a bootstrap.
+There are two easy ways to do this, either build (and install) libc++ along
+with Clang and then use it with the ``-stdlib=libc++`` compile and link flag,
+or install Clang into the same prefix (``$HOME/toolchains`` above) as GCC.
+Clang will look within its own prefix for libstdc++ and use it if found. You
+can also add an explicit prefix for Clang to look in for a GCC toolchain with
+the ``--gcc-toolchain=/opt/my/gcc/prefix`` flag, passing it to both compile and
+link commands when using your just-built-Clang to bootstrap.
+
 .. _Getting Started with LLVM:
 
 Getting Started with LLVM
@@ -479,6 +433,7 @@ you can checkout it from the '``tags``' directory (instead of '``trunk``'). The
 following releases are located in the following subdirectories of the '``tags``'
 directory:
 
+* Release 3.4: **RELEASE_34/final**
 * Release 3.3: **RELEASE_33/final**
 * Release 3.2: **RELEASE_32/final**
 * Release 3.1: **RELEASE_31/final**
@@ -1123,8 +1078,7 @@ different `tools`_.
 
 This directory contains projects that are not strictly part of LLVM but are
 shipped with LLVM. This is also the directory where you should create your own
-LLVM-based projects. See ``llvm/projects/sample`` for an example of how to set
-up your own project.
+LLVM-based projects.
 
 ``llvm/runtime``
 ----------------
diff --git a/docs/GettingStartedVS.rst b/docs/GettingStartedVS.rst
index c46dc83..628bfdc 100644
--- a/docs/GettingStartedVS.rst
+++ b/docs/GettingStartedVS.rst
@@ -45,15 +45,13 @@ and software you will need.
 
 Hardware
 --------
-Any system that can adequately run Visual Studio 2010 is fine. The LLVM
+Any system that can adequately run Visual Studio 2012 is fine. The LLVM
 source tree and object files, libraries and executables will consume
 approximately 3GB.
 
 Software
 --------
-You will need Visual Studio 2010 or higher.  Earlier versions of Visual
-Studio have bugs, are not completely compatible, or do not support the C++
-standard well enough.
+You will need Visual Studio 2012 or higher.
 
 You will also need the `CMake <http://www.cmake.org/>`_ build system since it
 generates the project files you will use to build with.
@@ -121,16 +119,14 @@ Here's the short story for getting up and running quickly with LLVM:
      or run it from the command line.  The program will print the
      corresponding fibonacci value.
 
-8. Test LLVM on Visual Studio:
+8. Test LLVM in Visual Studio:
 
    * If ``%PATH%`` does not contain GnuWin32, you may specify
      ``LLVM_LIT_TOOLS_DIR`` on CMake for the path to GnuWin32.
    * You can run LLVM tests by merely building the project "check". The test
      results will be shown in the VS output window.
 
-.. FIXME: Is it up-to-date?
-
-9. Test LLVM:
+9. Test LLVM on the command line:
 
    * The LLVM tests can be run by changing directory to the llvm source
      directory and running:
diff --git a/docs/HowToReleaseLLVM.rst b/docs/HowToReleaseLLVM.rst
index bc3b093..61aa9e8 100644
--- a/docs/HowToReleaseLLVM.rst
+++ b/docs/HowToReleaseLLVM.rst
@@ -22,12 +22,15 @@ create the binary packages, please refer to the :doc:`ReleaseProcess` instead.
 Release Timeline
 ================
 
-LLVM is released on a time based schedule --- roughly every 6 months.  We do
-not normally have dot releases because of the nature of LLVM's incremental
-development philosophy.  That said, the only thing preventing dot releases for
-critical bug fixes from happening is a lack of resources --- testers,
-machines, time, etc.  And, because of the high quality we desire for LLVM
-releases, we cannot allow for a truncated form of release qualification.
+LLVM is released on a time based schedule --- with major releases roughly
+every 6 months.  In between major releases there may be dot releases.
+The release manager will determine if and when to make a dot release based
+on feedback from the community.  Typically, dot releases should be made if
+there are large number of bug-fixes in the stable branch or a critical bug
+has been discovered that affects a large number of users.
+
+Unless otherwise stated, dot releases will follow the same procedure as
+major releases.
 
 The release process is roughly as follows:
 
@@ -51,6 +54,10 @@ The release process is roughly as follows:
 
 * Finally, release!
 
+The release process will be accelerated for dot releases.  If the first round
+of testing finds no critical bugs and no regressions since the last major release,
+then additional rounds of testing will not be required.
+
 Release Process
 ===============
 
@@ -238,6 +245,8 @@ when qualifying the build of ``llvm``, ``clang``, and ``dragonegg``.
 +--------------+---------------+----------------------+
 | x86-64       | FreeBSD       | gcc 4.2.X            |
 +--------------+---------------+----------------------+
+| ARMv7        | Linux         | gcc 4.6.X, gcc 4.7.X |
++--------------+---------------+----------------------+
 
 Release Qualification Criteria
 ------------------------------
@@ -298,6 +307,10 @@ Specific Target Qualification Details
 |              |             |                | clang regression tests,     |
 |              |             |                | test-suite                  |
 +--------------+-------------+----------------+-----------------------------+
+| ARMv7A       | Linux       | last release   | llvm regression tests,      |
+|              |             |                | clang regression tests,     |
+|              |             |                | test-suite                  |
++--------------+-------------+----------------+-----------------------------+
 
 Community Testing
 -----------------
@@ -346,6 +359,9 @@ Below are the rules regarding patching the release branch:
 #. During the remaining rounds of testing, only patches that fix critical
    regressions may be applied.
 
+#. For dot releases all patches must mantain both API and ABI compatibility with
+   the previous major release.  Only bugfixes will be accepted.
+
 Release Final Tasks
 -------------------
 
diff --git a/docs/HowToSetUpLLVMStyleRTTI.rst b/docs/HowToSetUpLLVMStyleRTTI.rst
index e0f865a..96275e7 100644
--- a/docs/HowToSetUpLLVMStyleRTTI.rst
+++ b/docs/HowToSetUpLLVMStyleRTTI.rst
@@ -223,8 +223,8 @@ steps:
         [...]
         template <class T>
         static bool classof(const T *,
-                            ::llvm::enable_if_c<
-                              ::llvm::is_base_of<Foo, T>::value
+                            ::std::enable_if<
+                              ::std::is_base_of<Foo, T>::value
                             >::type* = 0) { return true; }
         [...]
       };
diff --git a/docs/HowToSubmitABug.rst b/docs/HowToSubmitABug.rst
index 45be282..702dc0c 100644
--- a/docs/HowToSubmitABug.rst
+++ b/docs/HowToSubmitABug.rst
@@ -43,15 +43,15 @@ the LLVM libraries (e.g. the optimizer or code generator) that has
 problems.
 
 To figure out which component is crashing (the front-end, optimizer or code
-generator), run the ``llvm-gcc`` command line as you were when the crash
+generator), run the ``clang`` command line as you were when the crash
 occurred, but with the following extra command line options:
 
-* ``-O0 -emit-llvm``: If ``llvm-gcc`` still crashes when passed these
+* ``-O0 -emit-llvm``: If ``clang`` still crashes when passed these
   options (which disable the optimizer and code generator), then the crash
   is in the front-end.  Jump ahead to the section on :ref:`front-end bugs
   <front-end>`.
 
-* ``-emit-llvm``: If ``llvm-gcc`` crashes with this option (which disables
+* ``-emit-llvm``: If ``clang`` crashes with this option (which disables
   the code generator), you found an optimizer bug.  Jump ahead to
   `compile-time optimization bugs`_.
 
@@ -64,12 +64,12 @@ occurred, but with the following extra command line options:
 Front-end bugs
 --------------
 
-If the problem is in the front-end, you should re-run the same ``llvm-gcc``
+If the problem is in the front-end, you should re-run the same ``clang``
 command that resulted in the crash, but add the ``-save-temps`` option.
 The compiler will crash again, but it will leave behind a ``foo.i`` file
 (containing preprocessed C source code) and possibly ``foo.s`` for each
 compiled ``foo.c`` file. Send us the ``foo.i`` file, along with the options
-you passed to ``llvm-gcc``, and a brief description of the error it caused.
+you passed to ``clang``, and a brief description of the error it caused.
 
 The `delta <http://delta.tigris.org/>`_ tool helps to reduce the
 preprocessed file down to the smallest amount of code that still replicates
@@ -92,7 +92,7 @@ Then run:
    opt -std-compile-opts -debug-pass=Arguments foo.bc -disable-output
 
 This command should do two things: it should print out a list of passes, and
-then it should crash in the same way as llvm-gcc.  If it doesn't crash, please
+then it should crash in the same way as clang.  If it doesn't crash, please
 follow the instructions for a `front-end bug`_.
 
 If this does crash, then you should be able to debug this with the following
@@ -111,9 +111,9 @@ submit the "foo.bc" file and the list of passes printed by ``opt``.
 Code generator bugs
 -------------------
 
-If you find a bug that crashes llvm-gcc in the code generator, compile your
+If you find a bug that crashes clang in the code generator, compile your
 source file to a .bc file by passing "``-emit-llvm -c -o foo.bc``" to
-llvm-gcc (in addition to the options you already pass).  Once your have
+clang (in addition to the options you already pass).  Once your have
 foo.bc, one of the following commands should fail:
 
 #. ``llc foo.bc``
@@ -138,7 +138,7 @@ the "foo.bc" file and the option that llc crashes with.
 Miscompilations
 ===============
 
-If llvm-gcc successfully produces an executable, but that executable
+If clang successfully produces an executable, but that executable
 doesn't run right, this is either a bug in the code or a bug in the
 compiler.  The first thing to check is to make sure it is not using
 undefined behavior (e.g. reading a variable before it is defined). In
diff --git a/docs/InAlloca.rst b/docs/InAlloca.rst
new file mode 100644
index 0000000..c7609cd
--- /dev/null
+++ b/docs/InAlloca.rst
@@ -0,0 +1,160 @@
+==========================================
+Design and Usage of the InAlloca Attribute
+==========================================
+
+Introduction
+============
+
+The :ref:`inalloca <attr_inalloca>` attribute is designed to allow
+taking the address of an aggregate argument that is being passed by
+value through memory.  Primarily, this feature is required for
+compatibility with the Microsoft C++ ABI.  Under that ABI, class
+instances that are passed by value are constructed directly into
+argument stack memory.  Prior to the addition of inalloca, calls in LLVM
+were indivisible instructions.  There was no way to perform intermediate
+work, such as object construction, between the first stack adjustment
+and the final control transfer.  With inalloca, all arguments passed in
+memory are modelled as a single alloca, which can be stored to prior to
+the call.  Unfortunately, this complicated feature comes with a large
+set of restrictions designed to bound the lifetime of the argument
+memory around the call.
+
+For now, it is recommended that frontends and optimizers avoid producing
+this construct, primarily because it forces the use of a base pointer.
+This feature may grow in the future to allow general mid-level
+optimization, but for now, it should be regarded as less efficient than
+passing by value with a copy.
+
+Intended Usage
+==============
+
+The example below is the intended LLVM IR lowering for some C++ code
+that passes two default-constructed ``Foo`` objects to ``g`` in the
+32-bit Microsoft C++ ABI.
+
+.. code-block:: c++
+
+    // Foo is non-trivial.
+    struct Foo { int a, b; Foo(); ~Foo(); Foo(const Foo &); };
+    void g(Foo a, Foo b);
+    void f() {
+      g(Foo(), Foo());
+    }
+
+.. code-block:: llvm
+
+    %struct.Foo = type { i32, i32 }
+    declare void @Foo_ctor(%struct.Foo* %this)
+    declare void @Foo_dtor(%struct.Foo* %this)
+    declare void @g(<{ %struct.Foo, %struct.Foo }>* inalloca %memargs)
+
+    define void @f() {
+    entry:
+      %base = call i8* @llvm.stacksave()
+      %memargs = alloca <{ %struct.Foo, %struct.Foo }>
+      %b = getelementptr <{ %struct.Foo, %struct.Foo }>* %memargs, i32 1
+      call void @Foo_ctor(%struct.Foo* %b)
+
+      ; If a's ctor throws, we must destruct b.
+      %a = getelementptr <{ %struct.Foo, %struct.Foo }>* %memargs, i32 0
+      invoke void @Foo_ctor(%struct.Foo* %a)
+          to label %invoke.cont unwind %invoke.unwind
+
+    invoke.cont:
+      call void @g(<{ %struct.Foo, %struct.Foo }>* inalloca %memargs)
+      call void @llvm.stackrestore(i8* %base)
+      ...
+
+    invoke.unwind:
+      call void @Foo_dtor(%struct.Foo* %b)
+      call void @llvm.stackrestore(i8* %base)
+      ...
+    }
+
+To avoid stack leaks, the frontend saves the current stack pointer with
+a call to :ref:`llvm.stacksave <int_stacksave>`.  Then, it allocates the
+argument stack space with alloca and calls the default constructor.  The
+default constructor could throw an exception, so the frontend has to
+create a landing pad.  The frontend has to destroy the already
+constructed argument ``b`` before restoring the stack pointer.  If the
+constructor does not unwind, ``g`` is called.  In the Microsoft C++ ABI,
+``g`` will destroy its arguments, and then the stack is restored in
+``f``.
+
+Design Considerations
+=====================
+
+Lifetime
+--------
+
+The biggest design consideration for this feature is object lifetime.
+We cannot model the arguments as static allocas in the entry block,
+because all calls need to use the memory at the top of the stack to pass
+arguments.  We cannot vend pointers to that memory at function entry
+because after code generation they will alias.
+
+The rule against allocas between argument allocations and the call site
+avoids this problem, but it creates a cleanup problem.  Cleanup and
+lifetime is handled explicitly with stack save and restore calls.  In
+the future, we may want to introduce a new construct such as ``freea``
+or ``afree`` to make it clear that this stack adjusting cleanup is less
+powerful than a full stack save and restore.
+
+Nested Calls and Copy Elision
+-----------------------------
+
+We also want to be able to support copy elision into these argument
+slots.  This means we have to support multiple live argument
+allocations.
+
+Consider the evaluation of:
+
+.. code-block:: c++
+
+    // Foo is non-trivial.
+    struct Foo { int a; Foo(); Foo(const &Foo); ~Foo(); };
+    Foo bar(Foo b);
+    int main() {
+      bar(bar(Foo()));
+    }
+
+In this case, we want to be able to elide copies into ``bar``'s argument
+slots.  That means we need to have more than one set of argument frames
+active at the same time.  First, we need to allocate the frame for the
+outer call so we can pass it in as the hidden struct return pointer to
+the middle call.  Then we do the same for the middle call, allocating a
+frame and passing its address to ``Foo``'s default constructor.  By
+wrapping the evaluation of the inner ``bar`` with stack save and
+restore, we can have multiple overlapping active call frames.
+
+Callee-cleanup Calling Conventions
+----------------------------------
+
+Another wrinkle is the existence of callee-cleanup conventions.  On
+Windows, all methods and many other functions adjust the stack to clear
+the memory used to pass their arguments.  In some sense, this means that
+the allocas are automatically cleared by the call.  However, LLVM
+instead models this as a write of undef to all of the inalloca values
+passed to the call instead of a stack adjustment.  Frontends should
+still restore the stack pointer to avoid a stack leak.
+
+Exceptions
+----------
+
+There is also the possibility of an exception.  If argument evaluation
+or copy construction throws an exception, the landing pad must do
+cleanup, which includes adjusting the stack pointer to avoid a stack
+leak.  This means the cleanup of the stack memory cannot be tied to the
+call itself.  There needs to be a separate IR-level instruction that can
+perform independent cleanup of arguments.
+
+Efficiency
+----------
+
+Eventually, it should be possible to generate efficient code for this
+construct.  In particular, using inalloca should not require a base
+pointer.  If the backend can prove that all points in the CFG only have
+one possible stack level, then it can address the stack directly from
+the stack pointer.  While this is not yet implemented, the plan is that
+the inalloca attribute should not change much, but the frontend IR
+generation recommendations may change.
diff --git a/docs/LLVMBuild.rst b/docs/LLVMBuild.rst
index 040b044..c0c96d3 100644
--- a/docs/LLVMBuild.rst
+++ b/docs/LLVMBuild.rst
@@ -315,7 +315,7 @@ the properties which are associated with that component.
 
    ``BuildTool`` components are like ``Tool`` components, except that the
    tool is supposed to be built for the platform where the build is running
-   (instead of that platform being targetted). Build systems are expected
+   (instead of that platform being targeted). Build systems are expected
    to handle the fact that required libraries may need to be built for
    multiple platforms in order to be able to link this tool.
 
diff --git a/docs/LangRef.rst b/docs/LangRef.rst
index 810455c..91692ad 100644
--- a/docs/LangRef.rst
+++ b/docs/LangRef.rst
@@ -4,7 +4,7 @@ LLVM Language Reference Manual
 
 .. contents::
    :local:
-   :depth: 3
+   :depth: 4
 
 Abstract
 ========
@@ -197,16 +197,6 @@ linkage:
     private to be renamed as necessary to avoid collisions. Because the
     symbol is private to the module, all references can be updated. This
     doesn't show up in any symbol table in the object file.
-``linker_private``
-    Similar to ``private``, but the symbol is passed through the
-    assembler and evaluated by the linker. Unlike normal strong symbols,
-    they are removed by the linker from the final linked image
-    (executable or dynamic library).
-``linker_private_weak``
-    Similar to "``linker_private``", but the symbol is weak. Note that
-    ``linker_private_weak`` symbols are subject to coalescing by the
-    linker. The symbols are removed by the linker from the final linked
-    image (executable or dynamic library).
 ``internal``
     Similar to private, but the value shows as a local symbol
     (``STB_LOCAL`` in the case of ELF) in the object file. This
@@ -274,31 +264,8 @@ linkage:
     visible, meaning that it participates in linkage and can be used to
     resolve external symbol references.
 
-The next two types of linkage are targeted for Microsoft Windows
-platform only. They are designed to support importing (exporting)
-symbols from (to) DLLs (Dynamic Link Libraries).
-
-``dllimport``
-    "``dllimport``" linkage causes the compiler to reference a function
-    or variable via a global pointer to a pointer that is set up by the
-    DLL exporting the symbol. On Microsoft Windows targets, the pointer
-    name is formed by combining ``__imp_`` and the function or variable
-    name.
-``dllexport``
-    "``dllexport``" linkage causes the compiler to provide a global
-    pointer to a pointer in a DLL, so that it can be referenced with the
-    ``dllimport`` attribute. On Microsoft Windows targets, the pointer
-    name is formed by combining ``__imp_`` and the function or variable
-    name.
-
-For example, since the "``.LC0``" variable is defined to be internal, if
-another module defined a "``.LC0``" variable and was linked with this
-one, one of the two would be renamed, preventing a collision. Since
-"``main``" and "``puts``" are external (i.e., lacking any linkage
-declarations), they are accessible outside of the current module.
-
 It is illegal for a function *declaration* to have any linkage type
-other than ``external``, ``dllimport`` or ``extern_weak``.
+other than ``external`` or ``extern_weak``.
 
 .. _callingconv:
 
@@ -335,7 +302,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>`_.
@@ -370,6 +338,72 @@ 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`.
+"``preserve_mostcc``" - The `PreserveMost` calling convention
+    This calling convention attempts to make the code in the caller as little
+    intrusive as possible. This calling convention behaves identical to the `C`
+    calling convention on how arguments and return values are passed, but it
+    uses a different set of caller/callee-saved registers. This alleviates the
+    burden of saving and recovering a large register set before and after the
+    call in the caller. If the arguments are passed in callee-saved registers,
+    then they will be preserved by the callee across the call. This doesn't
+    apply for values returned in callee-saved registers.
+
+    - On X86-64 the callee preserves all general purpose registers, except for
+      R11. R11 can be used as a scratch register. Floating-point registers
+      (XMMs/YMMs) are not preserved and need to be saved by the caller.
+
+    The idea behind this convention is to support calls to runtime functions
+    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. 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.
+    Although this convention was created to optimize certain runtime calls to
+    the ObjectiveC runtime, it is not limited to this runtime and might be used
+    by other runtimes in the future too. The current implementation only
+    supports X86-64, but the intention is to support more architectures in the
+    future.
+"``preserve_allcc``" - The `PreserveAll` calling convention
+    This calling convention attempts to make the code in the caller even less
+    intrusive than the `PreserveMost` calling convention. This calling
+    convention also behaves identical to the `C` calling convention on how
+    arguments and return values are passed, but it uses a different set of
+    caller/callee-saved registers. This removes the burden of saving and
+    recovering a large register set before and after the call in the caller. If
+    the arguments are passed in callee-saved registers, then they will be
+    preserved by the callee across the call. This doesn't apply for values
+    returned in callee-saved registers.
+
+    - On X86-64 the callee preserves all general purpose registers, except for
+      R11. R11 can be used as a scratch register. Furthermore it also preserves
+      all floating-point registers (XMMs/YMMs).
+
+    The idea behind this convention is to support calls to runtime functions
+    that don't need to call out to any other functions.
+
+    This calling convention, like the `PreserveMost` calling convention, will be
+    used by a future version of the ObjectiveC runtime and should be considered
+    experimental at this time.
 "``cc <n>``" - Numbered convention
     Any calling convention may be specified by number, allowing
     target-specific calling conventions to be used. Target specific
@@ -408,31 +442,41 @@ styles:
 
 .. _namedtypes:
 
-Named Types
------------
+DLL Storage Classes
+-------------------
+
+All Global Variables, Functions and Aliases can have one of the following
+DLL storage class:
+
+``dllimport``
+    "``dllimport``" causes the compiler to reference a function or variable via
+    a global pointer to a pointer that is set up by the DLL exporting the
+    symbol. On Microsoft Windows targets, the pointer name is formed by
+    combining ``__imp_`` and the function or variable name.
+``dllexport``
+    "``dllexport``" causes the compiler to provide a global pointer to a pointer
+    in a DLL, so that it can be referenced with the ``dllimport`` attribute. On
+    Microsoft Windows targets, the pointer name is formed by combining
+    ``__imp_`` and the function or variable name. Since this storage class
+    exists for defining a dll interface, the compiler, assembler and linker know
+    it is externally referenced and must refrain from deleting the symbol.
+
+Structure Types
+---------------
 
-LLVM IR allows you to specify name aliases for certain types. This can
-make it easier to read the IR and make the IR more condensed
-(particularly when recursive types are involved). An example of a name
-specification is:
+LLVM IR allows you to specify both "identified" and "literal" :ref:`structure
+types <t_struct>`.  Literal types are uniqued structurally, but identified types
+are never uniqued.  An :ref:`opaque structural type <t_opaque>` can also be used
+to forward declare a type which is not yet available.
+
+An example of a identified structure specification is:
 
 .. code-block:: llvm
 
     %mytype = type { %mytype*, i32 }
 
-You may give a name to any :ref:`type <typesystem>` except
-":ref:`void <t_void>`". Type name aliases may be used anywhere a type is
-expected with the syntax "%mytype".
-
-Note that type names are aliases for the structural type that they
-indicate, and that you can therefore specify multiple names for the same
-type. This often leads to confusing behavior when dumping out a .ll
-file. Since LLVM IR uses structural typing, the name is not part of the
-type. When printing out LLVM IR, the printer will pick *one name* to
-render all types of a particular shape. This means that if you have code
-where two different source types end up having the same LLVM type, that
-the dumper will sometimes print the "wrong" or unexpected type. This is
-an important design point and isn't going to change.
+Prior to the LLVM 3.0 release, identified types were structurally uniqued.  Only
+literal types are uniqued in recent versions of LLVM.
 
 .. _globalvars:
 
@@ -507,8 +551,8 @@ variables defined within the module are not modified from their
 initial values before the start of the global initializer.  This is
 true even for variables potentially accessible from outside the
 module, including those with external linkage or appearing in
-``@llvm.used``. This assumption may be suppressed by marking the
-variable with ``externally_initialized``.
+``@llvm.used`` or dllexported variables. This assumption may be suppressed
+by marking the variable with ``externally_initialized``.
 
 An explicit alignment may be specified for a global, which must be a
 power of 2. If not present, or if the alignment is set to zero, the
@@ -521,6 +565,15 @@ assume that the globals are densely packed in their section and try to
 iterate over them as an array, alignment padding would break this
 iteration.
 
+Globals can also have a :ref:`DLL storage class <dllstorageclass>`.
+
+Syntax::
+
+    [@<GlobalVarName> =] [Linkage] [Visibility] [DLLStorageClass] [ThreadLocal]
+                         [AddrSpace] [unnamed_addr] [ExternallyInitialized]
+                         <global | constant> <Type>
+                         [, section "name"] [, align <Alignment>]
+
 For example, the following defines a global in a numbered address space
 with an initializer, section, and alignment:
 
@@ -548,7 +601,8 @@ Functions
 
 LLVM function definitions consist of the "``define``" keyword, an
 optional :ref:`linkage type <linkage>`, an optional :ref:`visibility
-style <visibility>`, an optional :ref:`calling convention <callingconv>`,
+style <visibility>`, an optional :ref:`DLL storage class <dllstorageclass>`,
+an optional :ref:`calling convention <callingconv>`,
 an optional ``unnamed_addr`` attribute, a return type, an optional
 :ref:`parameter attribute <paramattrs>` for the return type, a function
 name, a (possibly empty) argument list (each with optional :ref:`parameter
@@ -559,7 +613,8 @@ curly brace, a list of basic blocks, and a closing curly brace.
 
 LLVM function declarations consist of the "``declare``" keyword, an
 optional :ref:`linkage type <linkage>`, an optional :ref:`visibility
-style <visibility>`, an optional :ref:`calling convention <callingconv>`,
+style <visibility>`, an optional :ref:`DLL storage class <dllstorageclass>`,
+an optional :ref:`calling convention <callingconv>`,
 an optional ``unnamed_addr`` attribute, a return type, an optional
 :ref:`parameter attribute <paramattrs>` for the return type, a function
 name, a possibly empty list of arguments, an optional alignment, an optional
@@ -595,10 +650,10 @@ be significant and two identical functions can be merged.
 
 Syntax::
 
-    define [linkage] [visibility]
+    define [linkage] [visibility] [DLLStorageClass]
            [cconv] [ret attrs]
            <ResultType> @<FunctionName> ([argument list])
-           [fn Attrs] [section "name"] [align N]
+           [unnamed_addr] [fn Attrs] [section "name"] [align N]
            [gc] [prefix Constant] { ... }
 
 .. _langref_aliases:
@@ -608,19 +663,28 @@ Aliases
 
 Aliases act as "second name" for the aliasee value (which can be either
 function, global variable, another alias or bitcast of global value).
-Aliases may have an optional :ref:`linkage type <linkage>`, and an optional
-:ref:`visibility style <visibility>`.
+Aliases may have an optional :ref:`linkage type <linkage>`, an optional
+:ref:`visibility style <visibility>`, and an optional :ref:`DLL storage class
+<dllstorageclass>`.
 
 Syntax::
 
-    @<Name> = alias [Linkage] [Visibility] <AliaseeTy> @<Aliasee>
+    @<Name> = [Visibility] [DLLStorageClass] alias [Linkage] <AliaseeTy> @<Aliasee>
 
-The linkage must be one of ``private``, ``linker_private``,
-``linker_private_weak``, ``internal``, ``linkonce``, ``weak``,
+The linkage must be one of ``private``, ``internal``, ``linkonce``, ``weak``,
 ``linkonce_odr``, ``weak_odr``, ``external``. Note that some system linkers
-might not correctly handle dropping a weak symbol that is aliased by a non weak
+might not correctly handle dropping a weak symbol that is aliased by a non-weak
 alias.
 
+Alias that are not ``unnamed_addr`` are guaranteed to have the same address as
+the aliasee.
+
+The aliasee must be a definition.
+
+Aliases are not allowed to point to aliases with linkages that can be
+overridden. Since they are only a second name, the possibility of the
+intermediate alias being overridden cannot be represented in an object file.
+
 .. _namedmetadatastructure:
 
 Named Metadata
@@ -701,6 +765,35 @@ 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``
+
+    The ``inalloca`` argument attribute allows the caller to take the
+    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``.  The
+    ``inalloca`` attribute also disables LLVM's implicit lowering of
+    large aggregate return values, which means that frontend authors
+    must lower them with ``sret`` pointers.
+
+    When the call site is reached, the argument allocation must have
+    been the most recent stack allocation that is still live, or the
+    results are undefined.  It is possible to allocate additional stack
+    space after an argument allocation and before its call site, but it
+    must be cleared off with :ref:`llvm.stackrestore
+    <int_stackrestore>`.
+
+    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
@@ -1006,6 +1099,9 @@ example:
     - Calls to alloca() with variable sizes or constant sizes greater than
       ``ssp-buffer-size``.
 
+    Variables that are identified as requiring a protector will be arranged
+    on the stack such that they are adjacent to the stack protector guard.
+
     If a function that has an ``ssp`` attribute is inlined into a
     function that doesn't have an ``ssp`` attribute, then the resulting
     function will have an ``ssp`` attribute.
@@ -1014,6 +1110,17 @@ example:
     stack smashing protector. This overrides the ``ssp`` function
     attribute.
 
+    Variables that are identified as requiring a protector will be arranged
+    on the stack such that they are adjacent to the stack protector guard.
+    The specific layout rules are:
+
+    #. Large arrays and structures containing large arrays
+       (``>= ssp-buffer-size``) are closest to the stack protector.
+    #. Small arrays and structures containing small arrays
+       (``< ssp-buffer-size``) are 2nd closest to the protector.
+    #. Variables that have had their address taken are 3rd closest to the
+       protector.
+
     If a function that has an ``sspreq`` attribute is inlined into a
     function that doesn't have an ``sspreq`` attribute or which has an
     ``ssp`` or ``sspstrong`` attribute, then the resulting function will have
@@ -1029,6 +1136,17 @@ example:
     - Calls to alloca().
     - Local variables that have had their address taken.
 
+    Variables that are identified as requiring a protector will be arranged
+    on the stack such that they are adjacent to the stack protector guard.
+    The specific layout rules are:
+
+    #. Large arrays and structures containing large arrays
+       (``>= ssp-buffer-size``) are closest to the stack protector.
+    #. Small arrays and structures containing small arrays
+       (``< ssp-buffer-size``) are 2nd closest to the protector.
+    #. Variables that have had their address taken are 3rd closest to the
+       protector.
+
     This overrides the ``ssp`` function attribute.
 
     If a function that has an ``sspstrong`` attribute is inlined into a
@@ -1100,10 +1218,9 @@ as follows:
 ``p[n]:<size>:<abi>:<pref>``
     This specifies the *size* of a pointer and its ``<abi>`` and
     ``<pref>``\erred alignments for address space ``n``. All sizes are in
-    bits. Specifying the ``<pref>`` alignment is optional. If omitted, the
-    preceding ``:`` should be omitted too. The address space, ``n`` is
-    optional, and if not specified, denotes the default address space 0.
-    The value of ``n`` must be in the range [1,2^23).
+    bits. The address space, ``n`` is optional, and if not specified,
+    denotes the default address space 0.  The value of ``n`` must be
+    in the range [1,2^23).
 ``i<size>:<abi>:<pref>``
     This specifies the alignment for an integer type of a given bit
     ``<size>``. The value of ``<size>`` must be in the range [1,2^23).
@@ -1116,12 +1233,18 @@ as follows:
     will work. 32 (float) and 64 (double) are supported on all targets; 80
     or 128 (different flavors of long double) are also supported on some
     targets.
-``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>``.
+``a:<abi>:<pref>``
+    This specifies the alignment for an object of aggregate type.
+``m:<mangling>``
+    If present, specifies that llvm names are mangled in the output. The
+    options are
+
+    * ``e``: ELF mangling: Private symbols get a ``.L`` prefix.
+    * ``m``: Mips mangling: Private symbols get a ``$`` prefix.
+    * ``o``: Mach-O mangling: Private symbols get ``L`` prefix. Other
+      symbols get a ``_`` prefix.
+    * ``w``: Windows COFF prefix:  Similar to Mach-O, but stdcall and fastcall
+      functions also get a suffix based on the frame 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,
@@ -1129,6 +1252,10 @@ as follows:
     this set are considered to support most general arithmetic operations
     efficiently.
 
+On every specification that takes a ``<abi>:<pref>``, specifying the
+``<pref>`` alignment is optional. If omitted, the preceding ``:``
+should be omitted too and ``<pref>`` will be equal to ``<abi>``.
+
 When constructing the data layout for a given target, LLVM starts with a
 default set of specifications which are then (possibly) overridden by
 the specifications in the ``datalayout`` keyword. The default
@@ -1151,7 +1278,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:
@@ -1365,7 +1492,7 @@ Atomic Memory Ordering Constraints
 Atomic instructions (:ref:`cmpxchg <i_cmpxchg>`,
 :ref:`atomicrmw <i_atomicrmw>`, :ref:`fence <i_fence>`,
 :ref:`atomic load <i_load>`, and :ref:`atomic store <i_store>`) take
-an ordering parameter that determines which other atomic instructions on
+ordering parameters that determine which other atomic instructions on
 the same address they *synchronize with*. These semantics are borrowed
 from Java and C++0x, but are somewhat more colloquial. If these
 descriptions aren't precise enough, check those specs (see spec
@@ -1480,80 +1607,90 @@ transformation. A strong type system makes it easier to read the
 generated code and enables novel analyses and transformations that are
 not feasible to perform on normal three address code representations.
 
-.. _typeclassifications:
+.. _t_void:
 
-Type Classifications
---------------------
+Void Type
+---------
 
-The types fall into a few useful classifications:
+:Overview:
 
 
-.. list-table::
-   :header-rows: 1
+The void type does not represent any value and has no size.
 
-   * - Classification
-     - Types
+:Syntax:
 
-   * - :ref:`integer <t_integer>`
-     - ``i1``, ``i2``, ``i3``, ... ``i8``, ... ``i16``, ... ``i32``, ...
-       ``i64``, ...
 
-   * - :ref:`floating point <t_floating>`
-     - ``half``, ``float``, ``double``, ``x86_fp80``, ``fp128``,
-       ``ppc_fp128``
+::
 
+      void
 
-   * - first class
 
-       .. _t_firstclass:
+.. _t_function:
 
-     - :ref:`integer <t_integer>`, :ref:`floating point <t_floating>`,
-       :ref:`pointer <t_pointer>`, :ref:`vector <t_vector>`,
-       :ref:`structure <t_struct>`, :ref:`array <t_array>`,
-       :ref:`label <t_label>`, :ref:`metadata <t_metadata>`.
+Function Type
+-------------
+
+:Overview:
+
+
+The function type can be thought of as a function signature. It consists of a
+return type and a list of formal parameter types. The return type of a function
+type is a void type or first class type --- except for :ref:`label <t_label>`
+and :ref:`metadata <t_metadata>` types.
+
+:Syntax:
+
+::
+
+      <returntype> (<parameter list>)
+
+...where '``<parameter list>``' is a comma-separated list of type
+specifiers. Optionally, the parameter list may include a type ``...``, which
+indicates that the function takes a variable number of arguments.  Variable
+argument functions can access their arguments with the :ref:`variable argument
+handling intrinsic <int_varargs>` functions.  '``<returntype>``' is any type
+except :ref:`label <t_label>` and :ref:`metadata <t_metadata>`.
 
-   * - :ref:`primitive <t_primitive>`
-     - :ref:`label <t_label>`,
-       :ref:`void <t_void>`,
-       :ref:`integer <t_integer>`,
-       :ref:`floating point <t_floating>`,
-       :ref:`x86mmx <t_x86mmx>`,
-       :ref:`metadata <t_metadata>`.
+:Examples:
 
-   * - :ref:`derived <t_derived>`
-     - :ref:`array <t_array>`,
-       :ref:`function <t_function>`,
-       :ref:`pointer <t_pointer>`,
-       :ref:`structure <t_struct>`,
-       :ref:`vector <t_vector>`,
-       :ref:`opaque <t_opaque>`.
++---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| ``i32 (i32)``                   | function taking an ``i32``, returning an ``i32``                                                                                                                    |
++---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| ``float (i16, i32 *) *``        | :ref:`Pointer <t_pointer>` to a function that takes an ``i16`` and a :ref:`pointer <t_pointer>` to ``i32``, returning ``float``.                                    |
++---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| ``i32 (i8*, ...)``              | A vararg function that takes at least one :ref:`pointer <t_pointer>` to ``i8`` (char in C), which returns an integer. This is the signature for ``printf`` in LLVM. |
++---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+| ``{i32, i32} (i32)``            | A function taking an ``i32``, returning a :ref:`structure <t_struct>` containing two ``i32`` values                                                                 |
++---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
+
+.. _t_firstclass:
+
+First Class Types
+-----------------
 
 The :ref:`first class <t_firstclass>` types are perhaps the most important.
 Values of these types are the only ones which can be produced by
 instructions.
 
-.. _t_primitive:
+.. _t_single_value:
 
-Primitive Types
----------------
+Single Value Types
+^^^^^^^^^^^^^^^^^^
 
-The primitive types are the fundamental building blocks of the LLVM
-system.
+These are the types that are valid in registers from CodeGen's perspective.
 
 .. _t_integer:
 
 Integer Type
-^^^^^^^^^^^^
+""""""""""""
 
-Overview:
-"""""""""
+:Overview:
 
 The integer type is a very simple type that simply specifies an
 arbitrary bit width for the integer type desired. Any bit width from 1
 bit to 2\ :sup:`23`\ -1 (about 8 million) can be specified.
 
-Syntax:
-"""""""
+:Syntax:
 
 ::
 
@@ -1563,7 +1700,7 @@ The number of bits the integer will occupy is specified by the ``N``
 value.
 
 Examples:
-"""""""""
+*********
 
 +----------------+------------------------------------------------+
 | ``i1``         | a single-bit integer.                          |
@@ -1576,7 +1713,7 @@ Examples:
 .. _t_floating:
 
 Floating Point Types
-^^^^^^^^^^^^^^^^^^^^
+""""""""""""""""""""
 
 .. list-table::
    :header-rows: 1
@@ -1602,57 +1739,104 @@ Floating Point Types
    * - ``ppc_fp128``
      - 128-bit floating point value (two 64-bits)
 
-.. _t_x86mmx:
+X86_mmx Type
+""""""""""""
 
-X86mmx Type
-^^^^^^^^^^^
+:Overview:
 
-Overview:
-"""""""""
-
-The x86mmx type represents a value held in an MMX register on an x86
+The x86_mmx type represents a value held in an MMX register on an x86
 machine. The operations allowed on it are quite limited: parameters and
 return values, load and store, and bitcast. User-specified MMX
 instructions are represented as intrinsic or asm calls with arguments
 and/or results of this type. There are no arrays, vectors or constants
 of this type.
 
-Syntax:
-"""""""
+:Syntax:
 
 ::
 
-      x86mmx
+      x86_mmx
 
-.. _t_void:
 
-Void Type
-^^^^^^^^^
+.. _t_pointer:
 
-Overview:
-"""""""""
+Pointer Type
+""""""""""""
 
-The void type does not represent any value and has no size.
+:Overview:
 
-Syntax:
-"""""""
+The pointer type is used to specify memory locations. Pointers are
+commonly used to reference objects in memory.
+
+Pointer types may have an optional address space attribute defining the
+numbered address space where the pointed-to object resides. The default
+address space is number zero. The semantics of non-zero address spaces
+are target-specific.
+
+Note that LLVM does not permit pointers to void (``void*``) nor does it
+permit pointers to labels (``label*``). Use ``i8*`` instead.
+
+:Syntax:
 
 ::
 
-      void
+      <type> *
+
+:Examples:
+
++-------------------------+--------------------------------------------------------------------------------------------------------------+
+| ``[4 x i32]*``          | A :ref:`pointer <t_pointer>` to :ref:`array <t_array>` of four ``i32`` values.                               |
++-------------------------+--------------------------------------------------------------------------------------------------------------+
+| ``i32 (i32*) *``        | A :ref:`pointer <t_pointer>` to a :ref:`function <t_function>` that takes an ``i32*``, returning an ``i32``. |
++-------------------------+--------------------------------------------------------------------------------------------------------------+
+| ``i32 addrspace(5)*``   | A :ref:`pointer <t_pointer>` to an ``i32`` value that resides in address space #5.                           |
++-------------------------+--------------------------------------------------------------------------------------------------------------+
+
+.. _t_vector:
+
+Vector Type
+"""""""""""
+
+:Overview:
+
+A vector type is a simple derived type that represents a vector of
+elements. Vector types are used when multiple primitive data are
+operated in parallel using a single instruction (SIMD). A vector type
+requires a size (number of elements) and an underlying primitive data
+type. Vector types are considered :ref:`first class <t_firstclass>`.
+
+:Syntax:
+
+::
+
+      < <# elements> x <elementtype> >
+
+The number of elements is a constant integer value larger than 0;
+elementtype may be any integer or floating point type, or a pointer to
+these types. Vectors of size zero are not allowed.
+
+:Examples:
+
++-------------------+--------------------------------------------------+
+| ``<4 x i32>``     | Vector of 4 32-bit integer values.               |
++-------------------+--------------------------------------------------+
+| ``<8 x float>``   | Vector of 8 32-bit floating-point values.        |
++-------------------+--------------------------------------------------+
+| ``<2 x i64>``     | Vector of 2 64-bit integer values.               |
++-------------------+--------------------------------------------------+
+| ``<4 x i64*>``    | Vector of 4 pointers to 64-bit integer values.   |
++-------------------+--------------------------------------------------+
 
 .. _t_label:
 
 Label Type
 ^^^^^^^^^^
 
-Overview:
-"""""""""
+:Overview:
 
 The label type represents code labels.
 
-Syntax:
-"""""""
+:Syntax:
 
 ::
 
@@ -1663,31 +1847,17 @@ Syntax:
 Metadata Type
 ^^^^^^^^^^^^^
 
-Overview:
-"""""""""
+:Overview:
 
 The metadata type represents embedded metadata. No derived types may be
 created from metadata except for :ref:`function <t_function>` arguments.
 
-Syntax:
-"""""""
+:Syntax:
 
 ::
 
       metadata
 
-.. _t_derived:
-
-Derived Types
--------------
-
-The real power in LLVM comes from the derived types in the system. This
-is what allows a programmer to represent arrays, functions, pointers,
-and other useful types. Each of these types contain one or more element
-types which may be a primitive type, or another derived type. For
-example, it is possible to have a two dimensional array, using an array
-as the element type of another array.
-
 .. _t_aggregate:
 
 Aggregate Types
@@ -1701,17 +1871,15 @@ aggregate types.
 .. _t_array:
 
 Array Type
-^^^^^^^^^^
+""""""""""
 
-Overview:
-"""""""""
+:Overview:
 
 The array type is a very simple derived type that arranges elements
 sequentially in memory. The array type requires a size (number of
 elements) and an underlying data type.
 
-Syntax:
-"""""""
+:Syntax:
 
 ::
 
@@ -1720,8 +1888,7 @@ Syntax:
 The number of elements is a constant integer value; ``elementtype`` may
 be any type with a size.
 
-Examples:
-"""""""""
+:Examples:
 
 +------------------+--------------------------------------+
 | ``[40 x i32]``   | Array of 40 32-bit integer values.   |
@@ -1749,53 +1916,12 @@ LLVM with a zero length array type. An implementation of 'pascal style
 arrays' in LLVM could use the type "``{ i32, [0 x float]}``", for
 example.
 
-.. _t_function:
-
-Function Type
-^^^^^^^^^^^^^
-
-Overview:
-"""""""""
-
-The function type can be thought of as a function signature. It consists of a
-return type and a list of formal parameter types. The return type of a function
-type is a void type or first class type --- except for :ref:`label <t_label>`
-and :ref:`metadata <t_metadata>` types.
-
-Syntax:
-"""""""
-
-::
-
-      <returntype> (<parameter list>)
-
-...where '``<parameter list>``' is a comma-separated list of type
-specifiers. Optionally, the parameter list may include a type ``...``, which
-indicates that the function takes a variable number of arguments.  Variable
-argument functions can access their arguments with the :ref:`variable argument
-handling intrinsic <int_varargs>` functions.  '``<returntype>``' is any type
-except :ref:`label <t_label>` and :ref:`metadata <t_metadata>`.
-
-Examples:
-"""""""""
-
-+---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``i32 (i32)``                   | function taking an ``i32``, returning an ``i32``                                                                                                                    |
-+---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``float (i16, i32 *) *``        | :ref:`Pointer <t_pointer>` to a function that takes an ``i16`` and a :ref:`pointer <t_pointer>` to ``i32``, returning ``float``.                                    |
-+---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``i32 (i8*, ...)``              | A vararg function that takes at least one :ref:`pointer <t_pointer>` to ``i8`` (char in C), which returns an integer. This is the signature for ``printf`` in LLVM. |
-+---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-| ``{i32, i32} (i32)``            | A function taking an ``i32``, returning a :ref:`structure <t_struct>` containing two ``i32`` values                                                                 |
-+---------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------+
-
 .. _t_struct:
 
 Structure Type
-^^^^^^^^^^^^^^
+""""""""""""""
 
-Overview:
-"""""""""
+:Overview:
 
 The structure type is used to represent a collection of data members
 together in memory. The elements of a structure may be any type that has
@@ -1819,16 +1945,14 @@ Literal types are uniqued by their contents and can never be recursive
 or opaque since there is no way to write one. Identified types can be
 recursive, can be opaqued, and are never uniqued.
 
-Syntax:
-"""""""
+:Syntax:
 
 ::
 
       %T1 = type { <type list> }     ; Identified normal struct type
       %T2 = type <{ <type list> }>   ; Identified packed struct type
 
-Examples:
-"""""""""
+:Examples:
 
 +------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
 | ``{ i32, i32, i32 }``        | A triple of three ``i32`` values                                                                                                                                                      |
@@ -1841,105 +1965,27 @@ Examples:
 .. _t_opaque:
 
 Opaque Structure Types
-^^^^^^^^^^^^^^^^^^^^^^
+""""""""""""""""""""""
 
-Overview:
-"""""""""
+:Overview:
 
 Opaque structure types are used to represent named structure types that
 do not have a body specified. This corresponds (for example) to the C
 notion of a forward declared structure.
 
-Syntax:
-"""""""
+:Syntax:
 
 ::
 
       %X = type opaque
       %52 = type opaque
 
-Examples:
-"""""""""
+:Examples:
 
 +--------------+-------------------+
 | ``opaque``   | An opaque type.   |
 +--------------+-------------------+
 
-.. _t_pointer:
-
-Pointer Type
-^^^^^^^^^^^^
-
-Overview:
-"""""""""
-
-The pointer type is used to specify memory locations. Pointers are
-commonly used to reference objects in memory.
-
-Pointer types may have an optional address space attribute defining the
-numbered address space where the pointed-to object resides. The default
-address space is number zero. The semantics of non-zero address spaces
-are target-specific.
-
-Note that LLVM does not permit pointers to void (``void*``) nor does it
-permit pointers to labels (``label*``). Use ``i8*`` instead.
-
-Syntax:
-"""""""
-
-::
-
-      <type> *
-
-Examples:
-"""""""""
-
-+-------------------------+--------------------------------------------------------------------------------------------------------------+
-| ``[4 x i32]*``          | A :ref:`pointer <t_pointer>` to :ref:`array <t_array>` of four ``i32`` values.                               |
-+-------------------------+--------------------------------------------------------------------------------------------------------------+
-| ``i32 (i32*) *``        | A :ref:`pointer <t_pointer>` to a :ref:`function <t_function>` that takes an ``i32*``, returning an ``i32``. |
-+-------------------------+--------------------------------------------------------------------------------------------------------------+
-| ``i32 addrspace(5)*``   | A :ref:`pointer <t_pointer>` to an ``i32`` value that resides in address space #5.                           |
-+-------------------------+--------------------------------------------------------------------------------------------------------------+
-
-.. _t_vector:
-
-Vector Type
-^^^^^^^^^^^
-
-Overview:
-"""""""""
-
-A vector type is a simple derived type that represents a vector of
-elements. Vector types are used when multiple primitive data are
-operated in parallel using a single instruction (SIMD). A vector type
-requires a size (number of elements) and an underlying primitive data
-type. Vector types are considered :ref:`first class <t_firstclass>`.
-
-Syntax:
-"""""""
-
-::
-
-      < <# elements> x <elementtype> >
-
-The number of elements is a constant integer value larger than 0;
-elementtype may be any integer or floating point type, or a pointer to
-these types. Vectors of size zero are not allowed.
-
-Examples:
-"""""""""
-
-+-------------------+--------------------------------------------------+
-| ``<4 x i32>``     | Vector of 4 32-bit integer values.               |
-+-------------------+--------------------------------------------------+
-| ``<8 x float>``   | Vector of 8 32-bit floating-point values.        |
-+-------------------+--------------------------------------------------+
-| ``<2 x i64>``     | Vector of 2 64-bit integer values.               |
-+-------------------+--------------------------------------------------+
-| ``<4 x i64*>``    | Vector of 4 pointers to 64-bit integer values.   |
-+-------------------+--------------------------------------------------+
-
 Constants
 =========
 
@@ -1994,7 +2040,7 @@ The IEEE 16-bit format (half precision) is represented by ``0xH``
 followed by 4 hexadecimal digits. All hexadecimal formats are big-endian
 (sign bit at the left).
 
-There are no constants of type x86mmx.
+There are no constants of type x86_mmx.
 
 .. _complexconstants:
 
@@ -2742,9 +2788,9 @@ metadata types that refer to the same loop identifier metadata.
 
    for.body:
      ...
-     %0 = load i32* %arrayidx, align 4, !llvm.mem.parallel_loop_access !0
+     %val0 = load i32* %arrayidx, !llvm.mem.parallel_loop_access !0
      ...
-     store i32 %0, i32* %arrayidx4, align 4, !llvm.mem.parallel_loop_access !0
+     store i32 %val0, i32* %arrayidx1, !llvm.mem.parallel_loop_access !0
      ...
      br i1 %exitcond, label %for.end, label %for.body, !llvm.loop !0
 
@@ -2759,21 +2805,22 @@ the loop identifier metadata node directly:
 .. code-block:: llvm
 
    outer.for.body:
-   ...
+     ...
+     %val1 = load i32* %arrayidx3, !llvm.mem.parallel_loop_access !2
+     ...
+     br label %inner.for.body
 
    inner.for.body:
      ...
-     %0 = load i32* %arrayidx, align 4, !llvm.mem.parallel_loop_access !0
+     %val0 = load i32* %arrayidx1, !llvm.mem.parallel_loop_access !0
      ...
-     store i32 %0, i32* %arrayidx4, align 4, !llvm.mem.parallel_loop_access !0
+     store i32 %val0, i32* %arrayidx2, !llvm.mem.parallel_loop_access !0
      ...
      br i1 %exitcond, label %inner.for.end, label %inner.for.body, !llvm.loop !1
 
    inner.for.end:
      ...
-     %0 = load i32* %arrayidx, align 4, !llvm.mem.parallel_loop_access !0
-     ...
-     store i32 %0, i32* %arrayidx4, align 4, !llvm.mem.parallel_loop_access !0
+     store i32 %val1, i32* %arrayidx4, !llvm.mem.parallel_loop_access !2
      ...
      br i1 %exitcond, label %outer.for.end, label %outer.for.body, !llvm.loop !2
 
@@ -4662,7 +4709,7 @@ Syntax:
 
 ::
 
-      <result> = alloca <type>[, <ty> <NumElements>][, align <alignment>]     ; yields {type*}:result
+      <result> = alloca [inalloca] <type> [, <ty> <NumElements>] [, align <alignment>]     ; yields {type*}:result
 
 Overview:
 """""""""
@@ -4939,7 +4986,7 @@ Syntax:
 
 ::
 
-      cmpxchg [volatile] <ty>* <pointer>, <ty> <cmp>, <ty> <new> [singlethread] <ordering>  ; yields {ty}
+      cmpxchg [volatile] <ty>* <pointer>, <ty> <cmp>, <ty> <new> [singlethread] <success ordering> <failure ordering> ; yields {ty}
 
 Overview:
 """""""""
@@ -4962,8 +5009,11 @@ type, and the type of '<pointer>' must be a pointer to that type. If the
 to modify the number or order of execution of this ``cmpxchg`` with
 other :ref:`volatile operations <volatile>`.
 
-The :ref:`ordering <ordering>` argument specifies how this ``cmpxchg``
-synchronizes with other atomic operations.
+The success and failure :ref:`ordering <ordering>` arguments specify how this
+``cmpxchg`` synchronizes with other atomic operations. The both ordering
+parameters must be at least ``monotonic``, the ordering constraint on failure
+must be no stronger than that on success, and the failure ordering cannot be
+either ``release`` or ``acq_rel``.
 
 The optional "``singlethread``" argument declares that the ``cmpxchg``
 is only atomic with respect to code (usually signal handlers) running in
@@ -4981,10 +5031,9 @@ operand is read and compared to '``<cmp>``'; if the read value is the
 equal, '``<new>``' is written. The original value at the location is
 returned.
 
-A successful ``cmpxchg`` is a read-modify-write instruction for the purpose
-of identifying release sequences. A failed ``cmpxchg`` is equivalent to an
-atomic load with an ordering parameter determined by dropping any
-``release`` part of the ``cmpxchg``'s ordering.
+A successful ``cmpxchg`` is a read-modify-write instruction for the purpose of
+identifying release sequences. A failed ``cmpxchg`` is equivalent to an atomic
+load with an ordering parameter determined the second ordering parameter.
 
 Example:
 """"""""
@@ -4998,7 +5047,7 @@ Example:
     loop:
       %cmp = phi i32 [ %orig, %entry ], [%old, %loop]
       %squared = mul i32 %cmp, %cmp
-      %old = cmpxchg i32* %ptr, i32 %cmp, i32 %squared          ; yields {i32}
+      %old = cmpxchg i32* %ptr, i32 %cmp, i32 %squared acq_rel monotonic ; yields {i32}
       %success = icmp eq i32 %cmp, %old
       br i1 %success, label %done, label %loop
 
@@ -6069,7 +6118,7 @@ Overview:
 """""""""
 
 The '``select``' instruction is used to choose one value based on a
-condition, without branching.
+condition, without IR-level branching.
 
 Arguments:
 """"""""""
@@ -6892,6 +6941,39 @@ is lowered to a constant 0.
 Note that runtime support may be conditional on the privilege-level code is
 running at and the host platform.
 
+'``llvm.clear_cache``' Intrinsic
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+"""""""
+
+::
+
+      declare void @llvm.clear_cache(i8*, i8*)
+
+Overview:
+"""""""""
+
+The '``llvm.clear_cache``' intrinsic ensures visibility of modifications
+in the specified range to the execution unit of the processor. On
+targets with non-unified instruction and data cache, the implementation
+flushes the instruction cache.
+
+Semantics:
+""""""""""
+
+On platforms with coherent instruction and data caches (e.g. x86), this
+intrinsic is a nop. On platforms with non-coherent instruction and data
+cache (e.g. ARM, MIPS), the intrinsic is lowered either to appropiate
+instructions or a system call, if cache flushing requires special
+privileges.
+
+The default behavior is to emit a call to ``__clear_cache'' from the run
+time library.
+
+This instrinsic does *not* empty the instruction pipeline. Modifications
+of the current function are outside the scope of the intrinsic.
+
 Standard C Library Intrinsics
 -----------------------------
 
@@ -7457,7 +7539,7 @@ Semantics:
 """"""""""
 
 This function returns the same values as the libm ``fma`` functions
-would.
+would, and does not set errno.
 
 '``llvm.fabs.*``' Intrinsic
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -8265,7 +8347,8 @@ is equivalent to the expression a \* b + c, except that rounding will
 not be performed between the multiplication and addition steps if the
 code generator fuses the operations. Fusion is not guaranteed, even if
 the target platform supports it. If a fused multiply-add is required the
-corresponding llvm.fma.\* intrinsic function should be used instead.
+corresponding llvm.fma.\* intrinsic function should be used
+instead. This never sets errno, just as '``llvm.fma.*``'.
 
 Examples:
 """""""""
@@ -8502,6 +8585,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
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -8533,6 +8618,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
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -8909,8 +8996,12 @@ on the ``min`` argument).
 Syntax:
 """""""
 
+This is an overloaded intrinsic. You can use ``llvm.expect`` on any
+integer bit width.
+
 ::
 
+      declare i1 @llvm.expect.i1(i1 <val>, i1 <expected_val>)
       declare i32 @llvm.expect.i32(i32 <val>, i32 <expected_val>)
       declare i64 @llvm.expect.i64(i64 <val>, i64 <expected_val>)
 
@@ -8958,3 +9049,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`.
diff --git a/docs/MakefileGuide.rst b/docs/MakefileGuide.rst
index 120c108..a5e2731 100644
--- a/docs/MakefileGuide.rst
+++ b/docs/MakefileGuide.rst
@@ -47,9 +47,7 @@ quickly by utilizing the built-in features that are used to compile LLVM. LLVM
 compiles itself using the same features of the makefile system as used for
 projects.
 
-For complete details on setting up your projects configuration, simply mimic the
-``llvm/projects/sample`` project. Or for further details, consult the
-`Projects <Projects.html>`_ page.
+For further details, consult the `Projects <Projects.html>`_ page.
 
 Variable Values
 ---------------
diff --git a/docs/NVPTXUsage.rst b/docs/NVPTXUsage.rst
index a9065ce..e1c401d 100644
--- a/docs/NVPTXUsage.rst
+++ b/docs/NVPTXUsage.rst
@@ -273,7 +273,7 @@ there is a separate version for each compute architecture.
 For a list of all math functions implemented in libdevice, see
 `libdevice Users Guide <http://docs.nvidia.com/cuda/libdevice-users-guide/index.html>`_.
 
-To accomodate various math-related compiler flags that can affect code
+To accommodate various math-related compiler flags that can affect code
 generation of libdevice code, the library code depends on a special LLVM IR
 pass (``NVVMReflect``) to handle conditional compilation within LLVM IR. This
 pass looks for calls to the ``@__nvvm_reflect`` function and replaces them
@@ -839,7 +839,7 @@ Libdevice provides an ``__nv_powf`` function that we will use.
     %valB = load float addrspace(1)* %ptrB, align 4
 
     ; Compute C = pow(A, B)
-    %valC = call float @__nv_exp2f(float %valA, float %valB)
+    %valC = call float @__nv_powf(float %valA, float %valB)
 
     ; Store back to C
     store float %valC, float addrspace(1)* %ptrC, align 4
@@ -850,7 +850,7 @@ Libdevice provides an ``__nv_powf`` function that we will use.
   !nvvm.annotations = !{!0}
   !0 = metadata !{void (float addrspace(1)*,
                         float addrspace(1)*,
-                        float addrspace(1)*)* @kernel, metadata !"kernel", i32 1}%
+                        float addrspace(1)*)* @kernel, metadata !"kernel", i32 1}
 
 
 To compile this kernel, we perform the following steps:
diff --git a/docs/Passes.rst b/docs/Passes.rst
index 029e472..a288933 100644
--- a/docs/Passes.rst
+++ b/docs/Passes.rst
@@ -893,33 +893,14 @@ this would require knowledge of the entire call graph of the program including
 any libraries which may not be available in bitcode form); it simply lowers
 every atomic intrinsic.
 
-``-lowerinvoke``: Lower invoke and unwind, for unwindless code generators
--------------------------------------------------------------------------
+``-lowerinvoke``: Lower invokes to calls, for unwindless code generators
+------------------------------------------------------------------------
 
 This transformation is designed for use by code generators which do not yet
-support stack unwinding.  This pass supports two models of exception handling
-lowering, the "cheap" support and the "expensive" support.
-
-"Cheap" exception handling support gives the program the ability to execute any
-program which does not "throw an exception", by turning "``invoke``"
-instructions into calls and by turning "``unwind``" instructions into calls to
-``abort()``.  If the program does dynamically use the "``unwind``" instruction,
-the program will print a message then abort.
-
-"Expensive" exception handling support gives the full exception handling
-support to the program at the cost of making the "``invoke``" instruction
-really expensive.  It basically inserts ``setjmp``/``longjmp`` calls to emulate
-the exception handling as necessary.
-
-Because the "expensive" support slows down programs a lot, and EH is only used
-for a subset of the programs, it must be specifically enabled by the
-``-enable-correct-eh-support`` option.
-
-Note that after this pass runs the CFG is not entirely accurate (exceptional
-control flow edges are not correct anymore) so only very simple things should
-be done after the ``lowerinvoke`` pass has run (like generation of native
-code).  This should not be used as a general purpose "my LLVM-to-LLVM pass
-doesn't support the ``invoke`` instruction yet" lowering pass.
+support stack unwinding.  This pass converts ``invoke`` instructions to
+``call`` instructions, so that any exception-handling ``landingpad`` blocks
+become dead code (which can be removed by running the ``-simplifycfg`` pass
+afterwards).
 
 ``-lowerswitch``: Lower ``SwitchInst``\ s to branches
 -----------------------------------------------------
diff --git a/docs/Phabricator.rst b/docs/Phabricator.rst
index 6fdea1f..581c9e5 100644
--- a/docs/Phabricator.rst
+++ b/docs/Phabricator.rst
@@ -12,13 +12,6 @@ you can now submit your patches for Clang and LLVM at
 Sign up
 -------
 
-There are two options to get an account on Phabricator. You can sign up
-immediately with one of the supported OAuth account types if you're comfortable
-with OAuth, but you can also email chandlerc@gmail.com to request an account to
-be created manually without using OAuth. We're working to get support in
-Phabricator to directly create new accounts, but currently this is a manual
-process.
-
 Note that if you use your Subversion user name as Phabricator user name,
 Phabricator will automatically connect your submits to your Phabricator user in
 the `Code Repository Browser`_.
@@ -94,6 +87,26 @@ when a review changes state, for example by clicking "Accept Revision" in
 the web interface. Thus, please type LGTM into the comment box to accept
 a change from Phabricator.
 
+Committing a change
+-------------------
+
+When committing an LLVM change that has been reviewed using
+Phabricator, the convention is for the commit message to end with the
+line:
+
+::
+
+  Differential Revision: <URL>
+
+where ``<URL>`` is the URL for the code review, starting with
+``http://llvm-reviews.chandlerc.com/``.
+
+Note that Arcanist will add this automatically.
+
+This allows people reading the version history to see the review for
+context.  This also allows Phabricator to detect the commit, close the
+review, and add a link from the review to the commit.
+
 Status
 ------
 
diff --git a/docs/ProgrammersManual.rst b/docs/ProgrammersManual.rst
index 99aa5c7..9f388cc 100644
--- a/docs/ProgrammersManual.rst
+++ b/docs/ProgrammersManual.rst
@@ -475,8 +475,8 @@ these functions in your code in places you want to debug.
 
 Getting this to work requires a small amount of configuration.  On Unix systems
 with X11, install the `graphviz <http://www.graphviz.org>`_ toolkit, and make
-sure 'dot' and 'gv' are in your path.  If you are running on Mac OS/X, download
-and install the Mac OS/X `Graphviz program
+sure 'dot' and 'gv' are in your path.  If you are running on Mac OS X, download
+and install the Mac OS X `Graphviz program
 <http://www.pixelglow.com/graphviz/>`_ and add
 ``/Applications/Graphviz.app/Contents/MacOS/`` (or wherever you install it) to
 your path.  Once in your system and path are set up, rerun the LLVM configure
@@ -1318,7 +1318,7 @@ type used.
 
 .. _dss_valuemap:
 
-llvm/ADT/ValueMap.h
+llvm/IR/ValueMap.h
 ^^^^^^^^^^^^^^^^^^^
 
 ValueMap is a wrapper around a :ref:`DenseMap <dss_densemap>` mapping
diff --git a/docs/Projects.rst b/docs/Projects.rst
index 3246e3f..095b87a 100644
--- a/docs/Projects.rst
+++ b/docs/Projects.rst
@@ -37,82 +37,16 @@ There are two ways that you can set all of these variables:
   of LLVM, and the ability to support multiple object directories from a single
   source directory.
 
-This document assumes that you will base your project on the LLVM sample project
-found in ``llvm/projects/sample``. If you want to devise your own build system,
-studying the sample project and LLVM ``Makefiles`` will probably provide enough
-information on how to write your own ``Makefiles``.
-
-Create a Project from the Sample Project
-========================================
-
-Follow these simple steps to start your project:
-
-1. Copy the ``llvm/projects/sample`` directory to any place of your choosing.
-   You can place it anywhere you like. Rename the directory to match the name
-   of your project.
-
-2. If you downloaded LLVM using Subversion, remove all the directories named
-   ``.svn`` (and all the files therein) from your project's new source tree.
-   This will keep Subversion from thinking that your project is inside
-   ``llvm/trunk/projects/sample``.
-
-3. Add your source code and Makefiles to your source tree.
-
-4. If you want your project to be configured with the ``configure`` script then
-   you need to edit ``autoconf/configure.ac`` as follows:
-
-   * **AC_INIT** - Place the name of your project, its version number and a
-     contact email address for your project as the arguments to this macro
- 
-   * **AC_CONFIG_AUX_DIR** - If your project isn't in the ``llvm/projects``
-     directory then you might need to adjust this so that it specifies a
-     relative path to the ``llvm/autoconf`` directory.
-
-   * **LLVM_CONFIG_PROJECT** - Just leave this alone.
-
-   * **AC_CONFIG_SRCDIR** - Specify a path to a file name that identifies your
-     project; or just leave it at ``Makefile.common.in``.
-
-   * **AC_CONFIG_FILES** - Do not change.
-
-   * **AC_CONFIG_MAKEFILE** - Use one of these macros for each Makefile that
-     your project uses. This macro arranges for your makefiles to be copied from
-     the source directory, unmodified, to the build directory.
-
-5. After updating ``autoconf/configure.ac``, regenerate the configure script
-   with these commands. (You must be using ``Autoconf`` version 2.59 or later
-   and your ``aclocal`` version should be 1.9 or later.)
-
-       .. code-block:: bash
-
-         % cd autoconf
-         % ./AutoRegen.sh
-
-6. Run ``configure`` in the directory in which you want to place object code.
-   Use the following options to tell your project where it can find LLVM:
-
-   ``--with-llvmsrc=<directory>``
-       Tell your project where the LLVM source tree is located.
-
-   ``--with-llvmobj=<directory>``
-       Tell your project where the LLVM object tree is located.
-
-   ``--prefix=<directory>``
-       Tell your project where it should get installed.
-
-That's it!  Now all you have to do is type ``gmake`` (or ``make`` if you're on a
-GNU/Linux system) in the root of your object directory, and your project should
-build.
+If you want to devise your own build system, studying other projects and LLVM
+``Makefiles`` will probably provide enough information on how to write your own
+``Makefiles``.
 
 Source Tree Layout
 ==================
 
 In order to use the LLVM build system, you will want to organize your source
 code so that it can benefit from the build system's features.  Mainly, you want
-your source tree layout to look similar to the LLVM source tree layout.  The
-best way to do this is to just copy the project tree from
-``llvm/projects/sample`` and modify it to meet your needs, but you can certainly
-add to it if you want.
+your source tree layout to look similar to the LLVM source tree layout.
 
 Underneath your top level directory, you should have the following directories:
 
diff --git a/docs/ReleaseNotes.rst b/docs/ReleaseNotes.rst
index 94663c4..723e7cf 100644
--- a/docs/ReleaseNotes.rst
+++ b/docs/ReleaseNotes.rst
@@ -1,15 +1,21 @@
 ======================
-LLVM 3.4 Release Notes
+LLVM 3.5 Release Notes
 ======================
 
 .. contents::
     :local:
 
+.. warning::
+   These are in-progress notes for the upcoming LLVM 3.5 release.  You may
+   prefer the `LLVM 3.4 Release Notes <http://llvm.org/releases/3.4/docs
+   /ReleaseNotes.html>`_.
+
+
 Introduction
 ============
 
 This document contains the release notes for the LLVM Compiler Infrastructure,
-release 3.4.  Here we describe the status of LLVM, including major improvements
+release 3.5.  Here we describe the status of LLVM, including major improvements
 from the previous release, improvements in various subprojects of LLVM, and
 some of the current users of the code.  All LLVM releases may be downloaded
 from the `LLVM releases web site <http://llvm.org/releases/>`_.
@@ -28,211 +34,80 @@ page <http://llvm.org/releases/>`_.
 Non-comprehensive list of changes in this release
 =================================================
 
-* This is expected to be the last release of LLVM which compiles using a C++98
-  toolchain. We expect to start using some C++11 features in LLVM and other
-  sub-projects starting after this release. That said, we are committed to
-  supporting a reasonable set of modern C++ toolchains as the host compiler on
-  all of the platforms. This will at least include Visual Studio 2012 on
-  Windows, and Clang 3.1 or GCC 4.7.x on Mac and Linux. The final set of
-  compilers (and the C++11 features they support) is not set in stone, but we
-  wanted users of LLVM to have a heads up that the next release will involve
-  a substantial change in the host toolchain requirements.
-
-* The regression tests now fail if any command in a pipe fails. To disable it in
-  a directory, just add ``config.pipefail = False`` to its ``lit.local.cfg``.
-  See :doc:`Lit <CommandGuide/lit>` for the details.
-
-* Support for exception handling has been removed from the old JIT. Use MCJIT
-  if you need EH support.
-
-* The R600 backend is not marked experimental anymore and is built by default.
-
-* ``APFloat::isNormal()`` was renamed to ``APFloat::isFiniteNonZero()`` and
-  ``APFloat::isIEEENormal()`` was renamed to ``APFloat::isNormal()``. This
-  ensures that ``APFloat::isNormal()`` conforms to IEEE-754R-2008.
+* All backends have been changed to use the MC asm printer and support for the
+  non MC one has been removed.
 
-* The library call simplification pass has been removed.  Its functionality
-  has been integrated into the instruction combiner and function attribute
-  marking passes.
+* Clang can now successfully self-host itself on Linux/Sparc64 and on
+  FreeBSD/Sparc64.
 
-* Support for building using Visual Studio 2008 has been dropped. Use VS 2010
-  or later instead. For more information, see the `Getting Started using Visual
-  Studio <GettingStartedVS.html>`_ page.
+* LLVM now assumes the assembler supports ``.loc`` for generating debug line
+  numbers. The old support for printing the debug line info directly was only
+  used by ``llc`` and has been removed.
 
-* The Loop Vectorizer that was previously enabled for ``-O3`` is now enabled
-  for ``-Os`` and ``-O2``.
+* All inline assembly is parsed by the integrated assembler when it is enabled.
+  Previously this was only the case for object-file output. It is now the case
+  for assembly output as well. The integrated assembler can be disabled with
+  the ``-no-integrated-as`` option,
 
-* The new SLP Vectorizer is now enabled by default.
+* llvm-ar now handles IR files like regular object files. In particular, a
+  regular symbol table is created for symbols defined in IR files.
 
-* ``llvm-ar`` now uses the new Object library and produces archives and
-  symbol tables in the gnu format.
+.. NOTE
+   For small 1-3 sentence descriptions, just add an entry at the end of
+   this list. If your description won't fit comfortably in one bullet
+   point (e.g. maybe you would like to give an example of the
+   functionality, or simply have a lot to talk about), see the `NOTE` below
+   for adding a new subsection.
 
-* FileCheck now allows specifing ``-check-prefix`` multiple times. This
-  helps reduce duplicate check lines when using multiple RUN lines.
+* ... next change ...
 
-* The bitcast instruction no longer allows casting between pointers
-   with different address spaces. To achieve this, use the new addrspacecast
-   instruction.
+.. NOTE
+   If you would like to document a larger change, then you can add a
+   subsection about it right here. You can copy the following boilerplate
+   and un-indent it (the indentation causes it to be inside this comment).
 
-* Different sized pointers for different address spaces should now
-  generally work. This is primarily useful for GPU targets.
+   Special New Feature
+   -------------------
 
-* OCaml bindings have been significantly extended to cover almost all of the
-  LLVM libraries.
+   Makes programs 10x faster by doing Special New Thing.
 
-Mips Target
------------
+Changes to the ARM Backend
+--------------------------
 
-Support for the MIPS SIMD Architecture (MSA) has been added. MSA is supported
-through inline assembly, intrinsics with the prefix '``__builtin_msa``', and
-normal code generation.
+Since release 3.3, a lot of new features have been included in the ARM
+back-end but weren't production ready (ie. well tested) on release 3.4.
+Just after the 3.4 release, we started heavily testing two major parts
+of the back-end: the integrated assembler (IAS) and the ARM exception
+handling (EHABI), and now they are enabled by default on LLVM/Clang.
 
-For more information on MSA (including documentation for the instruction set),
-see the `MIPS SIMD page at Imagination Technologies
-<http://imgtec.com/mips/mips-simd.asp>`_
+The IAS received a lot of GNU extensions and directives, as well as some
+specific pre-UAL instructions. Not all remaining directives will be
+implemented, as we made judgement calls on the need versus the complexity,
+and have chosen simplicity and future compatibility where hard decisions
+had to be made. The major difference is, as stated above, the IAS validates
+all inline ASM, not just for object emission, and that cause trouble with
+some uses of inline ASM as pre-processor magic.
 
-PowerPC Target
---------------
+So, while the IAS is good enough to compile large projects (including most
+of the Linux kernel), there are a few things that we can't (and probably
+won't) do. For those cases, please use ``-fno-integrated-as`` in Clang.
 
-Changes in the PowerPC backend include:
+Exception handling is another big change. After extensive testing and
+changes to cooperate with Dwarf unwinding, EHABI is enabled by default.
+The options ``-arm-enable-ehabi`` and ``-arm-enable-ehabi-descriptors``,
+which were used to enable EHABI in the previous releases, are removed now.
 
-* fast-isel support (for faster ``-O0`` code generation)
-* many improvements to the builtin assembler
-* support for generating unaligned (Altivec) vector loads
-* support for generating the fcpsgn instruction
-* generate ``frin`` for ``round()`` (not ``nearbyint()`` and ``rint()``, which
-  had been done only in fast-math mode)
-* improved instruction scheduling for embedded cores (such as the A2)
-* improved prologue/epilogue generation (especially in 32-bit mode)
-* support for dynamic stack alignment (and dynamic stack allocations with large alignments)
-* improved generation of counter-register-based loops
-* bug fixes
+This means all ARM code will emit EH unwind tables, or CFI unwinding (for
+debug/profiling), or both. To avoid run-time inconsistencies, C code will
+also emit EH tables (in case they interoperate with C++ code), as is the
+case for other architectures (ex. x86_64).
 
-SPARC Target
-------------
-
-The SPARC backend got many improvements, namely
-
-* experimental SPARC V9 backend
-* JIT support for SPARC
-* fp128 support
-* exception handling
-* TLS support
-* leaf functions optimization
-* bug fixes
-
-SystemZ/s390x Backend
----------------------
-
-LLVM and clang can now optimize for zEnterprise z196 and zEnterprise EC12
-targets.  In clang these targets are selected using ``-march=z196`` and
-``-march=zEC12`` respectively.
-
-External Open Source Projects Using LLVM 3.4
+External Open Source Projects Using LLVM 3.5
 ============================================
 
 An exciting aspect of LLVM is that it is used as an enabling technology for
 a lot of other language and tools projects. This section lists some of the
-projects that have already been updated to work with LLVM 3.4.
-
-DXR
----
-
-`DXR <https://wiki.mozilla.org/DXR>`_ is Mozilla's code search and navigation
-tool, aimed at making sense of large projects like Firefox. It supports
-full-text and regex searches as well as structural queries like "Find all the
-callers of this function." Behind the scenes, it uses a custom trigram index,
-the re2 library, and structural data collected by a clang compiler plugin.
-
-LDC - the LLVM-based D compiler
--------------------------------
-
-`D <http://dlang.org>`_ is a language with C-like syntax and static typing. It
-pragmatically combines efficiency, control, and modeling power, with safety and
-programmer productivity. D supports powerful concepts like Compile-Time Function
-Execution (CTFE) and Template Meta-Programming, provides an innovative approach
-to concurrency and offers many classical paradigms.
-
-`LDC <http://wiki.dlang.org/LDC>`_ uses the frontend from the reference compiler
-combined with LLVM as backend to produce efficient native code. LDC targets
-x86/x86_64 systems like Linux, OS X, FreeBSD and Windows and also Linux/PPC64.
-Ports to other architectures like ARM and AArch64 are underway.
-
-LibBeauty
----------
-
-The `LibBeauty <http://www.libbeauty.com>`_ decompiler and reverse
-engineering tool currently utilises the LLVM disassembler and the LLVM IR
-Builder. The current aim of the project is to take a x86_64 binary ``.o`` file
-as input, and produce an equivalent LLVM IR ``.bc`` or ``.ll`` file as
-output. Support for ARM binary ``.o`` file as input will be added later.
-
-Likely
-------
-
-`Likely <http://www.liblikely.org/>`_ is an open source domain specific
-language for image recognition.  Algorithms are just-in-time compiled using
-LLVM's MCJIT infrastructure to execute on single or multi-threaded CPUs as well
-as OpenCL SPIR or CUDA enabled GPUs. Likely exploits the observation that while
-image processing and statistical learning kernels must be written generically
-to handle any matrix datatype, at runtime they tend to be executed repeatedly
-on the same type.
-
-Portable Computing Language (pocl)
-----------------------------------
-
-In addition to producing an easily portable open source OpenCL
-implementation, another major goal of `pocl <http://portablecl.org/>`_
-is improving performance portability of OpenCL programs with
-compiler optimizations, reducing the need for target-dependent manual
-optimizations. An important part of pocl is a set of LLVM passes used to
-statically parallelize multiple work-items with the kernel compiler, even in
-the presence of work-group barriers. This enables static parallelization of
-the fine-grained static concurrency in the work groups in multiple ways. 
-
-Portable Native Client (PNaCl)
-------------------------------
-
-`Portable Native Client (PNaCl) <http://www.chromium.org/nativeclient/pnacl>`_
-is a Chrome initiative to bring the performance and low-level control of native
-code to modern web browsers, without sacrificing the security benefits and
-portability of web applications. PNaCl works by compiling native C and C++ code
-to an intermediate representation using the LLVM clang compiler. This
-intermediate representation is a subset of LLVM bytecode that is wrapped into a
-portable executable, which can be hosted on a web server like any other website
-asset. When the site is accessed, Chrome fetches and translates the portable
-executable into an architecture-specific machine code optimized directly for
-the underlying device. PNaCl lets developers compile their code once to run on
-any hardware platform and embed their PNaCl application in any website,
-enabling developers to directly leverage the power of the underlying CPU and
-GPU.
-
-TTA-based Co-design Environment (TCE)
--------------------------------------
-
-`TCE <http://tce.cs.tut.fi/>`_ is a toolset for designing new
-exposed datapath processors based on the Transport triggered architecture (TTA). 
-The toolset provides a complete co-design flow from C/C++
-programs down to synthesizable VHDL/Verilog and parallel program binaries.
-Processor customization points include the register files, function units,
-supported operations, and the interconnection network.
-
-TCE uses Clang and LLVM for C/C++/OpenCL C language support, target independent 
-optimizations and also for parts of code generation. It generates
-new LLVM-based code generators "on the fly" for the designed processors and
-loads them in to the compiler backend as runtime libraries to avoid
-per-target recompilation of larger parts of the compiler chain. 
-
-WebCL Validator
----------------
-
-`WebCL Validator <https://github.com/KhronosGroup/webcl-validator>`_ implements
-validation for WebCL C language which is a subset of OpenCL ES 1.1. Validator
-checks the correctness of WebCL C, and implements memory protection for it as a
-source-2-source transformation. The transformation converts WebCL to memory
-protected OpenCL. The protected OpenCL cannot access any memory ranges which
-were not allocated for it, and its memory is always initialized to prevent
-information leakage from other programs.
+projects that have already been updated to work with LLVM 3.5.
 
 
 Additional Information
@@ -247,3 +122,4 @@ going into the ``llvm/docs/`` directory in the LLVM tree.
 
 If you have any questions or comments about LLVM, please feel free to contact
 us via the `mailing lists <http://llvm.org/docs/#maillist>`_.
+
diff --git a/docs/ReleaseProcess.rst b/docs/ReleaseProcess.rst
index 0836b6e..c4bbc91 100644
--- a/docs/ReleaseProcess.rst
+++ b/docs/ReleaseProcess.rst
@@ -52,18 +52,16 @@ The scripts are in the ``utils/release`` directory.
 test-release.sh
 ---------------
 
-This script will check-out, configure and compile LLVM+Clang (+ most add-ons,
-like ``compiler-rt``, ``libcxx`` and ``clang-extra-tools``) in three stages, and
-will test the final stage.  It'll have installed the final binaries on the
-Phase3/Releasei(+Asserts) directory, and that's the one you should use for the
-test-suite and other external tests.
+This script will check-out, configure and compile LLVM+Clang (+ most add-ons, like ``compiler-rt``,
+``libcxx`` and ``clang-extra-tools``) in three stages, and will test the final stage.
+It'll have installed the final binaries on the Phase3/Releasei(+Asserts) directory, and
+that's the one you should use for the test-suite and other external tests.
 
 To run the script on a specific release candidate run::
 
    ./test-release.sh \
-        -release 3.4 \
+        -release 3.3 \
         -rc 1 \
-        -triple x86_64-apple-darwin \
         -no-64bit \
         -test-asserts \
         -no-compare-files
diff --git a/docs/SourceLevelDebugging.rst b/docs/SourceLevelDebugging.rst
index a1d8110..f957a7d 100644
--- a/docs/SourceLevelDebugging.rst
+++ b/docs/SourceLevelDebugging.rst
@@ -319,6 +319,7 @@ Block descriptors
     metadata,;; Reference to context descriptor
     i32,     ;; Line number
     i32,     ;; Column number
+    i32,     ;; DWARF path discriminator value
     i32      ;; Unique ID to identify blocks from a template function
   }
 
@@ -566,7 +567,7 @@ Local variables
     metadata, ;; Reference to file where defined
     i32,      ;; 24 bit - Line number where defined
               ;; 8 bit - Argument number. 1 indicates 1st argument.
-    metadata, ;; Type descriptor
+    metadata, ;; Reference to the type descriptor
     i32,      ;; flags
     metadata  ;; (optional) Reference to inline location
   }
@@ -724,7 +725,8 @@ Compiled to LLVM, this function would be represented like this:
   !15 = metadata !{i32 786688, metadata !16, metadata !"Z", metadata !5, i32 5,
                    metadata !11, i32 0, i32 0} ; [ DW_TAG_auto_variable ] [Z] \
                      [line 5]
-  !16 = metadata !{i32 786443, metadata !1, metadata !4, i32 4, i32 0, i32 0} \
+  !16 = metadata !{i32 786443, metadata !1, metadata !4, i32 4, i32 0, i32 0,
+                   i32 0} \
                    ; [ DW_TAG_lexical_block ] [/private/tmp/t.c]
   !17 = metadata !{i32 5, i32 0, metadata !16, null}
   !18 = metadata !{i32 6, i32 0, metadata !16, null}
@@ -776,7 +778,8 @@ scope information for the variable ``Z``.
 
 .. code-block:: llvm
 
-  !16 = metadata !{i32 786443, metadata !1, metadata !4, i32 4, i32 0, i32 0}
+  !16 = metadata !{i32 786443, metadata !1, metadata !4, i32 4, i32 0, i32 0,
+                   i32 0}
                    ; [ DW_TAG_lexical_block ] [/private/tmp/t.c]
   !17 = metadata !{i32 5, i32 0, metadata !16, null}
 
@@ -2306,7 +2309,7 @@ stringWithCString:]``") and the basename is the selector only
 Mach-O Changes
 """"""""""""""
 
-The sections names for the apple hash tables are for non mach-o files.  For
+The sections names for the apple hash tables are for non-mach-o files.  For
 mach-o files, the sections should be contained in the ``__DWARF`` segment with
 names as follows:
 
diff --git a/docs/StackMaps.rst b/docs/StackMaps.rst
new file mode 100644
index 0000000..bd0fb94
--- /dev/null
+++ b/docs/StackMaps.rst
@@ -0,0 +1,496 @@
+===================================
+Stack maps and patch points in LLVM
+===================================
+
+.. contents::
+   :local:
+   :depth: 2
+
+Definitions
+===========
+
+In this document we refer to the "runtime" collectively as all
+components that serve as the LLVM client, including the LLVM IR
+generator, object code consumer, and code patcher.
+
+A stack map records the location of ``live values`` at a particular
+instruction address. These ``live values`` do not refer to all the
+LLVM values live across the stack map. Instead, they are only the
+values that the runtime requires to be live at this point. For
+example, they may be the values the runtime will need to resume
+program execution at that point independent of the compiled function
+containing the stack map.
+
+LLVM emits stack map data into the object code within a designated
+:ref:`stackmap-section`. This stack map data contains a record for
+each stack map. The record stores the stack map's instruction address
+and contains a entry for each mapped value. Each entry encodes a
+value's location as a register, stack offset, or constant.
+
+A patch point is an instruction address at which space is reserved for
+patching a new instruction sequence at run time. Patch points look
+much like calls to LLVM. They take arguments that follow a calling
+convention and may return a value. They also imply stack map
+generation, which allows the runtime to locate the patchpoint and
+find the location of ``live values`` at that point.
+
+Motivation
+==========
+
+This functionality is currently experimental but is potentially useful
+in a variety of settings, the most obvious being a runtime (JIT)
+compiler. Example applications of the patchpoint intrinsics are
+implementing an inline call cache for polymorphic method dispatch or
+optimizing the retrieval of properties in dynamically typed languages
+such as JavaScript.
+
+The intrinsics documented here are currently used by the JavaScript
+compiler within the open source WebKit project, see the `FTL JIT
+<https://trac.webkit.org/wiki/FTLJIT>`_, but they are designed to be
+used whenever stack maps or code patching are needed. Because the
+intrinsics have experimental status, compatibility across LLVM
+releases is not guaranteed.
+
+The stack map functionality described in this document is separate
+from the functionality described in
+:ref:`stack-map`. `GCFunctionMetadata` provides the location of
+pointers into a collected heap captured by the `GCRoot` intrinsic,
+which can also be considered a "stack map". Unlike the stack maps
+defined above, the `GCFunctionMetadata` stack map interface does not
+provide a way to associate live register values of arbitrary type with
+an instruction address, nor does it specify a format for the resulting
+stack map. The stack maps described here could potentially provide
+richer information to a garbage collecting runtime, but that usage
+will not be discussed in this document.
+
+Intrinsics
+==========
+
+The following two kinds of intrinsics can be used to implement stack
+maps and patch points: ``llvm.experimental.stackmap`` and
+``llvm.experimental.patchpoint``. Both kinds of intrinsics generate a
+stack map record, and they both allow some form of code patching. They
+can be used independently (i.e. ``llvm.experimental.patchpoint``
+implicitly generates a stack map without the need for an additional
+call to ``llvm.experimental.stackmap``). The choice of which to use
+depends on whether it is necessary to reserve space for code patching
+and whether any of the intrinsic arguments should be lowered according
+to calling conventions. ``llvm.experimental.stackmap`` does not
+reserve any space, nor does it expect any call arguments. If the
+runtime patches code at the stack map's address, it will destructively
+overwrite the program text. This is unlike
+``llvm.experimental.patchpoint``, which reserves space for in-place
+patching without overwriting surrounding code. The
+``llvm.experimental.patchpoint`` intrinsic also lowers a specified
+number of arguments according to its calling convention. This allows
+patched code to make in-place function calls without marshaling.
+
+Each instance of one of these intrinsics generates a stack map record
+in the :ref:`stackmap-section`. The record includes an ID, allowing
+the runtime to uniquely identify the stack map, and the offset within
+the code from the beginning of the enclosing function.
+
+'``llvm.experimental.stackmap``' Intrinsic
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+"""""""
+
+::
+
+      declare void
+        @llvm.experimental.stackmap(i64 <id>, i32 <numShadowBytes>, ...)
+
+Overview:
+"""""""""
+
+The '``llvm.experimental.stackmap``' intrinsic records the location of
+specified values in the stack map without generating any code.
+
+Operands:
+"""""""""
+
+The first operand is an ID to be encoded within the stack map. The
+second operand is the number of shadow bytes following the
+intrinsic. The variable number of operands that follow are the ``live
+values`` for which locations will be recorded in the stack map.
+
+To use this intrinsic as a bare-bones stack map, with no code patching
+support, the number of shadow bytes can be set to zero.
+
+Semantics:
+""""""""""
+
+The stack map intrinsic generates no code in place, unless nops are
+needed to cover its shadow (see below). However, its offset from
+function entry is stored in the stack map. This is the relative
+instruction address immediately following the instructions that
+precede the stack map.
+
+The stack map ID allows a runtime to locate the desired stack map
+record. LLVM passes this ID through directly to the stack map
+record without checking uniqueness.
+
+LLVM guarantees a shadow of instructions following the stack map's
+instruction offset during which neither the end of the basic block nor
+another call to ``llvm.experimental.stackmap`` or
+``llvm.experimental.patchpoint`` may occur. This allows the runtime to
+patch the code at this point in response to an event triggered from
+outside the code. The code for instructions following the stack map
+may be emitted in the stack map's shadow, and these instructions may
+be overwritten by destructive patching. Without shadow bytes, this
+destructive patching could overwrite program text or data outside the
+current function. We disallow overlapping stack map shadows so that
+the runtime does not need to consider this corner case.
+
+For example, a stack map with 8 byte shadow:
+
+.. code-block:: llvm
+
+  call void @runtime()
+  call void (i64, i32, ...)* @llvm.experimental.stackmap(i64 77, i32 8,
+                                                         i64* %ptr)
+  %val = load i64* %ptr
+  %add = add i64 %val, 3
+  ret i64 %add
+
+May require one byte of nop-padding:
+
+.. code-block:: none
+
+  0x00 callq _runtime
+  0x05 nop                <--- stack map address
+  0x06 movq (%rdi), %rax
+  0x07 addq $3, %rax
+  0x0a popq %rdx
+  0x0b ret                <---- end of 8-byte shadow
+
+Now, if the runtime needs to invalidate the compiled code, it may
+patch 8 bytes of code at the stack map's address at follows:
+
+.. code-block:: none
+
+  0x00 callq _runtime
+  0x05 movl  $0xffff, %rax <--- patched code at stack map address
+  0x0a callq *%rax         <---- end of 8-byte shadow
+
+This way, after the normal call to the runtime returns, the code will
+execute a patched call to a special entry point that can rebuild a
+stack frame from the values located by the stack map.
+
+'``llvm.experimental.patchpoint.*``' Intrinsic
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+"""""""
+
+::
+
+      declare void
+        @llvm.experimental.patchpoint.void(i64 <id>, i32 <numBytes>,
+                                           i8* <target>, i32 <numArgs>, ...)
+      declare i64
+        @llvm.experimental.patchpoint.i64(i64 <id>, i32 <numBytes>,
+                                          i8* <target>, i32 <numArgs>, ...)
+
+Overview:
+"""""""""
+
+The '``llvm.experimental.patchpoint.*``' intrinsics creates a function
+call to the specified ``<target>`` and records the location of specified
+values in the stack map.
+
+Operands:
+"""""""""
+
+The first operand is an ID, the second operand is the number of bytes
+reserved for the patchable region, the third operand is the target
+address of a function (optionally null), and the fourth operand
+specifies how many of the following variable operands are considered
+function call arguments. The remaining variable number of operands are
+the ``live values`` for which locations will be recorded in the stack
+map.
+
+Semantics:
+""""""""""
+
+The patch point intrinsic generates a stack map. It also emits a
+function call to the address specified by ``<target>`` if the address
+is not a constant null. The function call and its arguments are
+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.
+
+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
+still be reserved for patching, a call will be emitted, and a return
+value is allowed.
+
+The location of the arguments are not normally recorded in the stack
+map because they are already fixed by the calling convention. The
+remaining ``live values`` will have their location recorded, which
+could be a register, stack location, or constant. A special calling
+convention has been introduced for use with stack maps, anyregcc,
+which forces the arguments to be loaded into registers but allows
+those register to be dynamically allocated. These argument registers
+will have their register locations recorded in the stack map in
+addition to the remaining ``live values``.
+
+The patch point also emits nops to cover at least ``<numBytes>`` of
+instruction encoding space. Hence, the client must ensure that
+``<numBytes>`` is enough to encode a call to the target address on the
+supported targets. If the call target is constant null, then there is
+no minimum requirement. A zero-byte null target patchpoint is
+valid.
+
+The runtime may patch the code emitted for the patch point, including
+the call sequence and nops. However, the runtime may not assume
+anything about the code LLVM emits within the reserved space. Partial
+patching is not allowed. The runtime must patch all reserved bytes,
+padding with nops if necessary.
+
+This example shows a patch point reserving 15 bytes, with one argument
+in $rdi, and a return value in $rax per native calling convention:
+
+.. code-block:: llvm
+
+  %target = inttoptr i64 -281474976710654 to i8*
+  %val = call i64 (i64, i32, ...)*
+           @llvm.experimental.patchpoint.i64(i64 78, i32 15,
+                                             i8* %target, i32 1, i64* %ptr)
+  %add = add i64 %val, 3
+  ret i64 %add
+
+May generate:
+
+.. code-block:: none
+
+  0x00 movabsq $0xffff000000000002, %r11 <--- patch point address
+  0x0a callq   *%r11
+  0x0d nop
+  0x0e nop                               <--- end of reserved 15-bytes
+  0x0f addq    $0x3, %rax
+  0x10 movl    %rax, 8(%rsp)
+
+Note that no stack map locations will be recorded. If the patched code
+sequence does not need arguments fixed to specific calling convention
+registers, then the ``anyregcc`` convention may be used:
+
+.. code-block:: none
+
+  %val = call anyregcc @llvm.experimental.patchpoint(i64 78, i32 15,
+                                                     i8* %target, i32 1,
+                                                     i64* %ptr)
+
+The stack map now indicates the location of the %ptr argument and
+return value:
+
+.. code-block:: none
+
+  Stack Map: ID=78, Loc0=%r9 Loc1=%r8
+
+The patch code sequence may now use the argument that happened to be
+allocated in %r8 and return a value allocated in %r9:
+
+.. code-block:: none
+
+  0x00 movslq 4(%r8) %r9              <--- patched code at patch point address
+  0x03 nop
+  ...
+  0x0e nop                            <--- end of reserved 15-bytes
+  0x0f addq    $0x3, %r9
+  0x10 movl    %r9, 8(%rsp)
+
+.. _stackmap-format:
+
+Stack Map Format
+================
+
+The existence of a stack map or patch point intrinsic within an LLVM
+Module forces code emission to create a :ref:`stackmap-section`. The
+format of this section follows:
+
+.. code-block:: none
+
+  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] {
+    uint64 : Function Address
+    uint64 : Stack Size
+  }
+  Constants[NumConstants] {
+    uint64 : LargeConstant
+  }
+  StkMapRecord[NumRecords] {
+    uint64 : PatchPoint ID
+    uint32 : Instruction Offset
+    uint16 : Reserved (record flags)
+    uint16 : NumLocations
+    Location[NumLocations] {
+      uint8  : Register | Direct | Indirect | Constant | ConstantIndex
+      uint8  : Reserved (location flags)
+      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
+interpret the ``RegNum`` and ``Offset`` fields as follows:
+
+======== ========== =================== ===========================
+Encoding Type       Value               Description
+-------- ---------- ------------------- ---------------------------
+0x1      Register   Reg                 Value in a register
+0x2      Direct     Reg + Offset        Frame index value
+0x3      Indirect   [Reg + Offset]      Spilled value
+0x4      Constant   Offset              Small constant
+0x5      ConstIndex Constants[Offset]   Large constant
+======== ========== =================== ===========================
+
+In the common case, a value is available in a register, and the
+``Offset`` field will be zero. Values spilled to the stack are encoded
+as ``Indirect`` locations. The runtime must load those values from a
+stack address, typically in the form ``[BP + Offset]``. If an
+``alloca`` value is passed directly to a stack map intrinsic, then
+LLVM may fold the frame index into the stack map as an optimization to
+avoid allocating a register or stack slot. These frame indices will be
+encoded as ``Direct`` locations in the form ``BP + Offset``. LLVM may
+also optimize constants by emitting them directly in the stack map,
+either in the ``Offset`` of a ``Constant`` location or in the constant
+pool, referred to by ``ConstantIndex`` locations.
+
+At each callsite, a "liveout" register list is also recorded. These
+are the registers that are live across the stackmap and therefore must
+be saved by the runtime. This is an important optimization when the
+patchpoint intrinsic is used with a calling convention that by default
+preserves most registers as callee-save.
+
+Each entry in the liveout register list contains a DWARF register
+number and size in bytes. The stackmap format deliberately omits
+specific subregister information. Instead the runtime must interpret
+this information conservatively. For example, if the stackmap reports
+one byte at ``%rax``, then the value may be in either ``%al`` or
+``%ah``. It doesn't matter in practice, because the runtime will
+simply save ``%rax``. However, if the stackmap reports 16 bytes at
+``%ymm0``, then the runtime can safely optimize by saving only
+``%xmm0``.
+
+The stack map format is a contract between an LLVM SVN revision and
+the runtime. It is currently experimental and may change in the short
+term, but minimizing the need to update the runtime is
+important. Consequently, the stack map design is motivated by
+simplicity and extensibility. Compactness of the representation is
+secondary because the runtime is expected to parse the data
+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
+^^^^^^^^^^^^^^^^^
+
+A JIT compiler can easily access this section by providing its own
+memory manager via the LLVM C API
+``LLVMCreateSimpleMCJITMemoryManager()``. When creating the memory
+manager, the JIT provides a callback:
+``LLVMMemoryManagerAllocateDataSectionCallback()``. When LLVM creates
+this section, it invokes the callback and passes the section name. The
+JIT can record the in-memory address of the section at this time and
+later parse it to recover the stack map data.
+
+On Darwin, the stack map section name is "__llvm_stackmaps". The
+segment name is "__LLVM_STACKMAPS".
+
+Stack Map Usage
+===============
+
+The stack map support described in this document can be used to
+precisely determine the location of values at a specific position in
+the code. LLVM does not maintain any mapping between those values and
+any higher-level entity. The runtime must be able to interpret the
+stack map record given only the ID, offset, and the order of the
+locations, which LLVM preserves.
+
+Note that this is quite different from the goal of debug information,
+which is a best-effort attempt to track the location of named
+variables at every instruction.
+
+An important motivation for this design is to allow a runtime to
+commandeer a stack frame when execution reaches an instruction address
+associated with a stack map. The runtime must be able to rebuild a
+stack frame and resume program execution using the information
+provided by the stack map. For example, execution may resume in an
+interpreter or a recompiled version of the same function.
+
+This usage restricts LLVM optimization. Clearly, LLVM must not move
+stores across a stack map. However, loads must also be handled
+conservatively. If the load may trigger an exception, hoisting it
+above a stack map could be invalid. For example, the runtime may
+determine that a load is safe to execute without a type check given
+the current state of the type system. If the type system changes while
+some activation of the load's function exists on the stack, the load
+becomes unsafe. The runtime can prevent subsequent execution of that
+load by immediately patching any stack map location that lies between
+the current call site and the load (typically, the runtime would
+simply patch all stack map locations to invalidate the function). If
+the compiler had hoisted the load above the stack map, then the
+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. 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
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+As shown in :ref:`stackmap-section`, a Direct stack map location
+records the address of frame index. This address is itself the value
+that the runtime requested. This differs from Indirect locations,
+which refer to a stack locations from which the requested values must
+be loaded. Direct locations can communicate the address if an alloca,
+while Indirect locations handle register spills.
+
+For example:
+
+.. code-block:: none
+
+  entry:
+    %a = alloca i64...
+    llvm.experimental.stackmap(i64 <ID>, i32 <shadowBytes>, i64* %a)
+
+The runtime can determine this alloca's relative location on the
+stack immediately after compilation, or at any time thereafter. This
+differs from Register and Indirect locations, because the runtime can
+only read the values in those locations when execution reaches the
+instruction address of the stack map.
+
+This functionality requires LLVM to treat entry-block allocas
+specially when they are directly consumed by an intrinsics. (This is
+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.
diff --git a/docs/TableGen/BackEnds.rst b/docs/TableGen/BackEnds.rst
new file mode 100644
index 0000000..42de41d
--- /dev/null
+++ b/docs/TableGen/BackEnds.rst
@@ -0,0 +1,428 @@
+=================
+TableGen BackEnds
+=================
+
+.. contents::
+   :local:
+
+Introduction
+============
+
+TableGen backends are at the core of TableGen's functionality. The source files
+provide the semantics to a generated (in memory) structure, but it's up to the
+backend to print this out in a way that is meaningful to the user (normally a
+C program including a file or a textual list of warnings, options and error
+messages).
+
+TableGen is used by both LLVM and Clang with very different goals. LLVM uses it
+as a way to automate the generation of massive amounts of information regarding
+instructions, schedules, cores and architecture features. Some backends generate
+output that is consumed by more than one source file, so they need to be created
+in a way that is easy to use pre-processor tricks. Some backends can also print
+C code structures, so that they can be directly included as-is.
+
+Clang, on the other hand, uses it mainly for diagnostic messages (errors,
+warnings, tips) and attributes, so more on the textual end of the scale.
+
+LLVM BackEnds
+=============
+
+.. warning::
+   This document is raw. Each section below needs three sub-sections: description
+   of its purpose with a list of users, output generated from generic input, and
+   finally why it needed a new backend (in case there's something similar).
+
+Overall, each backend will take the same TableGen file type and transform into
+similar output for different targets/uses. There is an implicit contract between
+the TableGen files, the back-ends and their users.
+
+For instance, a global contract is that each back-end produces macro-guarded
+sections. Based on whether the file is included by a header or a source file,
+or even in which context of each file the include is being used, you have
+todefine a macro just before including it, to get the right output:
+
+.. code-block:: c++
+
+  #define GET_REGINFO_TARGET_DESC
+  #include "ARMGenRegisterInfo.inc"
+
+And just part of the generated file would be included. This is useful if
+you need the same information in multiple formats (instantiation, initialization,
+getter/setter functions, etc) from the same source TableGen file without having
+to re-compile the TableGen file multiple times.
+
+Sometimes, multiple macros might be defined before the same include file to
+output multiple blocks:
+
+.. code-block:: c++
+
+  #define GET_REGISTER_MATCHER
+  #define GET_SUBTARGET_FEATURE_NAME
+  #define GET_MATCHER_IMPLEMENTATION
+  #include "ARMGenAsmMatcher.inc"
+
+The macros will be undef'd automatically as they're used, in the include file.
+
+On all LLVM back-ends, the ``llvm-tblgen`` binary will be executed on the root
+TableGen file ``<Target>.td``, which should include all others. This guarantees
+that all information needed is accessible, and that no duplication is needed
+in the TbleGen files.
+
+CodeEmitter
+-----------
+
+**Purpose**: CodeEmitterGen uses the descriptions of instructions and their fields to
+construct an automated code emitter: a function that, given a MachineInstr,
+returns the (currently, 32-bit unsigned) value of the instruction.
+
+**Output**: C++ code, implementing the target's CodeEmitter
+class by overriding the virtual functions as ``<Target>CodeEmitter::function()``.
+
+**Usage**: Used to include directly at the end of ``<Target>CodeEmitter.cpp``, and
+with option `-mc-emitter` to be included in ``<Target>MCCodeEmitter.cpp``.
+
+RegisterInfo
+------------
+
+**Purpose**: This tablegen backend is responsible for emitting a description of a target
+register file for a code generator.  It uses instances of the Register,
+RegisterAliases, and RegisterClass classes to gather this information.
+
+**Output**: C++ code with enums and structures representing the register mappings,
+properties, masks, etc.
+
+**Usage**: Both on ``<Target>BaseRegisterInfo`` and ``<Target>MCTargetDesc`` (headers
+and source files) with macros defining in which they are for declaration vs.
+initialization issues.
+
+InstrInfo
+---------
+
+**Purpose**: This tablegen backend is responsible for emitting a description of the target
+instruction set for the code generator. (what are the differences from CodeEmitter?)
+
+**Output**: C++ code with enums and structures representing the register mappings,
+properties, masks, etc.
+
+**Usage**: Both on ``<Target>BaseInstrInfo`` and ``<Target>MCTargetDesc`` (headers
+and source files) with macros defining in which they are for declaration vs.
+
+AsmWriter
+---------
+
+**Purpose**: Emits an assembly printer for the current target.
+
+**Output**: Implementation of ``<Target>InstPrinter::printInstruction()``, among
+other things.
+
+**Usage**: Included directly into ``InstPrinter/<Target>InstPrinter.cpp``.
+
+AsmMatcher
+----------
+
+**Purpose**: Emits a target specifier matcher for
+converting parsed assembly operands in the MCInst structures. It also
+emits a matcher for custom operand parsing. Extensive documentation is
+written on the ``AsmMatcherEmitter.cpp`` file.
+
+**Output**: Assembler parsers' matcher functions, declarations, etc.
+
+**Usage**: Used in back-ends' ``AsmParser/<Target>AsmParser.cpp`` for
+building the AsmParser class.
+
+Disassembler
+------------
+
+**Purpose**: Contains disassembler table emitters for various
+architectures. Extensive documentation is written on the
+``DisassemblerEmitter.cpp`` file.
+
+**Output**: Decoding tables, static decoding functions, etc.
+
+**Usage**: Directly included in ``Disassembler/<Target>Disassembler.cpp``
+to cater for all default decodings, after all hand-made ones.
+
+PseudoLowering
+--------------
+
+**Purpose**: Generate pseudo instruction lowering.
+
+**Output**: Implements ``ARMAsmPrinter::emitPseudoExpansionLowering()``.
+
+**Usage**: Included directly into ``<Target>AsmPrinter.cpp``.
+
+CallingConv
+-----------
+
+**Purpose**: Responsible for emitting descriptions of the calling
+conventions supported by this target.
+
+**Output**: Implement static functions to deal with calling conventions
+chained by matching styles, returning false on no match.
+
+**Usage**: Used in ISelLowering and FastIsel as function pointers to
+implementation returned by a CC sellection function.
+
+DAGISel
+-------
+
+**Purpose**: Generate a DAG instruction selector.
+
+**Output**: Creates huge functions for automating DAG selection.
+
+**Usage**: Included in ``<Target>ISelDAGToDAG.cpp`` inside the target's
+implementation of ``SelectionDAGISel``.
+
+DFAPacketizer
+-------------
+
+**Purpose**: This class parses the Schedule.td file and produces an API that
+can be used to reason about whether an instruction can be added to a packet
+on a VLIW architecture. The class internally generates a deterministic finite
+automaton (DFA) that models all possible mappings of machine instructions
+to functional units as instructions are added to a packet.
+
+**Output**: Scheduling tables for GPU back-ends (Hexagon, AMD).
+
+**Usage**: Included directly on ``<Target>InstrInfo.cpp``.
+
+FastISel
+--------
+
+**Purpose**: This tablegen backend emits code for use by the "fast"
+instruction selection algorithm. See the comments at the top of
+lib/CodeGen/SelectionDAG/FastISel.cpp for background. This file
+scans through the target's tablegen instruction-info files
+and extracts instructions with obvious-looking patterns, and it emits
+code to look up these instructions by type and operator.
+
+**Output**: Generates ``Predicate`` and ``FastEmit`` methods.
+
+**Usage**: Implements private methods of the targets' implementation
+of ``FastISel`` class.
+
+Subtarget
+---------
+
+**Purpose**: Generate subtarget enumerations.
+
+**Output**: Enums, globals, local tables for sub-target information.
+
+**Usage**: Populates ``<Target>Subtarget`` and
+``MCTargetDesc/<Target>MCTargetDesc`` files (both headers and source).
+
+Intrinsic
+---------
+
+**Purpose**: Generate (target) intrinsic information.
+
+OptParserDefs
+-------------
+
+**Purpose**: Print enum values for a class.
+
+CTags
+-----
+
+**Purpose**: This tablegen backend emits an index of definitions in ctags(1)
+format. A helper script, utils/TableGen/tdtags, provides an easier-to-use
+interface; run 'tdtags -H' for documentation.
+
+Clang BackEnds
+==============
+
+ClangAttrClasses
+----------------
+
+**Purpose**: Creates Attrs.inc, which contains semantic attribute class
+declarations for any attribute in ``Attr.td`` that has not set ``ASTNode = 0``.
+This file is included as part of ``Attr.h``.
+
+ClangAttrParserStringSwitches
+-----------------------------
+
+**Purpose**: Creates AttrParserStringSwitches.inc, which contains
+StringSwitch::Case statements for parser-related string switches. Each switch
+is given its own macro (such as ``CLANG_ATTR_ARG_CONTEXT_LIST``, or
+``CLANG_ATTR_IDENTIFIER_ARG_LIST``), which is expected to be defined before
+including AttrParserStringSwitches.inc, and undefined after.
+
+ClangAttrImpl
+-------------
+
+**Purpose**: Creates AttrImpl.inc, which contains semantic attribute class
+definitions for any attribute in ``Attr.td`` that has not set ``ASTNode = 0``.
+This file is included as part of ``AttrImpl.cpp``.
+
+ClangAttrList
+-------------
+
+**Purpose**: Creates AttrList.inc, which is used when a list of semantic
+attribute identifiers is required. For instance, ``AttrKinds.h`` includes this
+file to generate the list of ``attr::Kind`` enumeration values. This list is
+separated out into multiple categories: attributes, inheritable attributes, and
+inheritable parameter attributes. This categorization happens automatically
+based on information in ``Attr.td`` and is used to implement the ``classof``
+functionality required for ``dyn_cast`` and similar APIs.
+
+ClangAttrPCHRead
+----------------
+
+**Purpose**: Creates AttrPCHRead.inc, which is used to deserialize attributes
+in the ``ASTReader::ReadAttributes`` function.
+
+ClangAttrPCHWrite
+-----------------
+
+**Purpose**: Creates AttrPCHWrite.inc, which is used to serialize attributes in
+the ``ASTWriter::WriteAttributes`` function.
+
+ClangAttrSpellings
+---------------------
+
+**Purpose**: Creates AttrSpellings.inc, which is used to implement the
+``__has_attribute`` feature test macro.
+
+ClangAttrSpellingListIndex
+--------------------------
+
+**Purpose**: Creates AttrSpellingListIndex.inc, which is used to map parsed
+attribute spellings (including which syntax or scope was used) to an attribute
+spelling list index. These spelling list index values are internal
+implementation details exposed via
+``AttributeList::getAttributeSpellingListIndex``.
+
+ClangAttrVisitor
+-------------------
+
+**Purpose**: Creates AttrVisitor.inc, which is used when implementing 
+recursive AST visitors.
+
+ClangAttrTemplateInstantiate
+----------------------------
+
+**Purpose**: Creates AttrTemplateInstantiate.inc, which implements the
+``instantiateTemplateAttribute`` function, used when instantiating a template
+that requires an attribute to be cloned.
+
+ClangAttrParsedAttrList
+-----------------------
+
+**Purpose**: Creates AttrParsedAttrList.inc, which is used to generate the
+``AttributeList::Kind`` parsed attribute enumeration.
+
+ClangAttrParsedAttrImpl
+-----------------------
+
+**Purpose**: Creates AttrParsedAttrImpl.inc, which is used by
+``AttributeList.cpp`` to implement several functions on the ``AttributeList``
+class. This functionality is implemented via the ``AttrInfoMap ParsedAttrInfo``
+array, which contains one element per parsed attribute object.
+
+ClangAttrParsedAttrKinds
+------------------------
+
+**Purpose**: Creates AttrParsedAttrKinds.inc, which is used to implement the
+``AttributeList::getKind`` function, mapping a string (and syntax) to a parsed
+attribute ``AttributeList::Kind`` enumeration.
+
+ClangAttrDump
+-------------
+
+**Purpose**: Creates AttrDump.inc, which dumps information about an attribute.
+It is used to implement ``ASTDumper::dumpAttr``.
+
+ClangDiagsDefs
+--------------
+
+Generate Clang diagnostics definitions.
+
+ClangDiagGroups
+---------------
+
+Generate Clang diagnostic groups.
+
+ClangDiagsIndexName
+-------------------
+
+Generate Clang diagnostic name index.
+
+ClangCommentNodes
+-----------------
+
+Generate Clang AST comment nodes.
+
+ClangDeclNodes
+--------------
+
+Generate Clang AST declaration nodes.
+
+ClangStmtNodes
+--------------
+
+Generate Clang AST statement nodes.
+
+ClangSACheckers
+---------------
+
+Generate Clang Static Analyzer checkers.
+
+ClangCommentHTMLTags
+--------------------
+
+Generate efficient matchers for HTML tag names that are used in documentation comments.
+
+ClangCommentHTMLTagsProperties
+------------------------------
+
+Generate efficient matchers for HTML tag properties.
+
+ClangCommentHTMLNamedCharacterReferences
+----------------------------------------
+
+Generate function to translate named character references to UTF-8 sequences.
+
+ClangCommentCommandInfo
+-----------------------
+
+Generate command properties for commands that are used in documentation comments.
+
+ClangCommentCommandList
+-----------------------
+
+Generate list of commands that are used in documentation comments.
+
+ArmNeon
+-------
+
+Generate arm_neon.h for clang.
+
+ArmNeonSema
+-----------
+
+Generate ARM NEON sema support for clang.
+
+ArmNeonTest
+-----------
+
+Generate ARM NEON tests for clang.
+
+AttrDocs
+--------
+
+**Purpose**: Creates ``AttributeReference.rst`` from ``AttrDocs.td``, and is
+used for documenting user-facing attributes.
+
+How to write a back-end
+=======================
+
+TODO.
+
+Until we get a step-by-step HowTo for writing TableGen backends, you can at
+least grab the boilerplate (build system, new files, etc.) from Clang's
+r173931.
+
+TODO: How they work, how to write one.  This section should not contain details
+about any particular backend, except maybe ``-print-enums`` as an example.  This
+should highlight the APIs in ``TableGen/Record.h``.
+
diff --git a/docs/TableGen/Deficiencies.rst b/docs/TableGen/Deficiencies.rst
new file mode 100644
index 0000000..a00aecd
--- /dev/null
+++ b/docs/TableGen/Deficiencies.rst
@@ -0,0 +1,31 @@
+=====================
+TableGen Deficiencies
+=====================
+
+.. contents::
+   :local:
+
+Introduction
+============
+
+Despite being very generic, TableGen has some deficiencies that have been
+pointed out numerous times. The common theme is that, while TableGen allows
+you to build Domain-Specific-Languages, the final languages that you create
+lack the power of other DSLs, which in turn increase considerably the size
+and complexity of TableGen files.
+
+At the same time, TableGen allows you to create virtually any meaning of
+the basic concepts via custom-made back-ends, which can pervert the original
+design and make it very hard for newcomers to understand it.
+
+There are some in favour of extending the semantics even more, but making sure
+back-ends adhere to strict rules. Others suggesting we should move to more
+powerful DSLs designed with specific purposes, or even re-using existing
+DSLs.
+
+Known Problems
+==============
+
+TODO: Add here frequently asked questions about why TableGen doesn't do
+what you want, how it might, and how we could extend/restrict it to
+be more use friendly.
diff --git a/docs/TableGen/LangIntro.rst b/docs/TableGen/LangIntro.rst
new file mode 100644
index 0000000..f139f35
--- /dev/null
+++ b/docs/TableGen/LangIntro.rst
@@ -0,0 +1,601 @@
+==============================
+TableGen Language Introduction
+==============================
+
+.. contents::
+   :local:
+
+.. warning::
+   This document is extremely rough. If you find something lacking, please
+   fix it, file a documentation bug, or ask about it on llvmdev.
+
+Introduction
+============
+
+This document is not meant to be a normative spec about the TableGen language
+in and of itself (i.e. how to understand a given construct in terms of how
+it affects the final set of records represented by the TableGen file). For
+the formal language specification, see :doc:`LangRef`.
+
+TableGen syntax
+===============
+
+TableGen doesn't care about the meaning of data (that is up to the backend to
+define), but it does care about syntax, and it enforces a simple type system.
+This section describes the syntax and the constructs allowed in a TableGen file.
+
+TableGen primitives
+-------------------
+
+TableGen comments
+^^^^^^^^^^^^^^^^^
+
+TableGen supports C++ style "``//``" comments, which run to the end of the
+line, and it also supports **nestable** "``/* */``" comments.
+
+.. _TableGen type:
+
+The TableGen type system
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+TableGen files are strongly typed, in a simple (but complete) type-system.
+These types are used to perform automatic conversions, check for errors, and to
+help interface designers constrain the input that they allow.  Every `value
+definition`_ is required to have an associated type.
+
+TableGen supports a mixture of very low-level types (such as ``bit``) and very
+high-level types (such as ``dag``).  This flexibility is what allows it to
+describe a wide range of information conveniently and compactly.  The TableGen
+types are:
+
+``bit``
+    A 'bit' is a boolean value that can hold either 0 or 1.
+
+``int``
+    The 'int' type represents a simple 32-bit integer value, such as 5.
+
+``string``
+    The 'string' type represents an ordered sequence of characters of arbitrary
+    length.
+
+``bits<n>``
+    A 'bits' type is an arbitrary, but fixed, size integer that is broken up
+    into individual bits.  This type is useful because it can handle some bits
+    being defined while others are undefined.
+
+``list<ty>``
+    This type represents a list whose elements are some other type.  The
+    contained type is arbitrary: it can even be another list type.
+
+Class type
+    Specifying a class name in a type context means that the defined value must
+    be a subclass of the specified class.  This is useful in conjunction with
+    the ``list`` type, for example, to constrain the elements of the list to a
+    common base class (e.g., a ``list<Register>`` can only contain definitions
+    derived from the "``Register``" class).
+
+``dag``
+    This type represents a nestable directed graph of elements.
+
+To date, these types have been sufficient for describing things that TableGen
+has been used for, but it is straight-forward to extend this list if needed.
+
+.. _TableGen expressions:
+
+TableGen values and expressions
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+TableGen allows for a pretty reasonable number of different expression forms
+when building up values.  These forms allow the TableGen file to be written in a
+natural syntax and flavor for the application.  The current expression forms
+supported include:
+
+``?``
+    uninitialized field
+
+``0b1001011``
+    binary integer value
+
+``07654321``
+    octal integer value (indicated by a leading 0)
+
+``7``
+    decimal integer value
+
+``0x7F``
+    hexadecimal integer value
+
+``"foo"``
+    string value
+
+``[{ ... }]``
+    usually called a "code fragment", but is just a multiline string literal
+
+``[ X, Y, Z ]<type>``
+    list value.  <type> is the type of the list element and is usually optional.
+    In rare cases, TableGen is unable to deduce the element type in which case
+    the user must specify it explicitly.
+
+``{ a, b, c }``
+    initializer for a "bits<3>" value
+
+``value``
+    value reference
+
+``value{17}``
+    access to one bit of a value
+
+``value{15-17}``
+    access to multiple bits of a value
+
+``DEF``
+    reference to a record definition
+
+``CLASS<val list>``
+    reference to a new anonymous definition of CLASS with the specified template
+    arguments.
+
+``X.Y``
+    reference to the subfield of a value
+
+``list[4-7,17,2-3]``
+    A slice of the 'list' list, including elements 4,5,6,7,17,2, and 3 from it.
+    Elements may be included multiple times.
+
+``foreach <var> = [ <list> ] in { <body> }``
+
+``foreach <var> = [ <list> ] in <def>``
+    Replicate <body> or <def>, replacing instances of <var> with each value
+    in <list>.  <var> is scoped at the level of the ``foreach`` loop and must
+    not conflict with any other object introduced in <body> or <def>.  Currently
+    only ``def``\s are expanded within <body>.
+
+``foreach <var> = 0-15 in ...``
+
+``foreach <var> = {0-15,32-47} in ...``
+    Loop over ranges of integers. The braces are required for multiple ranges.
+
+``(DEF a, b)``
+    a dag value.  The first element is required to be a record definition, the
+    remaining elements in the list may be arbitrary other values, including
+    nested ```dag``' values.
+
+``!strconcat(a, b)``
+    A string value that is the result of concatenating the 'a' and 'b' strings.
+
+``str1#str2``
+    "#" (paste) is a shorthand for !strconcat.  It may concatenate things that
+    are not quoted strings, in which case an implicit !cast<string> is done on
+    the operand of the paste.
+
+``!cast<type>(a)``
+    A symbol of type *type* obtained by looking up the string 'a' in the symbol
+    table.  If the type of 'a' does not match *type*, TableGen aborts with an
+    error. !cast<string> is a special case in that the argument must be an
+    object defined by a 'def' construct.
+
+``!subst(a, b, c)``
+    If 'a' and 'b' are of string type or are symbol references, substitute 'b'
+    for 'a' in 'c.'  This operation is analogous to $(subst) in GNU make.
+
+``!foreach(a, b, c)``
+    For each member 'b' of dag or list 'a' apply operator 'c.'  'b' is a dummy
+    variable that should be declared as a member variable of an instantiated
+    class.  This operation is analogous to $(foreach) in GNU make.
+
+``!head(a)``
+    The first element of list 'a.'
+
+``!tail(a)``
+    The 2nd-N elements of list 'a.'
+
+``!empty(a)``
+    An integer {0,1} indicating whether list 'a' is empty.
+
+``!if(a,b,c)``
+  'b' if the result of 'int' or 'bit' operator 'a' is nonzero, 'c' otherwise.
+
+``!eq(a,b)``
+    'bit 1' if string a is equal to string b, 0 otherwise.  This only operates
+    on string, int and bit objects.  Use !cast<string> to compare other types of
+    objects.
+
+Note that all of the values have rules specifying how they convert to values
+for different types.  These rules allow you to assign a value like "``7``"
+to a "``bits<4>``" value, for example.
+
+Classes and definitions
+-----------------------
+
+As mentioned in the :doc:`introduction <index>`, classes and definitions (collectively known as
+'records') in TableGen are the main high-level unit of information that TableGen
+collects.  Records are defined with a ``def`` or ``class`` keyword, the record
+name, and an optional list of "`template arguments`_".  If the record has
+superclasses, they are specified as a comma separated list that starts with a
+colon character ("``:``").  If `value definitions`_ or `let expressions`_ are
+needed for the class, they are enclosed in curly braces ("``{}``"); otherwise,
+the record ends with a semicolon.
+
+Here is a simple TableGen file:
+
+.. code-block:: llvm
+
+  class C { bit V = 1; }
+  def X : C;
+  def Y : C {
+    string Greeting = "hello";
+  }
+
+This example defines two definitions, ``X`` and ``Y``, both of which derive from
+the ``C`` class.  Because of this, they both get the ``V`` bit value.  The ``Y``
+definition also gets the Greeting member as well.
+
+In general, classes are useful for collecting together the commonality between a
+group of records and isolating it in a single place.  Also, classes permit the
+specification of default values for their subclasses, allowing the subclasses to
+override them as they wish.
+
+.. _value definition:
+.. _value definitions:
+
+Value definitions
+^^^^^^^^^^^^^^^^^
+
+Value definitions define named entries in records.  A value must be defined
+before it can be referred to as the operand for another value definition or
+before the value is reset with a `let expression`_.  A value is defined by
+specifying a `TableGen type`_ and a name.  If an initial value is available, it
+may be specified after the type with an equal sign.  Value definitions require
+terminating semicolons.
+
+.. _let expression:
+.. _let expressions:
+.. _"let" expressions within a record:
+
+'let' expressions
+^^^^^^^^^^^^^^^^^
+
+A record-level let expression is used to change the value of a value definition
+in a record.  This is primarily useful when a superclass defines a value that a
+derived class or definition wants to override.  Let expressions consist of the
+'``let``' keyword followed by a value name, an equal sign ("``=``"), and a new
+value.  For example, a new class could be added to the example above, redefining
+the ``V`` field for all of its subclasses:
+
+.. code-block:: llvm
+
+  class D : C { let V = 0; }
+  def Z : D;
+
+In this case, the ``Z`` definition will have a zero value for its ``V`` value,
+despite the fact that it derives (indirectly) from the ``C`` class, because the
+``D`` class overrode its value.
+
+.. _template arguments:
+
+Class template arguments
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+TableGen permits the definition of parameterized classes as well as normal
+concrete classes.  Parameterized TableGen classes specify a list of variable
+bindings (which may optionally have defaults) that are bound when used.  Here is
+a simple example:
+
+.. code-block:: llvm
+
+  class FPFormat<bits<3> val> {
+    bits<3> Value = val;
+  }
+  def NotFP      : FPFormat<0>;
+  def ZeroArgFP  : FPFormat<1>;
+  def OneArgFP   : FPFormat<2>;
+  def OneArgFPRW : FPFormat<3>;
+  def TwoArgFP   : FPFormat<4>;
+  def CompareFP  : FPFormat<5>;
+  def CondMovFP  : FPFormat<6>;
+  def SpecialFP  : FPFormat<7>;
+
+In this case, template arguments are used as a space efficient way to specify a
+list of "enumeration values", each with a "``Value``" field set to the specified
+integer.
+
+The more esoteric forms of `TableGen expressions`_ are useful in conjunction
+with template arguments.  As an example:
+
+.. code-block:: llvm
+
+  class ModRefVal<bits<2> val> {
+    bits<2> Value = val;
+  }
+
+  def None   : ModRefVal<0>;
+  def Mod    : ModRefVal<1>;
+  def Ref    : ModRefVal<2>;
+  def ModRef : ModRefVal<3>;
+
+  class Value<ModRefVal MR> {
+    // Decode some information into a more convenient format, while providing
+    // a nice interface to the user of the "Value" class.
+    bit isMod = MR.Value{0};
+    bit isRef = MR.Value{1};
+
+    // other stuff...
+  }
+
+  // Example uses
+  def bork : Value<Mod>;
+  def zork : Value<Ref>;
+  def hork : Value<ModRef>;
+
+This is obviously a contrived example, but it shows how template arguments can
+be used to decouple the interface provided to the user of the class from the
+actual internal data representation expected by the class.  In this case,
+running ``llvm-tblgen`` on the example prints the following definitions:
+
+.. code-block:: llvm
+
+  def bork {      // Value
+    bit isMod = 1;
+    bit isRef = 0;
+  }
+  def hork {      // Value
+    bit isMod = 1;
+    bit isRef = 1;
+  }
+  def zork {      // Value
+    bit isMod = 0;
+    bit isRef = 1;
+  }
+
+This shows that TableGen was able to dig into the argument and extract a piece
+of information that was requested by the designer of the "Value" class.  For
+more realistic examples, please see existing users of TableGen, such as the X86
+backend.
+
+Multiclass definitions and instances
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+While classes with template arguments are a good way to factor commonality
+between two instances of a definition, multiclasses allow a convenient notation
+for defining multiple definitions at once (instances of implicitly constructed
+classes).  For example, consider an 3-address instruction set whose instructions
+come in two forms: "``reg = reg op reg``" and "``reg = reg op imm``"
+(e.g. SPARC). In this case, you'd like to specify in one place that this
+commonality exists, then in a separate place indicate what all the ops are.
+
+Here is an example TableGen fragment that shows this idea:
+
+.. code-block:: llvm
+
+  def ops;
+  def GPR;
+  def Imm;
+  class inst<int opc, string asmstr, dag operandlist>;
+
+  multiclass ri_inst<int opc, string asmstr> {
+    def _rr : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
+                   (ops GPR:$dst, GPR:$src1, GPR:$src2)>;
+    def _ri : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
+                   (ops GPR:$dst, GPR:$src1, Imm:$src2)>;
+  }
+
+  // Instantiations of the ri_inst multiclass.
+  defm ADD : ri_inst<0b111, "add">;
+  defm SUB : ri_inst<0b101, "sub">;
+  defm MUL : ri_inst<0b100, "mul">;
+  ...
+
+The name of the resultant definitions has the multidef fragment names appended
+to them, so this defines ``ADD_rr``, ``ADD_ri``, ``SUB_rr``, etc.  A defm may
+inherit from multiple multiclasses, instantiating definitions from each
+multiclass.  Using a multiclass this way is exactly equivalent to instantiating
+the classes multiple times yourself, e.g. by writing:
+
+.. code-block:: llvm
+
+  def ops;
+  def GPR;
+  def Imm;
+  class inst<int opc, string asmstr, dag operandlist>;
+
+  class rrinst<int opc, string asmstr>
+    : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
+           (ops GPR:$dst, GPR:$src1, GPR:$src2)>;
+
+  class riinst<int opc, string asmstr>
+    : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
+           (ops GPR:$dst, GPR:$src1, Imm:$src2)>;
+
+  // Instantiations of the ri_inst multiclass.
+  def ADD_rr : rrinst<0b111, "add">;
+  def ADD_ri : riinst<0b111, "add">;
+  def SUB_rr : rrinst<0b101, "sub">;
+  def SUB_ri : riinst<0b101, "sub">;
+  def MUL_rr : rrinst<0b100, "mul">;
+  def MUL_ri : riinst<0b100, "mul">;
+  ...
+
+A ``defm`` can also be used inside a multiclass providing several levels of
+multiclass instantiations.
+
+.. code-block:: llvm
+
+  class Instruction<bits<4> opc, string Name> {
+    bits<4> opcode = opc;
+    string name = Name;
+  }
+
+  multiclass basic_r<bits<4> opc> {
+    def rr : Instruction<opc, "rr">;
+    def rm : Instruction<opc, "rm">;
+  }
+
+  multiclass basic_s<bits<4> opc> {
+    defm SS : basic_r<opc>;
+    defm SD : basic_r<opc>;
+    def X : Instruction<opc, "x">;
+  }
+
+  multiclass basic_p<bits<4> opc> {
+    defm PS : basic_r<opc>;
+    defm PD : basic_r<opc>;
+    def Y : Instruction<opc, "y">;
+  }
+
+  defm ADD : basic_s<0xf>, basic_p<0xf>;
+  ...
+
+  // Results
+  def ADDPDrm { ...
+  def ADDPDrr { ...
+  def ADDPSrm { ...
+  def ADDPSrr { ...
+  def ADDSDrm { ...
+  def ADDSDrr { ...
+  def ADDY { ...
+  def ADDX { ...
+
+``defm`` declarations can inherit from classes too, the rule to follow is that
+the class list must start after the last multiclass, and there must be at least
+one multiclass before them.
+
+.. code-block:: llvm
+
+  class XD { bits<4> Prefix = 11; }
+  class XS { bits<4> Prefix = 12; }
+
+  class I<bits<4> op> {
+    bits<4> opcode = op;
+  }
+
+  multiclass R {
+    def rr : I<4>;
+    def rm : I<2>;
+  }
+
+  multiclass Y {
+    defm SS : R, XD;
+    defm SD : R, XS;
+  }
+
+  defm Instr : Y;
+
+  // Results
+  def InstrSDrm {
+    bits<4> opcode = { 0, 0, 1, 0 };
+    bits<4> Prefix = { 1, 1, 0, 0 };
+  }
+  ...
+  def InstrSSrr {
+    bits<4> opcode = { 0, 1, 0, 0 };
+    bits<4> Prefix = { 1, 0, 1, 1 };
+  }
+
+File scope entities
+-------------------
+
+File inclusion
+^^^^^^^^^^^^^^
+
+TableGen supports the '``include``' token, which textually substitutes the
+specified file in place of the include directive.  The filename should be
+specified as a double quoted string immediately after the '``include``' keyword.
+Example:
+
+.. code-block:: llvm
+
+  include "foo.td"
+
+'let' expressions
+^^^^^^^^^^^^^^^^^
+
+"Let" expressions at file scope are similar to `"let" expressions within a
+record`_, except they can specify a value binding for multiple records at a
+time, and may be useful in certain other cases.  File-scope let expressions are
+really just another way that TableGen allows the end-user to factor out
+commonality from the records.
+
+File-scope "let" expressions take a comma-separated list of bindings to apply,
+and one or more records to bind the values in.  Here are some examples:
+
+.. code-block:: llvm
+
+  let isTerminator = 1, isReturn = 1, isBarrier = 1, hasCtrlDep = 1 in
+    def RET : I<0xC3, RawFrm, (outs), (ins), "ret", [(X86retflag 0)]>;
+
+  let isCall = 1 in
+    // All calls clobber the non-callee saved registers...
+    let Defs = [EAX, ECX, EDX, FP0, FP1, FP2, FP3, FP4, FP5, FP6, ST0,
+                MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7,
+                XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, EFLAGS] in {
+      def CALLpcrel32 : Ii32<0xE8, RawFrm, (outs), (ins i32imm:$dst,variable_ops),
+                             "call\t${dst:call}", []>;
+      def CALL32r     : I<0xFF, MRM2r, (outs), (ins GR32:$dst, variable_ops),
+                          "call\t{*}$dst", [(X86call GR32:$dst)]>;
+      def CALL32m     : I<0xFF, MRM2m, (outs), (ins i32mem:$dst, variable_ops),
+                          "call\t{*}$dst", []>;
+    }
+
+File-scope "let" expressions are often useful when a couple of definitions need
+to be added to several records, and the records do not otherwise need to be
+opened, as in the case with the ``CALL*`` instructions above.
+
+It's also possible to use "let" expressions inside multiclasses, providing more
+ways to factor out commonality from the records, specially if using several
+levels of multiclass instantiations. This also avoids the need of using "let"
+expressions within subsequent records inside a multiclass.
+
+.. code-block:: llvm
+
+  multiclass basic_r<bits<4> opc> {
+    let Predicates = [HasSSE2] in {
+      def rr : Instruction<opc, "rr">;
+      def rm : Instruction<opc, "rm">;
+    }
+    let Predicates = [HasSSE3] in
+      def rx : Instruction<opc, "rx">;
+  }
+
+  multiclass basic_ss<bits<4> opc> {
+    let IsDouble = 0 in
+      defm SS : basic_r<opc>;
+
+    let IsDouble = 1 in
+      defm SD : basic_r<opc>;
+  }
+
+  defm ADD : basic_ss<0xf>;
+
+Looping
+^^^^^^^
+
+TableGen supports the '``foreach``' block, which textually replicates the loop
+body, substituting iterator values for iterator references in the body.
+Example:
+
+.. code-block:: llvm
+
+  foreach i = [0, 1, 2, 3] in {
+    def R#i : Register<...>;
+    def F#i : Register<...>;
+  }
+
+This will create objects ``R0``, ``R1``, ``R2`` and ``R3``.  ``foreach`` blocks
+may be nested. If there is only one item in the body the braces may be
+elided:
+
+.. code-block:: llvm
+
+  foreach i = [0, 1, 2, 3] in
+    def R#i : Register<...>;
+
+Code Generator backend info
+===========================
+
+Expressions used by code generator to describe instructions and isel patterns:
+
+``(implicit a)``
+    an implicitly defined physical register.  This tells the dag instruction
+    selection emitter the input pattern's extra definitions matches implicit
+    physical register definitions.
+
diff --git a/docs/TableGen/LangRef.rst b/docs/TableGen/LangRef.rst
index bd28a90..e3db3aa 100644
--- a/docs/TableGen/LangRef.rst
+++ b/docs/TableGen/LangRef.rst
@@ -74,6 +74,9 @@ TableGen also has two string-like literals:
    TokString: '"' <non-'"' characters and C-like escapes> '"'
    TokCodeFragment: "[{" <shortest text not containing "}]"> "}]"
 
+:token:`TokCodeFragment` is essentially a multiline string literal
+delimited by ``[{`` and ``}]``.
+
 .. note::
    The current implementation accepts the following C-like escapes::
 
diff --git a/docs/TableGen/index.rst b/docs/TableGen/index.rst
new file mode 100644
index 0000000..0860afa
--- /dev/null
+++ b/docs/TableGen/index.rst
@@ -0,0 +1,309 @@
+========
+TableGen
+========
+
+.. contents::
+   :local:
+
+.. toctree::
+   :hidden:
+
+   BackEnds
+   LangRef
+   LangIntro
+   Deficiencies
+
+Introduction
+============
+
+TableGen's purpose is to help a human develop and maintain records of
+domain-specific information.  Because there may be a large number of these
+records, it is specifically designed to allow writing flexible descriptions and
+for common features of these records to be factored out.  This reduces the
+amount of duplication in the description, reduces the chance of error, and makes
+it easier to structure domain specific information.
+
+The core part of TableGen parses a file, instantiates the declarations, and
+hands the result off to a domain-specific `backend`_ for processing.
+
+The current major users of TableGen are :doc:`../CodeGenerator`
+and the
+`Clang diagnostics and attributes <http://clang.llvm.org/docs/UsersManual.html#controlling-errors-and-warnings>`_.
+
+Note that if you work on TableGen much, and use emacs or vim, that you can find
+an emacs "TableGen mode" and a vim language file in the ``llvm/utils/emacs`` and
+``llvm/utils/vim`` directories of your LLVM distribution, respectively.
+
+.. _intro:
+
+
+The TableGen program
+====================
+
+TableGen files are interpreted by the TableGen program: `llvm-tblgen` available
+on your build directory under `bin`. It is not installed in the system (or where
+your sysroot is set to), since it has no use beyond LLVM's build process.
+
+Running TableGen
+----------------
+
+TableGen runs just like any other LLVM tool.  The first (optional) argument
+specifies the file to read.  If a filename is not specified, ``llvm-tblgen``
+reads from standard input.
+
+To be useful, one of the `backends`_ must be used.  These backends are
+selectable on the command line (type '``llvm-tblgen -help``' for a list).  For
+example, to get a list of all of the definitions that subclass a particular type
+(which can be useful for building up an enum list of these records), use the
+``-print-enums`` option:
+
+.. code-block:: bash
+
+  $ llvm-tblgen X86.td -print-enums -class=Register
+  AH, AL, AX, BH, BL, BP, BPL, BX, CH, CL, CX, DH, DI, DIL, DL, DX, EAX, EBP, EBX,
+  ECX, EDI, EDX, EFLAGS, EIP, ESI, ESP, FP0, FP1, FP2, FP3, FP4, FP5, FP6, IP,
+  MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, R10, R10B, R10D, R10W, R11, R11B, R11D,
+  R11W, R12, R12B, R12D, R12W, R13, R13B, R13D, R13W, R14, R14B, R14D, R14W, R15,
+  R15B, R15D, R15W, R8, R8B, R8D, R8W, R9, R9B, R9D, R9W, RAX, RBP, RBX, RCX, RDI,
+  RDX, RIP, RSI, RSP, SI, SIL, SP, SPL, ST0, ST1, ST2, ST3, ST4, ST5, ST6, ST7,
+  XMM0, XMM1, XMM10, XMM11, XMM12, XMM13, XMM14, XMM15, XMM2, XMM3, XMM4, XMM5,
+  XMM6, XMM7, XMM8, XMM9,
+
+  $ llvm-tblgen X86.td -print-enums -class=Instruction 
+  ABS_F, ABS_Fp32, ABS_Fp64, ABS_Fp80, ADC32mi, ADC32mi8, ADC32mr, ADC32ri,
+  ADC32ri8, ADC32rm, ADC32rr, ADC64mi32, ADC64mi8, ADC64mr, ADC64ri32, ADC64ri8,
+  ADC64rm, ADC64rr, ADD16mi, ADD16mi8, ADD16mr, ADD16ri, ADD16ri8, ADD16rm,
+  ADD16rr, ADD32mi, ADD32mi8, ADD32mr, ADD32ri, ADD32ri8, ADD32rm, ADD32rr,
+  ADD64mi32, ADD64mi8, ADD64mr, ADD64ri32, ...
+
+The default backend prints out all of the records.
+
+If you plan to use TableGen, you will most likely have to write a `backend`_
+that extracts the information specific to what you need and formats it in the
+appropriate way.
+
+Example
+-------
+
+With no other arguments, `llvm-tblgen` parses the specified file and prints out all
+of the classes, then all of the definitions.  This is a good way to see what the
+various definitions expand to fully.  Running this on the ``X86.td`` file prints
+this (at the time of this writing):
+
+.. code-block:: llvm
+
+  ...
+  def ADD32rr {   // Instruction X86Inst I
+    string Namespace = "X86";
+    dag OutOperandList = (outs GR32:$dst);
+    dag InOperandList = (ins GR32:$src1, GR32:$src2);
+    string AsmString = "add{l}\t{$src2, $dst|$dst, $src2}";
+    list<dag> Pattern = [(set GR32:$dst, (add GR32:$src1, GR32:$src2))];
+    list<Register> Uses = [];
+    list<Register> Defs = [EFLAGS];
+    list<Predicate> Predicates = [];
+    int CodeSize = 3;
+    int AddedComplexity = 0;
+    bit isReturn = 0;
+    bit isBranch = 0;
+    bit isIndirectBranch = 0;
+    bit isBarrier = 0;
+    bit isCall = 0;
+    bit canFoldAsLoad = 0;
+    bit mayLoad = 0;
+    bit mayStore = 0;
+    bit isImplicitDef = 0;
+    bit isConvertibleToThreeAddress = 1;
+    bit isCommutable = 1;
+    bit isTerminator = 0;
+    bit isReMaterializable = 0;
+    bit isPredicable = 0;
+    bit hasDelaySlot = 0;
+    bit usesCustomInserter = 0;
+    bit hasCtrlDep = 0;
+    bit isNotDuplicable = 0;
+    bit hasSideEffects = 0;
+    bit neverHasSideEffects = 0;
+    InstrItinClass Itinerary = NoItinerary;
+    string Constraints = "";
+    string DisableEncoding = "";
+    bits<8> Opcode = { 0, 0, 0, 0, 0, 0, 0, 1 };
+    Format Form = MRMDestReg;
+    bits<6> FormBits = { 0, 0, 0, 0, 1, 1 };
+    ImmType ImmT = NoImm;
+    bits<3> ImmTypeBits = { 0, 0, 0 };
+    bit hasOpSizePrefix = 0;
+    bit hasAdSizePrefix = 0;
+    bits<4> Prefix = { 0, 0, 0, 0 };
+    bit hasREX_WPrefix = 0;
+    FPFormat FPForm = ?;
+    bits<3> FPFormBits = { 0, 0, 0 };
+  }
+  ...
+
+This definition corresponds to the 32-bit register-register ``add`` instruction
+of the x86 architecture.  ``def ADD32rr`` defines a record named
+``ADD32rr``, and the comment at the end of the line indicates the superclasses
+of the definition.  The body of the record contains all of the data that
+TableGen assembled for the record, indicating that the instruction is part of
+the "X86" namespace, the pattern indicating how the instruction is selected by
+the code generator, that it is a two-address instruction, has a particular
+encoding, etc.  The contents and semantics of the information in the record are
+specific to the needs of the X86 backend, and are only shown as an example.
+
+As you can see, a lot of information is needed for every instruction supported
+by the code generator, and specifying it all manually would be unmaintainable,
+prone to bugs, and tiring to do in the first place.  Because we are using
+TableGen, all of the information was derived from the following definition:
+
+.. code-block:: llvm
+
+  let Defs = [EFLAGS],
+      isCommutable = 1,                  // X = ADD Y,Z --> X = ADD Z,Y
+      isConvertibleToThreeAddress = 1 in // Can transform into LEA.
+  def ADD32rr  : I<0x01, MRMDestReg, (outs GR32:$dst),
+                                     (ins GR32:$src1, GR32:$src2),
+                   "add{l}\t{$src2, $dst|$dst, $src2}",
+                   [(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
+
+This definition makes use of the custom class ``I`` (extended from the custom
+class ``X86Inst``), which is defined in the X86-specific TableGen file, to
+factor out the common features that instructions of its class share.  A key
+feature of TableGen is that it allows the end-user to define the abstractions
+they prefer to use when describing their information.
+
+Each ``def`` record has a special entry called "NAME".  This is the name of the
+record ("``ADD32rr``" above).  In the general case ``def`` names can be formed
+from various kinds of string processing expressions and ``NAME`` resolves to the
+final value obtained after resolving all of those expressions.  The user may
+refer to ``NAME`` anywhere she desires to use the ultimate name of the ``def``.
+``NAME`` should not be defined anywhere else in user code to avoid conflicts.
+
+Syntax
+======
+
+TableGen has a syntax that is loosely based on C++ templates, with built-in
+types and specification. In addition, TableGen's syntax introduces some
+automation concepts like multiclass, foreach, let, etc.
+
+Basic concepts
+--------------
+
+TableGen files consist of two key parts: 'classes' and 'definitions', both of
+which are considered 'records'.
+
+**TableGen records** have a unique name, a list of values, and a list of
+superclasses.  The list of values is the main data that TableGen builds for each
+record; it is this that holds the domain specific information for the
+application.  The interpretation of this data is left to a specific `backend`_,
+but the structure and format rules are taken care of and are fixed by
+TableGen.
+
+**TableGen definitions** are the concrete form of 'records'.  These generally do
+not have any undefined values, and are marked with the '``def``' keyword.
+
+.. code-block:: llvm
+
+  def FeatureFPARMv8 : SubtargetFeature<"fp-armv8", "HasFPARMv8", "true",
+                                        "Enable ARMv8 FP">;
+
+In this example, FeatureFPARMv8 is ``SubtargetFeature`` record initialised
+with some values. The names of the classes are defined via the
+keyword `class` either on the same file or some other included. Most target
+TableGen files include the generic ones in ``include/llvm/Target``.
+
+**TableGen classes** are abstract records that are used to build and describe
+other records.  These classes allow the end-user to build abstractions for
+either the domain they are targeting (such as "Register", "RegisterClass", and
+"Instruction" in the LLVM code generator) or for the implementor to help factor
+out common properties of records (such as "FPInst", which is used to represent
+floating point instructions in the X86 backend).  TableGen keeps track of all of
+the classes that are used to build up a definition, so the backend can find all
+definitions of a particular class, such as "Instruction".
+
+.. code-block:: llvm
+
+ class ProcNoItin<string Name, list<SubtargetFeature> Features>
+       : Processor<Name, NoItineraries, Features>;
+  
+Here, the class ProcNoItin, receiving parameters `Name` of type `string` and
+a list of target features is specializing the class Processor by passing the
+arguments down as well as hard-coding NoItineraries.
+
+**TableGen multiclasses** are groups of abstract records that are instantiated
+all at once.  Each instantiation can result in multiple TableGen definitions.
+If a multiclass inherits from another multiclass, the definitions in the
+sub-multiclass become part of the current multiclass, as if they were declared
+in the current multiclass.
+
+.. code-block:: llvm
+
+  multiclass ro_signed_pats<string T, string Rm, dag Base, dag Offset, dag Extend,
+                          dag address, ValueType sty> {
+  def : Pat<(i32 (!cast<SDNode>("sextload" # sty) address)),
+            (!cast<Instruction>("LDRS" # T # "w_" # Rm # "_RegOffset")
+              Base, Offset, Extend)>;
+
+  def : Pat<(i64 (!cast<SDNode>("sextload" # sty) address)),
+            (!cast<Instruction>("LDRS" # T # "x_" # Rm # "_RegOffset")
+              Base, Offset, Extend)>;
+  }
+
+  defm : ro_signed_pats<"B", Rm, Base, Offset, Extend,
+                        !foreach(decls.pattern, address,
+                                 !subst(SHIFT, imm_eq0, decls.pattern)),
+                        i8>;
+
+
+
+See the :doc:`TableGen Language Introduction <LangIntro>` for more generic
+information on the usage of the language, and the
+:doc:`TableGen Language Reference <LangRef>` for more in-depth description
+of the formal language specification.
+
+.. _backend:
+.. _backends:
+
+TableGen backends
+=================
+
+TableGen files have no real meaning without a back-end. The default operation
+of running ``llvm-tblgen`` is to print the information in a textual format, but
+that's only useful for debugging of the TableGen files themselves. The power
+in TableGen is, however, to interpret the source files into an internal 
+representation that can be generated into anything you want.
+
+Current usage of TableGen is to create include huge files with tables that you
+can either include directly (if the output is in the language you're coding),
+or be used in pre-processing via macros surrounding the include of the file.
+
+Direct output can be used if the back-end already prints a table in C format
+or if the output is just a list of strings (for error and warning messages).
+Pre-processed output should be used if the same information needs to be used
+in different contexts (like Instruction names), so your back-end should print
+a meta-information list that can be shaped into different compile-time formats.
+
+See the `TableGen BackEnds <BackEnds.html>`_ for more information.
+
+TableGen Deficiencies
+=====================
+
+Despite being very generic, TableGen has some deficiencies that have been
+pointed out numerous times. The common theme is that, while TableGen allows
+you to build Domain-Specific-Languages, the final languages that you create
+lack the power of other DSLs, which in turn increase considerably the size
+and complecity of TableGen files.
+
+At the same time, TableGen allows you to create virtually any meaning of
+the basic concepts via custom-made back-ends, which can pervert the original
+design and make it very hard for newcomers to understand the evil TableGen
+file.
+
+There are some in favour of extending the semantics even more, but making sure
+back-ends adhere to strict rules. Others are suggesting we should move to less,
+more powerful DSLs designed with specific purposes, or even re-using existing
+DSLs.
+
+Either way, this is a discussion that will likely span across several years,
+if not decades. You can read more in the `TableGen Deficiencies <Deficiencies.html>`_
+document.
diff --git a/docs/TableGenFundamentals.rst b/docs/TableGenFundamentals.rst
index 4fe4bb9..75e82ae 100644
--- a/docs/TableGenFundamentals.rst
+++ b/docs/TableGenFundamentals.rst
@@ -2,799 +2,9 @@
 TableGen Fundamentals
 =====================
 
-.. contents::
-   :local:
+Moved
+=====
 
-Introduction
-============
-
-TableGen's purpose is to help a human develop and maintain records of
-domain-specific information.  Because there may be a large number of these
-records, it is specifically designed to allow writing flexible descriptions and
-for common features of these records to be factored out.  This reduces the
-amount of duplication in the description, reduces the chance of error, and makes
-it easier to structure domain specific information.
-
-The core part of TableGen `parses a file`_, instantiates the declarations, and
-hands the result off to a domain-specific `TableGen backend`_ for processing.
-The current major user of TableGen is the `LLVM code
-generator <CodeGenerator.html>`_.
-
-Note that if you work on TableGen much, and use emacs or vim, that you can find
-an emacs "TableGen mode" and a vim language file in the ``llvm/utils/emacs`` and
-``llvm/utils/vim`` directories of your LLVM distribution, respectively.
-
-.. _intro:
-
-Basic concepts
---------------
-
-TableGen files consist of two key parts: 'classes' and 'definitions', both of
-which are considered 'records'.
-
-**TableGen records** have a unique name, a list of values, and a list of
-superclasses.  The list of values is the main data that TableGen builds for each
-record; it is this that holds the domain specific information for the
-application.  The interpretation of this data is left to a specific `TableGen
-backend`_, but the structure and format rules are taken care of and are fixed by
-TableGen.
-
-**TableGen definitions** are the concrete form of 'records'.  These generally do
-not have any undefined values, and are marked with the '``def``' keyword.
-
-**TableGen classes** are abstract records that are used to build and describe
-other records.  These 'classes' allow the end-user to build abstractions for
-either the domain they are targeting (such as "Register", "RegisterClass", and
-"Instruction" in the LLVM code generator) or for the implementor to help factor
-out common properties of records (such as "FPInst", which is used to represent
-floating point instructions in the X86 backend).  TableGen keeps track of all of
-the classes that are used to build up a definition, so the backend can find all
-definitions of a particular class, such as "Instruction".
-
-**TableGen multiclasses** are groups of abstract records that are instantiated
-all at once.  Each instantiation can result in multiple TableGen definitions.
-If a multiclass inherits from another multiclass, the definitions in the
-sub-multiclass become part of the current multiclass, as if they were declared
-in the current multiclass.
-
-.. _described above:
-
-An example record
------------------
-
-With no other arguments, TableGen parses the specified file and prints out all
-of the classes, then all of the definitions.  This is a good way to see what the
-various definitions expand to fully.  Running this on the ``X86.td`` file prints
-this (at the time of this writing):
-
-.. code-block:: llvm
-
-  ...
-  def ADD32rr {   // Instruction X86Inst I
-    string Namespace = "X86";
-    dag OutOperandList = (outs GR32:$dst);
-    dag InOperandList = (ins GR32:$src1, GR32:$src2);
-    string AsmString = "add{l}\t{$src2, $dst|$dst, $src2}";
-    list<dag> Pattern = [(set GR32:$dst, (add GR32:$src1, GR32:$src2))];
-    list<Register> Uses = [];
-    list<Register> Defs = [EFLAGS];
-    list<Predicate> Predicates = [];
-    int CodeSize = 3;
-    int AddedComplexity = 0;
-    bit isReturn = 0;
-    bit isBranch = 0;
-    bit isIndirectBranch = 0;
-    bit isBarrier = 0;
-    bit isCall = 0;
-    bit canFoldAsLoad = 0;
-    bit mayLoad = 0;
-    bit mayStore = 0;
-    bit isImplicitDef = 0;
-    bit isConvertibleToThreeAddress = 1;
-    bit isCommutable = 1;
-    bit isTerminator = 0;
-    bit isReMaterializable = 0;
-    bit isPredicable = 0;
-    bit hasDelaySlot = 0;
-    bit usesCustomInserter = 0;
-    bit hasCtrlDep = 0;
-    bit isNotDuplicable = 0;
-    bit hasSideEffects = 0;
-    bit neverHasSideEffects = 0;
-    InstrItinClass Itinerary = NoItinerary;
-    string Constraints = "";
-    string DisableEncoding = "";
-    bits<8> Opcode = { 0, 0, 0, 0, 0, 0, 0, 1 };
-    Format Form = MRMDestReg;
-    bits<6> FormBits = { 0, 0, 0, 0, 1, 1 };
-    ImmType ImmT = NoImm;
-    bits<3> ImmTypeBits = { 0, 0, 0 };
-    bit hasOpSizePrefix = 0;
-    bit hasAdSizePrefix = 0;
-    bits<4> Prefix = { 0, 0, 0, 0 };
-    bit hasREX_WPrefix = 0;
-    FPFormat FPForm = ?;
-    bits<3> FPFormBits = { 0, 0, 0 };
-  }
-  ...
-
-This definition corresponds to the 32-bit register-register ``add`` instruction
-of the x86 architecture.  ``def ADD32rr`` defines a record named
-``ADD32rr``, and the comment at the end of the line indicates the superclasses
-of the definition.  The body of the record contains all of the data that
-TableGen assembled for the record, indicating that the instruction is part of
-the "X86" namespace, the pattern indicating how the instruction should be
-emitted into the assembly file, that it is a two-address instruction, has a
-particular encoding, etc.  The contents and semantics of the information in the
-record are specific to the needs of the X86 backend, and are only shown as an
-example.
-
-As you can see, a lot of information is needed for every instruction supported
-by the code generator, and specifying it all manually would be unmaintainable,
-prone to bugs, and tiring to do in the first place.  Because we are using
-TableGen, all of the information was derived from the following definition:
-
-.. code-block:: llvm
-
-  let Defs = [EFLAGS],
-      isCommutable = 1,                  // X = ADD Y,Z --> X = ADD Z,Y
-      isConvertibleToThreeAddress = 1 in // Can transform into LEA.
-  def ADD32rr  : I<0x01, MRMDestReg, (outs GR32:$dst),
-                                     (ins GR32:$src1, GR32:$src2),
-                   "add{l}\t{$src2, $dst|$dst, $src2}",
-                   [(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
-
-This definition makes use of the custom class ``I`` (extended from the custom
-class ``X86Inst``), which is defined in the X86-specific TableGen file, to
-factor out the common features that instructions of its class share.  A key
-feature of TableGen is that it allows the end-user to define the abstractions
-they prefer to use when describing their information.
-
-Each ``def`` record has a special entry called "NAME".  This is the name of the
-record ("``ADD32rr``" above).  In the general case ``def`` names can be formed
-from various kinds of string processing expressions and ``NAME`` resolves to the
-final value obtained after resolving all of those expressions.  The user may
-refer to ``NAME`` anywhere she desires to use the ultimate name of the ``def``.
-``NAME`` should not be defined anywhere else in user code to avoid conflicts.
-
-Running TableGen
-----------------
-
-TableGen runs just like any other LLVM tool.  The first (optional) argument
-specifies the file to read.  If a filename is not specified, ``llvm-tblgen``
-reads from standard input.
-
-To be useful, one of the `TableGen backends`_ must be used.  These backends are
-selectable on the command line (type '``llvm-tblgen -help``' for a list).  For
-example, to get a list of all of the definitions that subclass a particular type
-(which can be useful for building up an enum list of these records), use the
-``-print-enums`` option:
-
-.. code-block:: bash
-
-  $ llvm-tblgen X86.td -print-enums -class=Register
-  AH, AL, AX, BH, BL, BP, BPL, BX, CH, CL, CX, DH, DI, DIL, DL, DX, EAX, EBP, EBX,
-  ECX, EDI, EDX, EFLAGS, EIP, ESI, ESP, FP0, FP1, FP2, FP3, FP4, FP5, FP6, IP,
-  MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, R10, R10B, R10D, R10W, R11, R11B, R11D,
-  R11W, R12, R12B, R12D, R12W, R13, R13B, R13D, R13W, R14, R14B, R14D, R14W, R15,
-  R15B, R15D, R15W, R8, R8B, R8D, R8W, R9, R9B, R9D, R9W, RAX, RBP, RBX, RCX, RDI,
-  RDX, RIP, RSI, RSP, SI, SIL, SP, SPL, ST0, ST1, ST2, ST3, ST4, ST5, ST6, ST7,
-  XMM0, XMM1, XMM10, XMM11, XMM12, XMM13, XMM14, XMM15, XMM2, XMM3, XMM4, XMM5,
-  XMM6, XMM7, XMM8, XMM9,
-
-  $ llvm-tblgen X86.td -print-enums -class=Instruction 
-  ABS_F, ABS_Fp32, ABS_Fp64, ABS_Fp80, ADC32mi, ADC32mi8, ADC32mr, ADC32ri,
-  ADC32ri8, ADC32rm, ADC32rr, ADC64mi32, ADC64mi8, ADC64mr, ADC64ri32, ADC64ri8,
-  ADC64rm, ADC64rr, ADD16mi, ADD16mi8, ADD16mr, ADD16ri, ADD16ri8, ADD16rm,
-  ADD16rr, ADD32mi, ADD32mi8, ADD32mr, ADD32ri, ADD32ri8, ADD32rm, ADD32rr,
-  ADD64mi32, ADD64mi8, ADD64mr, ADD64ri32, ...
-
-The default backend prints out all of the records, as `described above`_.
-
-If you plan to use TableGen, you will most likely have to `write a backend`_
-that extracts the information specific to what you need and formats it in the
-appropriate way.
-
-.. _parses a file:
-
-TableGen syntax
-===============
-
-TableGen doesn't care about the meaning of data (that is up to the backend to
-define), but it does care about syntax, and it enforces a simple type system.
-This section describes the syntax and the constructs allowed in a TableGen file.
-
-TableGen primitives
--------------------
-
-TableGen comments
-^^^^^^^^^^^^^^^^^
-
-TableGen supports BCPL style "``//``" comments, which run to the end of the
-line, and it also supports **nestable** "``/* */``" comments.
-
-.. _TableGen type:
-
-The TableGen type system
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-TableGen files are strongly typed, in a simple (but complete) type-system.
-These types are used to perform automatic conversions, check for errors, and to
-help interface designers constrain the input that they allow.  Every `value
-definition`_ is required to have an associated type.
-
-TableGen supports a mixture of very low-level types (such as ``bit``) and very
-high-level types (such as ``dag``).  This flexibility is what allows it to
-describe a wide range of information conveniently and compactly.  The TableGen
-types are:
-
-``bit``
-    A 'bit' is a boolean value that can hold either 0 or 1.
-
-``int``
-    The 'int' type represents a simple 32-bit integer value, such as 5.
-
-``string``
-    The 'string' type represents an ordered sequence of characters of arbitrary
-    length.
-
-``bits<n>``
-    A 'bits' type is an arbitrary, but fixed, size integer that is broken up
-    into individual bits.  This type is useful because it can handle some bits
-    being defined while others are undefined.
-
-``list<ty>``
-    This type represents a list whose elements are some other type.  The
-    contained type is arbitrary: it can even be another list type.
-
-Class type
-    Specifying a class name in a type context means that the defined value must
-    be a subclass of the specified class.  This is useful in conjunction with
-    the ``list`` type, for example, to constrain the elements of the list to a
-    common base class (e.g., a ``list<Register>`` can only contain definitions
-    derived from the "``Register``" class).
-
-``dag``
-    This type represents a nestable directed graph of elements.
-
-``code``
-    This represents a big hunk of text.  This is lexically distinct from string
-    values because it doesn't require escaping double quotes and other common
-    characters that occur in code.
-
-To date, these types have been sufficient for describing things that TableGen
-has been used for, but it is straight-forward to extend this list if needed.
-
-.. _TableGen expressions:
-
-TableGen values and expressions
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-TableGen allows for a pretty reasonable number of different expression forms
-when building up values.  These forms allow the TableGen file to be written in a
-natural syntax and flavor for the application.  The current expression forms
-supported include:
-
-``?``
-    uninitialized field
-
-``0b1001011``
-    binary integer value
-
-``07654321``
-    octal integer value (indicated by a leading 0)
-
-``7``
-    decimal integer value
-
-``0x7F``
-    hexadecimal integer value
-
-``"foo"``
-    string value
-
-``[{ ... }]``
-    code fragment
-
-``[ X, Y, Z ]<type>``
-    list value.  <type> is the type of the list element and is usually optional.
-    In rare cases, TableGen is unable to deduce the element type in which case
-    the user must specify it explicitly.
-
-``{ a, b, c }``
-    initializer for a "bits<3>" value
-
-``value``
-    value reference
-
-``value{17}``
-    access to one bit of a value
-
-``value{15-17}``
-    access to multiple bits of a value
-
-``DEF``
-    reference to a record definition
-
-``CLASS<val list>``
-    reference to a new anonymous definition of CLASS with the specified template
-    arguments.
-
-``X.Y``
-    reference to the subfield of a value
-
-``list[4-7,17,2-3]``
-    A slice of the 'list' list, including elements 4,5,6,7,17,2, and 3 from it.
-    Elements may be included multiple times.
-
-``foreach <var> = [ <list> ] in { <body> }``
-
-``foreach <var> = [ <list> ] in <def>``
-    Replicate <body> or <def>, replacing instances of <var> with each value
-    in <list>.  <var> is scoped at the level of the ``foreach`` loop and must
-    not conflict with any other object introduced in <body> or <def>.  Currently
-    only ``def``\s are expanded within <body>.
-
-``foreach <var> = 0-15 in ...``
-
-``foreach <var> = {0-15,32-47} in ...``
-    Loop over ranges of integers. The braces are required for multiple ranges.
-
-``(DEF a, b)``
-    a dag value.  The first element is required to be a record definition, the
-    remaining elements in the list may be arbitrary other values, including
-    nested ```dag``' values.
-
-``!strconcat(a, b)``
-    A string value that is the result of concatenating the 'a' and 'b' strings.
-
-``str1#str2``
-    "#" (paste) is a shorthand for !strconcat.  It may concatenate things that
-    are not quoted strings, in which case an implicit !cast<string> is done on
-    the operand of the paste.
-
-``!cast<type>(a)``
-    A symbol of type *type* obtained by looking up the string 'a' in the symbol
-    table.  If the type of 'a' does not match *type*, TableGen aborts with an
-    error. !cast<string> is a special case in that the argument must be an
-    object defined by a 'def' construct.
-
-``!subst(a, b, c)``
-    If 'a' and 'b' are of string type or are symbol references, substitute 'b'
-    for 'a' in 'c.'  This operation is analogous to $(subst) in GNU make.
-
-``!foreach(a, b, c)``
-    For each member 'b' of dag or list 'a' apply operator 'c.'  'b' is a dummy
-    variable that should be declared as a member variable of an instantiated
-    class.  This operation is analogous to $(foreach) in GNU make.
-
-``!head(a)``
-    The first element of list 'a.'
-
-``!tail(a)``
-    The 2nd-N elements of list 'a.'
-
-``!empty(a)``
-    An integer {0,1} indicating whether list 'a' is empty.
-
-``!if(a,b,c)``
-  'b' if the result of 'int' or 'bit' operator 'a' is nonzero, 'c' otherwise.
-
-``!eq(a,b)``
-    'bit 1' if string a is equal to string b, 0 otherwise.  This only operates
-    on string, int and bit objects.  Use !cast<string> to compare other types of
-    objects.
-
-Note that all of the values have rules specifying how they convert to values
-for different types.  These rules allow you to assign a value like "``7``"
-to a "``bits<4>``" value, for example.
-
-Classes and definitions
------------------------
-
-As mentioned in the `intro`_, classes and definitions (collectively known as
-'records') in TableGen are the main high-level unit of information that TableGen
-collects.  Records are defined with a ``def`` or ``class`` keyword, the record
-name, and an optional list of "`template arguments`_".  If the record has
-superclasses, they are specified as a comma separated list that starts with a
-colon character ("``:``").  If `value definitions`_ or `let expressions`_ are
-needed for the class, they are enclosed in curly braces ("``{}``"); otherwise,
-the record ends with a semicolon.
-
-Here is a simple TableGen file:
-
-.. code-block:: llvm
-
-  class C { bit V = 1; }
-  def X : C;
-  def Y : C {
-    string Greeting = "hello";
-  }
-
-This example defines two definitions, ``X`` and ``Y``, both of which derive from
-the ``C`` class.  Because of this, they both get the ``V`` bit value.  The ``Y``
-definition also gets the Greeting member as well.
-
-In general, classes are useful for collecting together the commonality between a
-group of records and isolating it in a single place.  Also, classes permit the
-specification of default values for their subclasses, allowing the subclasses to
-override them as they wish.
-
-.. _value definition:
-.. _value definitions:
-
-Value definitions
-^^^^^^^^^^^^^^^^^
-
-Value definitions define named entries in records.  A value must be defined
-before it can be referred to as the operand for another value definition or
-before the value is reset with a `let expression`_.  A value is defined by
-specifying a `TableGen type`_ and a name.  If an initial value is available, it
-may be specified after the type with an equal sign.  Value definitions require
-terminating semicolons.
-
-.. _let expression:
-.. _let expressions:
-.. _"let" expressions within a record:
-
-'let' expressions
-^^^^^^^^^^^^^^^^^
-
-A record-level let expression is used to change the value of a value definition
-in a record.  This is primarily useful when a superclass defines a value that a
-derived class or definition wants to override.  Let expressions consist of the
-'``let``' keyword followed by a value name, an equal sign ("``=``"), and a new
-value.  For example, a new class could be added to the example above, redefining
-the ``V`` field for all of its subclasses:
-
-.. code-block:: llvm
-
-  class D : C { let V = 0; }
-  def Z : D;
-
-In this case, the ``Z`` definition will have a zero value for its ``V`` value,
-despite the fact that it derives (indirectly) from the ``C`` class, because the
-``D`` class overrode its value.
-
-.. _template arguments:
-
-Class template arguments
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-TableGen permits the definition of parameterized classes as well as normal
-concrete classes.  Parameterized TableGen classes specify a list of variable
-bindings (which may optionally have defaults) that are bound when used.  Here is
-a simple example:
-
-.. code-block:: llvm
-
-  class FPFormat<bits<3> val> {
-    bits<3> Value = val;
-  }
-  def NotFP      : FPFormat<0>;
-  def ZeroArgFP  : FPFormat<1>;
-  def OneArgFP   : FPFormat<2>;
-  def OneArgFPRW : FPFormat<3>;
-  def TwoArgFP   : FPFormat<4>;
-  def CompareFP  : FPFormat<5>;
-  def CondMovFP  : FPFormat<6>;
-  def SpecialFP  : FPFormat<7>;
-
-In this case, template arguments are used as a space efficient way to specify a
-list of "enumeration values", each with a "``Value``" field set to the specified
-integer.
-
-The more esoteric forms of `TableGen expressions`_ are useful in conjunction
-with template arguments.  As an example:
-
-.. code-block:: llvm
-
-  class ModRefVal<bits<2> val> {
-    bits<2> Value = val;
-  }
-
-  def None   : ModRefVal<0>;
-  def Mod    : ModRefVal<1>;
-  def Ref    : ModRefVal<2>;
-  def ModRef : ModRefVal<3>;
-
-  class Value<ModRefVal MR> {
-    // Decode some information into a more convenient format, while providing
-    // a nice interface to the user of the "Value" class.
-    bit isMod = MR.Value{0};
-    bit isRef = MR.Value{1};
-
-    // other stuff...
-  }
-
-  // Example uses
-  def bork : Value<Mod>;
-  def zork : Value<Ref>;
-  def hork : Value<ModRef>;
-
-This is obviously a contrived example, but it shows how template arguments can
-be used to decouple the interface provided to the user of the class from the
-actual internal data representation expected by the class.  In this case,
-running ``llvm-tblgen`` on the example prints the following definitions:
-
-.. code-block:: llvm
-
-  def bork {      // Value
-    bit isMod = 1;
-    bit isRef = 0;
-  }
-  def hork {      // Value
-    bit isMod = 1;
-    bit isRef = 1;
-  }
-  def zork {      // Value
-    bit isMod = 0;
-    bit isRef = 1;
-  }
-
-This shows that TableGen was able to dig into the argument and extract a piece
-of information that was requested by the designer of the "Value" class.  For
-more realistic examples, please see existing users of TableGen, such as the X86
-backend.
-
-Multiclass definitions and instances
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-While classes with template arguments are a good way to factor commonality
-between two instances of a definition, multiclasses allow a convenient notation
-for defining multiple definitions at once (instances of implicitly constructed
-classes).  For example, consider an 3-address instruction set whose instructions
-come in two forms: "``reg = reg op reg``" and "``reg = reg op imm``"
-(e.g. SPARC). In this case, you'd like to specify in one place that this
-commonality exists, then in a separate place indicate what all the ops are.
-
-Here is an example TableGen fragment that shows this idea:
-
-.. code-block:: llvm
-
-  def ops;
-  def GPR;
-  def Imm;
-  class inst<int opc, string asmstr, dag operandlist>;
-
-  multiclass ri_inst<int opc, string asmstr> {
-    def _rr : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
-                   (ops GPR:$dst, GPR:$src1, GPR:$src2)>;
-    def _ri : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
-                   (ops GPR:$dst, GPR:$src1, Imm:$src2)>;
-  }
-
-  // Instantiations of the ri_inst multiclass.
-  defm ADD : ri_inst<0b111, "add">;
-  defm SUB : ri_inst<0b101, "sub">;
-  defm MUL : ri_inst<0b100, "mul">;
-  ...
-
-The name of the resultant definitions has the multidef fragment names appended
-to them, so this defines ``ADD_rr``, ``ADD_ri``, ``SUB_rr``, etc.  A defm may
-inherit from multiple multiclasses, instantiating definitions from each
-multiclass.  Using a multiclass this way is exactly equivalent to instantiating
-the classes multiple times yourself, e.g. by writing:
-
-.. code-block:: llvm
-
-  def ops;
-  def GPR;
-  def Imm;
-  class inst<int opc, string asmstr, dag operandlist>;
-
-  class rrinst<int opc, string asmstr>
-    : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
-           (ops GPR:$dst, GPR:$src1, GPR:$src2)>;
-
-  class riinst<int opc, string asmstr>
-    : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
-           (ops GPR:$dst, GPR:$src1, Imm:$src2)>;
-
-  // Instantiations of the ri_inst multiclass.
-  def ADD_rr : rrinst<0b111, "add">;
-  def ADD_ri : riinst<0b111, "add">;
-  def SUB_rr : rrinst<0b101, "sub">;
-  def SUB_ri : riinst<0b101, "sub">;
-  def MUL_rr : rrinst<0b100, "mul">;
-  def MUL_ri : riinst<0b100, "mul">;
-  ...
-
-A ``defm`` can also be used inside a multiclass providing several levels of
-multiclass instanciations.
-
-.. code-block:: llvm
-
-  class Instruction<bits<4> opc, string Name> {
-    bits<4> opcode = opc;
-    string name = Name;
-  }
-
-  multiclass basic_r<bits<4> opc> {
-    def rr : Instruction<opc, "rr">;
-    def rm : Instruction<opc, "rm">;
-  }
-
-  multiclass basic_s<bits<4> opc> {
-    defm SS : basic_r<opc>;
-    defm SD : basic_r<opc>;
-    def X : Instruction<opc, "x">;
-  }
-
-  multiclass basic_p<bits<4> opc> {
-    defm PS : basic_r<opc>;
-    defm PD : basic_r<opc>;
-    def Y : Instruction<opc, "y">;
-  }
-
-  defm ADD : basic_s<0xf>, basic_p<0xf>;
-  ...
-
-  // Results
-  def ADDPDrm { ...
-  def ADDPDrr { ...
-  def ADDPSrm { ...
-  def ADDPSrr { ...
-  def ADDSDrm { ...
-  def ADDSDrr { ...
-  def ADDY { ...
-  def ADDX { ...
-
-``defm`` declarations can inherit from classes too, the rule to follow is that
-the class list must start after the last multiclass, and there must be at least
-one multiclass before them.
-
-.. code-block:: llvm
-
-  class XD { bits<4> Prefix = 11; }
-  class XS { bits<4> Prefix = 12; }
-
-  class I<bits<4> op> {
-    bits<4> opcode = op;
-  }
-
-  multiclass R {
-    def rr : I<4>;
-    def rm : I<2>;
-  }
-
-  multiclass Y {
-    defm SS : R, XD;
-    defm SD : R, XS;
-  }
-
-  defm Instr : Y;
-
-  // Results
-  def InstrSDrm {
-    bits<4> opcode = { 0, 0, 1, 0 };
-    bits<4> Prefix = { 1, 1, 0, 0 };
-  }
-  ...
-  def InstrSSrr {
-    bits<4> opcode = { 0, 1, 0, 0 };
-    bits<4> Prefix = { 1, 0, 1, 1 };
-  }
-
-File scope entities
--------------------
-
-File inclusion
-^^^^^^^^^^^^^^
-
-TableGen supports the '``include``' token, which textually substitutes the
-specified file in place of the include directive.  The filename should be
-specified as a double quoted string immediately after the '``include``' keyword.
-Example:
-
-.. code-block:: llvm
-
-  include "foo.td"
-
-'let' expressions
-^^^^^^^^^^^^^^^^^
-
-"Let" expressions at file scope are similar to `"let" expressions within a
-record`_, except they can specify a value binding for multiple records at a
-time, and may be useful in certain other cases.  File-scope let expressions are
-really just another way that TableGen allows the end-user to factor out
-commonality from the records.
-
-File-scope "let" expressions take a comma-separated list of bindings to apply,
-and one or more records to bind the values in.  Here are some examples:
-
-.. code-block:: llvm
-
-  let isTerminator = 1, isReturn = 1, isBarrier = 1, hasCtrlDep = 1 in
-    def RET : I<0xC3, RawFrm, (outs), (ins), "ret", [(X86retflag 0)]>;
-
-  let isCall = 1 in
-    // All calls clobber the non-callee saved registers...
-    let Defs = [EAX, ECX, EDX, FP0, FP1, FP2, FP3, FP4, FP5, FP6, ST0,
-                MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7,
-                XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, EFLAGS] in {
-      def CALLpcrel32 : Ii32<0xE8, RawFrm, (outs), (ins i32imm:$dst,variable_ops),
-                             "call\t${dst:call}", []>;
-      def CALL32r     : I<0xFF, MRM2r, (outs), (ins GR32:$dst, variable_ops),
-                          "call\t{*}$dst", [(X86call GR32:$dst)]>;
-      def CALL32m     : I<0xFF, MRM2m, (outs), (ins i32mem:$dst, variable_ops),
-                          "call\t{*}$dst", []>;
-    }
-
-File-scope "let" expressions are often useful when a couple of definitions need
-to be added to several records, and the records do not otherwise need to be
-opened, as in the case with the ``CALL*`` instructions above.
-
-It's also possible to use "let" expressions inside multiclasses, providing more
-ways to factor out commonality from the records, specially if using several
-levels of multiclass instanciations. This also avoids the need of using "let"
-expressions within subsequent records inside a multiclass.
-
-.. code-block:: llvm
-
-  multiclass basic_r<bits<4> opc> {
-    let Predicates = [HasSSE2] in {
-      def rr : Instruction<opc, "rr">;
-      def rm : Instruction<opc, "rm">;
-    }
-    let Predicates = [HasSSE3] in
-      def rx : Instruction<opc, "rx">;
-  }
-
-  multiclass basic_ss<bits<4> opc> {
-    let IsDouble = 0 in
-      defm SS : basic_r<opc>;
-
-    let IsDouble = 1 in
-      defm SD : basic_r<opc>;
-  }
-
-  defm ADD : basic_ss<0xf>;
-
-Looping
-^^^^^^^
-
-TableGen supports the '``foreach``' block, which textually replicates the loop
-body, substituting iterator values for iterator references in the body.
-Example:
-
-.. code-block:: llvm
-
-  foreach i = [0, 1, 2, 3] in {
-    def R#i : Register<...>;
-    def F#i : Register<...>;
-  }
-
-This will create objects ``R0``, ``R1``, ``R2`` and ``R3``.  ``foreach`` blocks
-may be nested. If there is only one item in the body the braces may be
-elided:
-
-.. code-block:: llvm
-
-  foreach i = [0, 1, 2, 3] in
-    def R#i : Register<...>;
-
-Code Generator backend info
-===========================
-
-Expressions used by code generator to describe instructions and isel patterns:
-
-``(implicit a)``
-    an implicitly defined physical register.  This tells the dag instruction
-    selection emitter the input pattern's extra definitions matches implicit
-    physical register definitions.
-
-.. _TableGen backend:
-.. _TableGen backends:
-.. _write a backend:
-
-TableGen backends
-=================
-
-Until we get a step-by-step HowTo for writing TableGen backends, you can at
-least grab the boilerplate (build system, new files, etc.) from Clang's
-r173931.
-
-TODO: How they work, how to write one.  This section should not contain details
-about any particular backend, except maybe ``-print-enums`` as an example.  This
-should highlight the APIs in ``TableGen/Record.h``.
+The TableGen fundamentals documentation has moved to a directory on its own
+and is now available at :doc:`TableGen/index`. Please, change your links to
+that page.
diff --git a/docs/TestingGuide.rst b/docs/TestingGuide.rst
index c9a35cd..f9222372 100644
--- a/docs/TestingGuide.rst
+++ b/docs/TestingGuide.rst
@@ -337,87 +337,100 @@ triple, test with the specific FileCheck and put it into the specific
 directory that will filter out all other architectures.
 
 
-Variables and substitutions
----------------------------
+Substitutions
+-------------
 
-With a RUN line there are a number of substitutions that are permitted.
-To make a substitution just write the variable's name preceded by a ``$``.
-Additionally, for compatibility reasons with previous versions of the
-test library, certain names can be accessed with an alternate syntax: a
-% prefix. These alternates are deprecated and may go away in a future
-version.
+Besides replacing LLVM tool names the following substitutions are performed in
+RUN lines:
 
-Here are the available variable names. The alternate syntax is listed in
-parentheses.
+``%%``
+   Replaced by a single ``%``. This allows escaping other substitutions.
 
-``$test`` (``%s``)
-   The full path to the test case's source. This is suitable for passing on
-   the command line as the input to an LLVM tool.
+``%s``
+   File path to the test case's source. This is suitable for passing on the
+   command line as the input to an LLVM tool.
 
-``%(line)``, ``%(line+<number>)``, ``%(line-<number>)``
-   The number of the line where this variable is used, with an optional
-   integer offset. This can be used in tests with multiple RUN lines,
-   which reference test file's line numbers.
+   Example: ``/home/user/llvm/test/MC/ELF/foo_test.s``
 
-``$srcdir``
-   The source directory from where the ``make check`` was run.
+``%S``
+   Directory path to the test case's source.
 
-``objdir``
-   The object directory that corresponds to the ``$srcdir``.
+   Example: ``/home/user/llvm/test/MC/ELF``
 
-``subdir``
-   A partial path from the ``test`` directory that contains the
-   sub-directory that contains the test source being executed.
+``%t``
+   File path to a temporary file name that could be used for this test case.
+   The file name won't conflict with other test cases. You can append to it
+   if you need multiple temporaries. This is useful as the destination of
+   some redirected output.
 
-``srcroot``
-   The root directory of the LLVM src tree.
+   Example: ``/home/user/llvm.build/test/MC/ELF/Output/foo_test.s.tmp``
 
-``objroot``
-   The root directory of the LLVM object tree. This could be the same as
-   the srcroot.
+``%T``
+   Directory of ``%t``.
 
-``path``
-   The path to the directory that contains the test case source. This is
-   for locating any supporting files that are not generated by the test,
-   but used by the test.
+   Example: ``/home/user/llvm.build/test/MC/ELF/Output``
 
-``tmp``
-   The path to a temporary file name that could be used for this test case.
-   The file name won't conflict with other test cases. You can append to it
-   if you need multiple temporaries. This is useful as the destination of
-   some redirected output.
+``%{pathsep}``
+
+   Expands to the path separator, i.e. ``:`` (or ``;`` on Windows).
 
-``target_triplet`` (``%target_triplet``)
-   The target triplet that corresponds to the current host machine (the one
-   running the test cases). This should probably be called "host".
 
-``link`` (``%link``)
-   This full link command used to link LLVM executables. This has all the
-   configured ``-I``, ``-L`` and ``-l`` options.
+**LLVM-specific substitutions:**
 
-``shlibext`` (``%shlibext``)
-   The suffix for the host platforms shared library (DLL) files. This
-   includes the period as the first character.
+``%shlibext``
+   The suffix for the host platforms shared library files. This includes the
+   period as the first character.
+
+   Example: ``.so`` (Linux), ``.dylib`` (OS X), ``.dll`` (Windows)
+
+``%exeext``
+   The suffix for the host platforms executable files. This includes the
+   period as the first character.
+
+   Example: ``.exe`` (Windows), empty on Linux.
+
+``%(line)``, ``%(line+<number>)``, ``%(line-<number>)``
+   The number of the line where this substitution is used, with an optional
+   integer offset. This can be used in tests with multiple RUN lines, which
+   reference test file's line numbers.
+
+
+**Clang-specific substitutions:**
+
+``%clang``
+   Invokes the Clang driver.
+
+``%clang_cpp``
+   Invokes the Clang driver for C++.
+
+``%clang_cl``
+   Invokes the CL-compatible Clang driver.
+
+``%clangxx``
+   Invokes the G++-compatible Clang driver.
+
+``%clang_cc1``
+   Invokes the Clang frontend.
+
+``%itanium_abi_triple``, ``%ms_abi_triple``
+   These substitutions can be used to get the current target triple adjusted to
+   the desired ABI. For example, if the test suite is running with the
+   ``i686-pc-win32`` target, ``%itanium_abi_triple`` will expand to
+   ``i686-pc-mingw32``. This allows a test to run with a specific ABI without
+   constraining it to a specific triple.
+
+To add more substituations, look at ``test/lit.cfg`` or ``lit.local.cfg``.
 
-To add more variables, look at ``test/lit.cfg``.
 
 Other Features
 --------------
 
-To make RUN line writing easier, there are several helper scripts and programs
-in the ``llvm/test/Scripts`` directory. This directory is in the PATH
-when running tests, so you can just call these scripts using their name.
-For example:
-
-``ignore``
-   This script runs its arguments and then always returns 0. This is useful
-   in cases where the test needs to cause a tool to generate an error (e.g.
-   to check the error output). However, any program in a pipeline that
-   returns a non-zero result will cause the test to fail.  This script
-   overcomes that issue and nicely documents that the test case is
-   purposefully ignoring the result code of the tool
+To make RUN line writing easier, there are several helper programs. These
+helpers are in the PATH when running tests, so you can just call them using
+their name. For example:
+
 ``not``
-   This script runs its arguments and then inverts the result code from it.
+   This program runs its arguments and then inverts the result code from it.
    Zero result codes become 1. Non-zero result codes become 0.
 
 Sometimes it is necessary to mark a test case as "expected fail" or
diff --git a/docs/Vectorizers.rst b/docs/Vectorizers.rst
index 61ebca2..887ccaa 100644
--- a/docs/Vectorizers.rst
+++ b/docs/Vectorizers.rst
@@ -182,11 +182,14 @@ that scatter/gathers memory.
 
 .. code-block:: c++
 
-  int foo(int *A, int *B, int n, int k) {
-    for (int i = 0; i < n; ++i)
-      A[i*7] += B[i*k];
+  int foo(int * A, int * B, int n) {
+    for (intptr_t i = 0; i < n; ++i)
+        A[i] += B[i * 4];
   }
 
+In many situations the cost model will inform LLVM that this is not beneficial
+and LLVM will only vectorize such code if forced with "-mllvm -force-vector-width=#".
+
 Vectorization of Mixed Types
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
diff --git a/docs/WritingAnLLVMBackend.rst b/docs/WritingAnLLVMBackend.rst
index 35a2d16..429f52a 100644
--- a/docs/WritingAnLLVMBackend.rst
+++ b/docs/WritingAnLLVMBackend.rst
@@ -238,6 +238,12 @@ For some targets, you also need to support the following methods:
 * ``getTargetLowering()``
 * ``getJITInfo()``
 
+Some architectures, such as GPUs, do not support jumping to an arbitrary
+program location and implement branching using masked execution and loop using
+special instructions around the loop body. In order to avoid CFG modifications
+that introduce irreducible control flow not handled by such hardware, a target
+must call `setRequiresStructuredCFG(true)` when being initialized.
+
 In addition, the ``XXXTargetMachine`` constructor should specify a
 ``TargetDescription`` string that determines the data layout for the target
 machine, including characteristics such as pointer size, alignment, and
diff --git a/docs/YamlIO.rst b/docs/YamlIO.rst
index 3ecd03a..b1917b6 100644
--- a/docs/YamlIO.rst
+++ b/docs/YamlIO.rst
@@ -234,6 +234,7 @@ The following types have built-in support in YAML I/O:
 * float
 * double
 * StringRef
+* std::string
 * int64_t
 * int32_t
 * int16_t
@@ -640,12 +641,50 @@ The YAML syntax supports tags as a way to specify the type of a node before
 it is parsed. This allows dynamic types of nodes.  But the YAML I/O model uses
 static typing, so there are limits to how you can use tags with the YAML I/O
 model. Recently, we added support to YAML I/O for checking/setting the optional 
-tag on a map. Using this functionality it is even possbile to support differnt 
+tag on a map. Using this functionality it is even possbile to support different 
 mappings, as long as they are convertable.  
 
 To check a tag, inside your mapping() method you can use io.mapTag() to specify
 what the tag should be.  This will also add that tag when writing yaml.
 
+Validation
+----------
+
+Sometimes in a yaml map, each key/value pair is valid, but the combination is
+not.  This is similar to something having no syntax errors, but still having
+semantic errors.  To support semantic level checking, YAML I/O allows
+an optional ``validate()`` method in a MappingTraits template specialization.  
+
+When parsing yaml, the ``validate()`` method is call *after* all key/values in 
+the map have been processed. Any error message returned by the ``validate()`` 
+method during input will be printed just a like a syntax error would be printed.
+When writing yaml, the ``validate()`` method is called *before* the yaml 
+key/values  are written.  Any error during output will trigger an ``assert()`` 
+because it is a programming error to have invalid struct values.
+
+
+.. code-block:: c++
+
+    using llvm::yaml::MappingTraits;
+    using llvm::yaml::IO;
+    
+    struct Stuff {
+      ...
+    };
+
+    template <>
+    struct MappingTraits<Stuff> {
+      static void mapping(IO &io, Stuff &stuff) {
+      ...
+      }
+      static StringRef validate(IO &io, Stuff &stuff) {
+        // Look at all fields in 'stuff' and if there
+        // are any bad values return a string describing
+        // the error.  Otherwise return an empty string.
+        return StringRef();
+      }
+    };
+
 
 Sequence
 ========
diff --git a/docs/conf.py b/docs/conf.py
index d71f46e..17d21f3 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -40,7 +40,7 @@ master_doc = 'index'
 
 # General information about the project.
 project = u'LLVM'
-copyright = u'2003-2013, LLVM Project'
+copyright = u'2003-2014, LLVM Project'
 
 # The version info for the project you're documenting, acts as replacement for
 # |version| and |release|, also used in various other places throughout the
diff --git a/docs/doxygen.cfg.in b/docs/doxygen.cfg.in
index 0ed686b..8c16b66 100644
--- a/docs/doxygen.cfg.in
+++ b/docs/doxygen.cfg.in
@@ -280,10 +280,10 @@ TYPEDEF_HIDES_STRUCT   = NO
 # For small to medium size projects (<1000 input files) the default value is
 # probably good enough. For larger projects a too small cache size can cause
 # doxygen to be busy swapping symbols to and from disk most of the time
-# causing a significant performance penality.
+# causing a significant performance penalty.
 # If the system has enough physical memory increasing the cache will improve the
 # performance by keeping more symbols in memory. Note that the value works on
-# a logarithmic scale so increasing the size by one will rougly double the
+# a logarithmic scale so increasing the size by one will roughly double the
 # memory usage. The cache size is given by this formula:
 # 2^(16+SYMBOL_CACHE_SIZE). The valid range is 0..9, the default is 0,
 # corresponding to a cache size of 2^16 = 65536 symbols
@@ -938,58 +938,58 @@ BINARY_TOC             = NO
 
 TOC_EXPAND             = NO
 
-# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and
-# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated
-# that can be used as input for Qt's qhelpgenerator to generate a
+# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and 
+# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated 
+# that can be used as input for Qt's qhelpgenerator to generate a 
 # Qt Compressed Help (.qch) of the generated HTML documentation.
 
-GENERATE_QHP           = NO
+GENERATE_QHP           = @llvm_doxygen_generate_qhp@
 
-# If the QHG_LOCATION tag is specified, the QCH_FILE tag can
-# be used to specify the file name of the resulting .qch file.
+# If the QHG_LOCATION tag is specified, the QCH_FILE tag can 
+# be used to specify the file name of the resulting .qch file. 
 # The path specified is relative to the HTML output folder.
 
-QCH_FILE               =
+QCH_FILE               = @llvm_doxygen_qch_filename@
 
-# The QHP_NAMESPACE tag specifies the namespace to use when generating
-# Qt Help Project output. For more information please see
-# http://doc.trolltech.com/qthelpproject.html#namespace
+# The QHP_NAMESPACE tag specifies the namespace to use when generating 
+# Qt Help Project output. For more information please see 
+# http://qt-project.org/doc/qt-4.8/qthelpproject.html#namespace
 
-QHP_NAMESPACE          = org.doxygen.Project
+QHP_NAMESPACE          = @llvm_doxygen_qhp_namespace@
 
-# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating
-# Qt Help Project output. For more information please see
-# http://doc.trolltech.com/qthelpproject.html#virtual-folders
+# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating 
+# Qt Help Project output. For more information please see 
+# http://qt-project.org/doc/qt-4.8/qthelpproject.html#virtual-folders
 
 QHP_VIRTUAL_FOLDER     = doc
 
-# If QHP_CUST_FILTER_NAME is set, it specifies the name of a custom filter to
-# add. For more information please see
-# http://doc.trolltech.com/qthelpproject.html#custom-filters
+# If QHP_CUST_FILTER_NAME is set, it specifies the name of a custom filter to 
+# add. For more information please see 
+# http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-filters
 
-QHP_CUST_FILTER_NAME   =
+QHP_CUST_FILTER_NAME   = @llvm_doxygen_qhp_cust_filter_name@
 
-# The QHP_CUST_FILT_ATTRS tag specifies the list of the attributes of the
-# custom filter to add. For more information please see
-# <a href="http://doc.trolltech.com/qthelpproject.html#custom-filters">
+# The QHP_CUST_FILT_ATTRS tag specifies the list of the attributes of the 
+# custom filter to add. For more information please see 
+# <a href="http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-filters"> 
 # Qt Help Project / Custom Filters</a>.
 
-QHP_CUST_FILTER_ATTRS  =
+QHP_CUST_FILTER_ATTRS  = @llvm_doxygen_qhp_cust_filter_attrs@
 
-# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this
-# project's
-# filter section matches.
-# <a href="http://doc.trolltech.com/qthelpproject.html#filter-attributes">
+# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this 
+# project's 
+# filter section matches. 
+# <a href="http://qt-project.org/doc/qt-4.8/qthelpproject.html#filter-attributes"> 
 # Qt Help Project / Filter Attributes</a>.
 
-QHP_SECT_FILTER_ATTRS  =
+QHP_SECT_FILTER_ATTRS  = 
 
-# If the GENERATE_QHP tag is set to YES, the QHG_LOCATION tag can
-# be used to specify the location of Qt's qhelpgenerator.
-# If non-empty doxygen will try to run qhelpgenerator on the generated
+# If the GENERATE_QHP tag is set to YES, the QHG_LOCATION tag can 
+# be used to specify the location of Qt's qhelpgenerator. 
+# If non-empty doxygen will try to run qhelpgenerator on the generated 
 # .qhp file.
 
-QHG_LOCATION           =
+QHG_LOCATION           = @llvm_doxygen_qhelpgenerator_path@
 
 # If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files
 #  will be generated, which together with the HTML files, form an Eclipse help
diff --git a/docs/doxygen.footer b/docs/doxygen.footer
index 95d5434..6f8bc9e 100644
--- a/docs/doxygen.footer
+++ b/docs/doxygen.footer
@@ -3,7 +3,7 @@
 Generated on $datetime for <a href="http://llvm.org/">$projectname</a> by
 <a href="http://www.doxygen.org"><img src="doxygen.png" alt="Doxygen"
 align="middle" border="0"/>$doxygenversion</a><br>
-Copyright &copy; 2003-2013 University of Illinois at Urbana-Champaign.
+Copyright &copy; 2003-2014 University of Illinois at Urbana-Champaign.
 All Rights Reserved.</p>
 
 <hr>
diff --git a/docs/index.rst b/docs/index.rst
index 62766f1..726a392 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -222,6 +222,7 @@ For API clients and LLVM developers.
    LinkTimeOptimization
    SegmentedStacks
    TableGenFundamentals
+   TableGen/index
    DebuggingJITedCode
    GoldPlugin
    MarkedUpDisassembly
@@ -231,9 +232,10 @@ For API clients and LLVM developers.
    WritingAnLLVMBackend
    GarbageCollection
    WritingAnLLVMPass
-   TableGen/LangRef
    HowToUseAttributes
    NVPTXUsage
+   StackMaps
+   InAlloca
 
 :doc:`WritingAnLLVMPass`
    Information on how to write LLVM transformations and analyses.
@@ -246,7 +248,7 @@ For API clients and LLVM developers.
    working on retargetting LLVM to a new architecture, designing a new codegen
    pass, or enhancing existing components.
 
-:doc:`TableGenFundamentals`
+:doc:`TableGen Fundamentals <TableGen/index>`
    Describes the TableGen tool, which is used heavily by the LLVM code
    generator.
 
@@ -308,6 +310,9 @@ For API clients and LLVM developers.
 :doc:`NVPTXUsage`
    This document describes using the NVPTX back-end to compile GPU kernels.
 
+:doc:`StackMaps`
+  LLVM support for mapping instruction addresses to the location of
+  values and allowing code to be patched.
 
 Development Process Documentation
 =================================
diff --git a/docs/tutorial/LangImpl7.rst b/docs/tutorial/LangImpl7.rst
index a2e47b5..849ce50 100644
--- a/docs/tutorial/LangImpl7.rst
+++ b/docs/tutorial/LangImpl7.rst
@@ -237,7 +237,7 @@ strongly recommend that you use this technique for building SSA form,
 unless there is an extremely good reason not to. Using this technique
 is:
 
--  Proven and well tested: llvm-gcc and clang both use this technique
+-  Proven and well tested: clang uses this technique
    for local mutable variables. As such, the most common clients of LLVM
    are using this to handle a bulk of their variables. You can be sure
    that bugs are found fast and fixed early.
diff --git a/docs/tutorial/LangImpl8.rst b/docs/tutorial/LangImpl8.rst
index 3534b2e..6f69493 100644
--- a/docs/tutorial/LangImpl8.rst
+++ b/docs/tutorial/LangImpl8.rst
@@ -72,7 +72,7 @@ For example, try adding:
    info <../SourceLevelDebugging.html>`_ which is understood by common
    debuggers like GDB. Adding support for debug info is fairly
    straightforward. The best way to understand it is to compile some
-   C/C++ code with "``llvm-gcc -g -O0``" and taking a look at what it
+   C/C++ code with "``clang -g -O0``" and taking a look at what it
    produces.
 -  **exception handling support** - LLVM supports generation of `zero
    cost exceptions <../ExceptionHandling.html>`_ which interoperate with
diff --git a/docs/tutorial/OCamlLangImpl7.rst b/docs/tutorial/OCamlLangImpl7.rst
index cfb4931..98ea93f 100644
--- a/docs/tutorial/OCamlLangImpl7.rst
+++ b/docs/tutorial/OCamlLangImpl7.rst
@@ -237,7 +237,7 @@ strongly recommend that you use this technique for building SSA form,
 unless there is an extremely good reason not to. Using this technique
 is:
 
--  Proven and well tested: llvm-gcc and clang both use this technique
+-  Proven and well tested: clang uses this technique
    for local mutable variables. As such, the most common clients of LLVM
    are using this to handle a bulk of their variables. You can be sure
    that bugs are found fast and fixed early.
diff --git a/docs/tutorial/OCamlLangImpl8.rst b/docs/tutorial/OCamlLangImpl8.rst
index 3534b2e..6f69493 100644
--- a/docs/tutorial/OCamlLangImpl8.rst
+++ b/docs/tutorial/OCamlLangImpl8.rst
@@ -72,7 +72,7 @@ For example, try adding:
    info <../SourceLevelDebugging.html>`_ which is understood by common
    debuggers like GDB. Adding support for debug info is fairly
    straightforward. The best way to understand it is to compile some
-   C/C++ code with "``llvm-gcc -g -O0``" and taking a look at what it
+   C/C++ code with "``clang -g -O0``" and taking a look at what it
    produces.
 -  **exception handling support** - LLVM supports generation of `zero
    cost exceptions <../ExceptionHandling.html>`_ which interoperate with
diff --git a/docs/yaml2obj.rst b/docs/yaml2obj.rst
index 2c55f02..1812e58 100644
--- a/docs/yaml2obj.rst
+++ b/docs/yaml2obj.rst
@@ -64,7 +64,7 @@ Here's a simplified Kwalify_ schema with an extension to allow alternate types.
                                  , IMAGE_FILE_MACHINE_AM33
                                  , IMAGE_FILE_MACHINE_AMD64
                                  , IMAGE_FILE_MACHINE_ARM
-                                 , IMAGE_FILE_MACHINE_ARMV7
+                                 , IMAGE_FILE_MACHINE_ARMNT
                                  , IMAGE_FILE_MACHINE_EBC
                                  , IMAGE_FILE_MACHINE_I386
                                  , IMAGE_FILE_MACHINE_IA64