Merge commit '10251753b6897adcd22cc981c0cc42f348c109de' into merge-20130807

Conflicts:
	lib/Archive/ArchiveReader.cpp
	lib/Support/Unix/PathV2.inc

Change-Id: I29d8c1e321a4a380b6013f00bac6a8e4b593cc4e

27 files changed, 404 insertions, 342 deletions

diff --git a/docs/Atomics.rst b/docs/Atomics.rst
index 705d73f..1243f34 100644
--- a/docs/Atomics.rst
+++ b/docs/Atomics.rst
@@ -211,7 +211,7 @@ Notes for code generation
   never stored.  A normal load or store instruction is usually sufficient, but
   note that an unordered load or store cannot be split into multiple
   instructions (or an instruction which does multiple memory operations, like
-  ``LDRD`` on ARM).
+  ``LDRD`` on ARM without LPAE, or not naturally-aligned ``LDRD`` on LPAE ARM).
 
 Monotonic
 ---------
diff --git a/docs/CMake.rst b/docs/CMake.rst
index 8459081..c9fe538 100644
--- a/docs/CMake.rst
+++ b/docs/CMake.rst
@@ -87,7 +87,7 @@ names are case-sensitive. Example:
 
 .. code-block:: console
 
-  $ cmake -G "Visual Studio 9 2008" path/to/llvm/source/root
+  $ cmake -G "Visual Studio 10" path/to/llvm/source/root
 
 For a given development platform there can be more than one adequate
 generator. If you use Visual Studio "NMake Makefiles" is a generator you can use
@@ -275,6 +275,11 @@ LLVM-specific variables
   Build with zlib to support compression/uncompression in LLVM tools.
   Defaults to ON.
 
+**LLVM_USE_SANITIZER**:STRING
+  Define the sanitizer used to build LLVM binaries and tests. Possible values
+  are ``Address``, ``Memory`` and ``MemoryWithOrigins``. Defaults to empty
+  string.
+
 Executing the test suite
 ========================
 
@@ -417,6 +422,5 @@ Microsoft Visual C++
 
 **LLVM_COMPILER_JOBS**:STRING
   Specifies the maximum number of parallell compiler jobs to use per project
-  when building with msbuild or Visual Studio. Only supported for Visual Studio
-  2008 and Visual Studio 2010 CMake generators. 0 means use all
-  processors. Default is 0.
+  when building with msbuild or Visual Studio. Only supported for the Visual
+  Studio 2010 CMake generator. 0 means use all processors. Default is 0.
diff --git a/docs/CodeGenerator.rst b/docs/CodeGenerator.rst
index d54df0f..1f2dc6c 100644
--- a/docs/CodeGenerator.rst
+++ b/docs/CodeGenerator.rst
@@ -1788,7 +1788,6 @@ Here is the table:
 :raw-html:`<th>Feature</th>`
 :raw-html:`<th>ARM</th>`
 :raw-html:`<th>Hexagon</th>`
-:raw-html:`<th>MBlaze</th>`
 :raw-html:`<th>MSP430</th>`
 :raw-html:`<th>Mips</th>`
 :raw-html:`<th>NVPTX</th>`
@@ -1803,7 +1802,6 @@ Here is the table:
 :raw-html:`<td><a href="#feat_reliable">is generally reliable</a></td>`
 :raw-html:`<td class="yes"></td> <!-- ARM -->`
 :raw-html:`<td class="yes"></td> <!-- Hexagon -->`
-:raw-html:`<td class="no"></td> <!-- MBlaze -->`
 :raw-html:`<td class="unknown"></td> <!-- MSP430 -->`
 :raw-html:`<td class="yes"></td> <!-- Mips -->`
 :raw-html:`<td class="yes"></td> <!-- NVPTX -->`
@@ -1818,7 +1816,6 @@ Here is the table:
 :raw-html:`<td><a href="#feat_asmparser">assembly parser</a></td>`
 :raw-html:`<td class="no"></td> <!-- ARM -->`
 :raw-html:`<td class="no"></td> <!-- Hexagon -->`
-:raw-html:`<td class="yes"></td> <!-- MBlaze -->`
 :raw-html:`<td class="no"></td> <!-- MSP430 -->`
 :raw-html:`<td class="no"></td> <!-- Mips -->`
 :raw-html:`<td class="no"></td> <!-- NVPTX -->`
@@ -1833,7 +1830,6 @@ Here is the table:
 :raw-html:`<td><a href="#feat_disassembler">disassembler</a></td>`
 :raw-html:`<td class="yes"></td> <!-- ARM -->`
 :raw-html:`<td class="no"></td> <!-- Hexagon -->`
-:raw-html:`<td class="yes"></td> <!-- MBlaze -->`
 :raw-html:`<td class="no"></td> <!-- MSP430 -->`
 :raw-html:`<td class="no"></td> <!-- Mips -->`
 :raw-html:`<td class="na"></td> <!-- NVPTX -->`
@@ -1848,7 +1844,6 @@ Here is the table:
 :raw-html:`<td><a href="#feat_inlineasm">inline asm</a></td>`
 :raw-html:`<td class="yes"></td> <!-- ARM -->`
 :raw-html:`<td class="yes"></td> <!-- Hexagon -->`
-:raw-html:`<td class="yes"></td> <!-- MBlaze -->`
 :raw-html:`<td class="unknown"></td> <!-- MSP430 -->`
 :raw-html:`<td class="no"></td> <!-- Mips -->`
 :raw-html:`<td class="yes"></td> <!-- NVPTX -->`
@@ -1863,7 +1858,6 @@ Here is the table:
 :raw-html:`<td><a href="#feat_jit">jit</a></td>`
 :raw-html:`<td class="partial"><a href="#feat_jit_arm">*</a></td> <!-- ARM -->`
 :raw-html:`<td class="no"></td> <!-- Hexagon -->`
-:raw-html:`<td class="no"></td> <!-- MBlaze -->`
 :raw-html:`<td class="unknown"></td> <!-- MSP430 -->`
 :raw-html:`<td class="yes"></td> <!-- Mips -->`
 :raw-html:`<td class="na"></td> <!-- NVPTX -->`
@@ -1878,7 +1872,6 @@ Here is the table:
 :raw-html:`<td><a href="#feat_objectwrite">.o&nbsp;file writing</a></td>`
 :raw-html:`<td class="no"></td> <!-- ARM -->`
 :raw-html:`<td class="no"></td> <!-- Hexagon -->`
-:raw-html:`<td class="yes"></td> <!-- MBlaze -->`
 :raw-html:`<td class="no"></td> <!-- MSP430 -->`
 :raw-html:`<td class="no"></td> <!-- Mips -->`
 :raw-html:`<td class="na"></td> <!-- NVPTX -->`
@@ -1893,7 +1886,6 @@ Here is the table:
 :raw-html:`<td><a hr:raw-html:`ef="#feat_tailcall">tail calls</a></td>`
 :raw-html:`<td class="yes"></td> <!-- ARM -->`
 :raw-html:`<td class="yes"></td> <!-- Hexagon -->`
-:raw-html:`<td class="no"></td> <!-- MBlaze -->`
 :raw-html:`<td class="unknown"></td> <!-- MSP430 -->`
 :raw-html:`<td class="no"></td> <!-- Mips -->`
 :raw-html:`<td class="no"></td> <!-- NVPTX -->`
@@ -1908,7 +1900,6 @@ Here is the table:
 :raw-html:`<td><a href="#feat_segstacks">segmented stacks</a></td>`
 :raw-html:`<td class="no"></td> <!-- ARM -->`
 :raw-html:`<td class="no"></td> <!-- Hexagon -->`
-:raw-html:`<td class="no"></td> <!-- MBlaze -->`
 :raw-html:`<td class="no"></td> <!-- MSP430 -->`
 :raw-html:`<td class="no"></td> <!-- Mips -->`
 :raw-html:`<td class="no"></td> <!-- NVPTX -->`
diff --git a/docs/CodingStandards.rst b/docs/CodingStandards.rst
index 4d66ad7..9418680 100644
--- a/docs/CodingStandards.rst
+++ b/docs/CodingStandards.rst
@@ -796,7 +796,9 @@ In general, names should be in camel case (e.g. ``TextFileReader`` and
   
 As an exception, classes that mimic STL classes can have member names in STL's
 style of lower-case words separated by underscores (e.g. ``begin()``,
-``push_back()``, and ``empty()``).
+``push_back()``, and ``empty()``). Classes that provide multiple
+iterators should add a singular prefix to ``begin()`` and ``end()``
+(e.g. ``global_begin()`` and ``use_begin()``).
 
 Here are some examples of good and bad names:
 
diff --git a/docs/CommandGuide/FileCheck.rst b/docs/CommandGuide/FileCheck.rst
index 0d98349..6be5fc3 100644
--- a/docs/CommandGuide/FileCheck.rst
+++ b/docs/CommandGuide/FileCheck.rst
@@ -18,7 +18,8 @@ using :program:`grep`, but it is optimized for matching multiple different
 inputs in one file in a specific order.
 
 The ``match-filename`` file specifies the file that contains the patterns to
-match.  The file to verify is always read from standard input.
+match.  The file to verify is read from standard input unless the
+:option:`--input-file` option is used.
 
 OPTIONS
 -------
@@ -44,7 +45,7 @@ OPTIONS
  By default, FileCheck canonicalizes input horizontal whitespace (spaces and
  tabs) which causes it to ignore these differences (a space will match a tab).
  The :option:`--strict-whitespace` argument disables this behavior. End-of-line
- sequences are canonicalized to UNIX-style '\n' in all modes.
+ sequences are canonicalized to UNIX-style ``\n`` in all modes.
 
 .. option:: -version
 
@@ -243,6 +244,57 @@ occurrences matching ``CHECK-DAG:`` after ``CHECK-NOT:``. For example,
 
 This case will reject input strings where ``BEFORE`` occurs after ``AFTER``.
 
+The "CHECK-LABEL:" directive
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Sometimes in a file containing multiple tests divided into logical blocks, one
+or more ``CHECK:`` directives may inadvertently succeed by matching lines in a
+later block. While an error will usually eventually be generated, the check
+flagged as causing the error may not actually bear any relationship to the
+actual source of the problem.
+
+In order to produce better error messages in these cases, the "``CHECK-LABEL:``"
+directive can be used. It is treated identically to a normal ``CHECK``
+directive except that FileCheck makes an additional assumption that a line
+matched by the directive cannot also be matched by any other check present in
+``match-filename``; this is intended to be used for lines containing labels or
+other unique identifiers. Conceptually, the presence of ``CHECK-LABEL`` divides
+the input stream into separate blocks, each of which is processed independently,
+preventing a ``CHECK:`` directive in one block matching a line in another block.
+For example,
+
+.. code-block:: llvm
+
+  define %struct.C* @C_ctor_base(%struct.C* %this, i32 %x) {
+  entry:
+  ; CHECK-LABEL: C_ctor_base:
+  ; CHECK: mov [[SAVETHIS:r[0-9]+]], r0
+  ; CHECK: bl A_ctor_base
+  ; CHECK: mov r0, [[SAVETHIS]]
+    %0 = bitcast %struct.C* %this to %struct.A*
+    %call = tail call %struct.A* @A_ctor_base(%struct.A* %0)
+    %1 = bitcast %struct.C* %this to %struct.B*
+    %call2 = tail call %struct.B* @B_ctor_base(%struct.B* %1, i32 %x)
+    ret %struct.C* %this
+  }
+
+  define %struct.D* @D_ctor_base(%struct.D* %this, i32 %x) {
+  entry:
+  ; CHECK-LABEL: D_ctor_base:
+
+The use of ``CHECK-LABEL:`` directives in this case ensures that the three
+``CHECK:`` directives only accept lines corresponding to the body of the
+``@C_ctor_base`` function, even if the patterns match lines found later in
+the file. Furthermore, if one of these three ``CHECK:`` directives fail,
+FileCheck will recover by continuing to the next block, allowing multiple test
+failures to be detected in a single invocation.
+
+There is no requirement that ``CHECK-LABEL:`` directives contain strings that
+correspond to actual syntactic labels in a source or output language: they must
+simply uniquely match a single line in the file being verified.
+
+``CHECK-LABEL:`` directives cannot contain variable definitions or uses.
+
 FileCheck Pattern Matching Syntax
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
diff --git a/docs/CommandGuide/index.rst b/docs/CommandGuide/index.rst
index b3b4bc3..d50542d 100644
--- a/docs/CommandGuide/index.rst
+++ b/docs/CommandGuide/index.rst
@@ -21,7 +21,6 @@ Basic Commands
    lli
    llvm-link
    llvm-ar
-   llvm-ranlib
    llvm-nm
    llvm-prof
    llvm-config
diff --git a/docs/CommandGuide/lit.rst b/docs/CommandGuide/lit.rst
index 2f6d9a1..a4681fb 100644
--- a/docs/CommandGuide/lit.rst
+++ b/docs/CommandGuide/lit.rst
@@ -316,6 +316,10 @@ executed, two important global variables are predefined:
  *on_clone* function will generally modify), and (3) the test path to the new
  directory being scanned.
 
+ **pipefail** Normally a test using a shell pipe fails if any of the commands
+ on the pipe fail. If this is not desired, setting this variable to false
+ makes the test fail only if the last command in the pipe fails.
+
 TEST DISCOVERY
 ~~~~~~~~~~~~~~
 
diff --git a/docs/CommandGuide/llc.rst b/docs/CommandGuide/llc.rst
index e6a5976..02ad798 100644
--- a/docs/CommandGuide/llc.rst
+++ b/docs/CommandGuide/llc.rst
@@ -141,24 +141,24 @@ Tuning/Configuration Options
 
 .. option:: --regalloc=<allocator>
 
- Specify the register allocator to use.  The default ``allocator`` is *local*.
+ Specify the register allocator to use.
  Valid register allocators are:
 
- *simple*
+ *basic*
 
-  Very simple "always spill" register allocator
+  Basic register allocator.
 
- *local*
+ *fast*
 
-  Local register allocator
+  Fast register allocator. It is the default for unoptimized code.
 
- *linearscan*
+ *greedy*
 
-  Linear scan global register allocator
+  Greedy register allocator. It is the default for optimized code.
 
- *iterativescan*
+ *pbqp*
 
-  Iterative scan global register allocator
+  Register allocator based on 'Partitioned Boolean Quadratic Programming'.
 
 .. option:: --spiller=<spiller>
 
diff --git a/docs/CommandGuide/llvm-ar.rst b/docs/CommandGuide/llvm-ar.rst
index 8ff4192..d3ee993 100644
--- a/docs/CommandGuide/llvm-ar.rst
+++ b/docs/CommandGuide/llvm-ar.rst
@@ -21,64 +21,24 @@ LLVM program. However, the archive can contain any kind of file. By default,
 only the symbol table needs to be consulted, not each individual file member
 of the archive.
 
-The **llvm-ar** command can be used to *read* both SVR4 and BSD style archive
-files. However, it cannot be used to write them.  While the **llvm-ar** command
-produces files that are *almost* identical to the format used by other ``ar``
-implementations, it has two significant departures in order to make the
-archive appropriate for LLVM. The first departure is that **llvm-ar** only
-uses BSD4.4 style long path names (stored immediately after the header) and
-never contains a string table for long names. The second departure is that the
-symbol table is formated for efficient construction of an in-memory data
-structure that permits rapid (red-black tree) lookups. Consequently, archives
-produced with **llvm-ar** usually won't be readable or editable with any
-``ar`` implementation or useful for linking.  Using the ``f`` modifier to flatten
-file names will make the archive readable by other ``ar`` implementations
-but not for linking because the symbol table format for LLVM is unique. If an
+The **llvm-ar** command can be used to *read* SVR4, GNU and BSD style archive
+files. However, right now it can only write in the GNU format. If an
 SVR4 or BSD style archive is used with the ``r`` (replace) or ``q`` (quick
-update) operations, the archive will be reconstructed in LLVM format. This
-means that the string table will be dropped (in deference to BSD 4.4 long names)
-and an LLVM symbol table will be added (by default). The system symbol table
-will be retained.
+update) operations, the archive will be reconstructed in GNU format.
 
 Here's where **llvm-ar** departs from previous ``ar`` implementations:
 
 
 *Symbol Table*
 
- Since **llvm-ar** is intended to archive bitcode files, the symbol table
- won't make much sense to anything but LLVM. Consequently, the symbol table's
- format has been simplified. It consists simply of a sequence of pairs
- of a file member index number as an LSB 4byte integer and a null-terminated
- string.
-
+ Since **llvm-ar** supports bitcode files. The symbol table it creates
+ is in GNU format and includes both native and bitcode files.
 
 
 *Long Paths*
 
- Some ``ar`` implementations (SVR4) use a separate file member to record long
- path names (> 15 characters). **llvm-ar** takes the BSD 4.4 and Mac OS X
- approach which is to simply store the full path name immediately preceding
- the data for the file. The path name is null terminated and may contain the
- slash (/) character.
-
-
-
-*Directory Recursion*
-
- Most ``ar`` implementations do not recurse through directories but simply
- ignore directories if they are presented to the program in the *files*
- option. **llvm-ar**, however, can recurse through directory structures and
- add all the files under a directory, if requested.
-
-
-
-*TOC Verbose Output*
-
- When **llvm-ar** prints out the verbose table of contents (``tv`` option), it
- precedes the usual output with a character indicating the basic kind of
- content in the file. A blank means the file is a regular file. A 'B' means
- the file is an LLVM bitcode file. An 'S' means the file is the symbol table.
-
+ Currently **llvm-ar** can read GNU and BSD long file names, but only writes
+ archives with the GNU format.
 
 
 
@@ -124,20 +84,19 @@ m[abi]
 
 
 
-p[k]
+p
 
- Print files to the standard output. The *k* modifier applies to this
- operation. This operation simply prints the *files* indicated to the
- standard output. If no *files* are specified, the entire archive is printed.
- Printing bitcode files is ill-advised as they might confuse your terminal
- settings. The *p* operation never modifies the archive.
+ Print files to the standard output. This operation simply prints the
+ *files* indicated to the standard output. If no *files* are
+ specified, the entire  archive is printed.  Printing bitcode files is
+ ill-advised as they might confuse your terminal settings. The *p*
+ operation never modifies the archive.
 
 
 
-q[Rf]
+q
 
- Quickly append files to the end of the archive. The *R*, and *f*
- modifiers apply to this operation.  This operation quickly adds the
+ Quickly append files to the end of the archive.  This operation quickly adds the
  *files* to the archive without checking for duplicates that should be
  removed first. If no *files* are specified, the archive is not modified.
  Because of the way that **llvm-ar** constructs the archive file, its dubious
@@ -145,9 +104,9 @@ q[Rf]
 
 
 
-r[Rabfu]
+r[abu]
 
- Replace or insert file members. The *R*, *a*, *b*, *f*, and *u*
+ Replace or insert file members. The *a*, *b*,  and *u*
  modifiers apply to this operation. This operation will replace existing
  *files* or insert them at the end of the archive if they do not exist. If no
  *files* are specified, the archive is not modified.
@@ -201,37 +160,12 @@ section (above) to determine which modifiers are applicable to which operations.
 
 
 
-[f]
-
- Normally, **llvm-ar** stores the full path name to a file as presented to it on
- the command line. With this option, truncated (15 characters max) names are
- used. This ensures name compatibility with older versions of ``ar`` but may also
- thwart correct extraction of the files (duplicates may overwrite). If used with
- the *R* option, the directory recursion will be performed but the file names
- will all be flattened to simple file names.
-
-
-
 [i]
 
  A synonym for the *b* option.
 
 
 
-[k]
-
- Normally, **llvm-ar** will not print the contents of bitcode files when the
- *p* operation is used. This modifier defeats the default and allows the
- bitcode members to be printed.
-
-
-
-[N]
-
- This option is ignored by **llvm-ar** but provided for compatibility.
-
-
-
 [o]
 
  When extracting files, this option will cause **llvm-ar** to preserve the
@@ -239,22 +173,6 @@ section (above) to determine which modifiers are applicable to which operations.
 
 
 
-[P]
-
- use full path names when matching
-
-
-
-[R]
-
- This modifier instructions the *r* option to recursively process directories.
- Without *R*, directories are ignored and only those *files* that refer to
- files will be added to the archive. When *R* is used, any directories specified
- with *files* will be scanned (recursively) to find files to be added to the
- archive. Any file whose name begins with a dot will not be added.
-
-
-
 [u]
 
  When replacing existing files in the archive, only replace those files that have
@@ -283,8 +201,7 @@ The modifiers below may be applied to any operation.
  This modifier requests that an archive index (or symbol table) be added to the
  archive. This is the default mode of operation. The symbol table will contain
  all the externally visible functions and global variables defined by all the
- bitcode files in the archive. Using this modifier is more efficient that using
- llvm-ranlib|llvm-ranlib which also creates the symbol table.
+ bitcode files in the archive.
 
 
 
@@ -401,14 +318,6 @@ fmag - char[2]
  utility in identifying archive files that have been corrupted.
 
 
-
-The LLVM symbol table has the special name "#_LLVM_SYM_TAB_#". It is presumed
-that no regular archive member file will want this name. The LLVM symbol table
-is simply composed of a sequence of triplets: byte offset, length of symbol,
-and the symbol itself. Symbols are not null or newline terminated. Here are
-the details on each of these items:
-
-
 offset - vbr encoded 32-bit integer
 
  The offset item provides the offset into the archive file where the bitcode
@@ -455,4 +364,4 @@ SEE ALSO
 --------
 
 
-llvm-ranlib|llvm-ranlib, ar(1)
+ar(1)
diff --git a/docs/CommandGuide/llvm-ranlib.rst b/docs/CommandGuide/llvm-ranlib.rst
deleted file mode 100644
index 6658818..0000000
--- a/docs/CommandGuide/llvm-ranlib.rst
+++ /dev/null
@@ -1,61 +0,0 @@
-llvm-ranlib - Generate index for LLVM archive
-=============================================
-
-
-SYNOPSIS
---------
-
-
-**llvm-ranlib** [--version] [-help] <archive-file>
-
-
-DESCRIPTION
------------
-
-
-The **llvm-ranlib** command is similar to the common Unix utility, ``ranlib``. It
-adds or updates the symbol table in an LLVM archive file. Note that using the
-**llvm-ar** modifier *s* is usually more efficient than running **llvm-ranlib**
-which is only provided only for completness and compatibility. Unlike other
-implementations of ``ranlib``, **llvm-ranlib** indexes LLVM bitcode files, not
-native object modules. You can list the contents of the symbol table with the
-``llvm-nm -s`` command.
-
-
-OPTIONS
--------
-
-
-
-*archive-file*
-
- Specifies the archive-file to which the symbol table is added or updated.
-
-
-
-*--version*
-
- Print the version of **llvm-ranlib** and exit without building a symbol table.
-
-
-
-*-help*
-
- Print usage help for **llvm-ranlib** and exit without building a symbol table.
-
-
-
-
-EXIT STATUS
------------
-
-
-If **llvm-ranlib** succeeds, it will exit with 0.  If an error occurs, a non-zero
-exit code will be returned.
-
-
-SEE ALSO
---------
-
-
-llvm-ar|llvm-ar, ranlib(1)
diff --git a/docs/CommandGuide/llvm-symbolizer.rst b/docs/CommandGuide/llvm-symbolizer.rst
index 73babb1..e03be9b 100644
--- a/docs/CommandGuide/llvm-symbolizer.rst
+++ b/docs/CommandGuide/llvm-symbolizer.rst
@@ -22,6 +22,8 @@ EXAMPLE
   a.out 0x4004f4
   /tmp/b.out 0x400528
   /tmp/c.so 0x710
+  /tmp/mach_universal_binary:i386 0x1f84
+  /tmp/mach_universal_binary:x86_64 0x100000f24
   $ llvm-symbolizer < addr.txt
   main
   /tmp/a.cc:4
@@ -38,6 +40,12 @@ EXAMPLE
   main
   /tmp/source.cc:8
 
+  _main
+  /tmp/source_i386.cc:8
+
+  _main
+  /tmp/source_x86_64.cc:8
+
 OPTIONS
 -------
 
@@ -59,6 +67,14 @@ OPTIONS
  If a source code location is in an inlined function, prints all the
  inlnied frames. Defaults to true.
 
+.. option:: -default-arch
+
+ If a binary contains object files for multiple architectures (e.g. it is a
+ Mach-O universal binary), symbolize the object file for a given architecture.
+ You can also specify architecture by writing ``binary_name:arch_name`` in the
+ input (see example above). If architecture is not specified in either way,
+ address will not be symbolized. Defaults to empty string.
+
 EXIT STATUS
 -----------
 
diff --git a/docs/CommandLine.rst b/docs/CommandLine.rst
index 6535551..4c84d23 100644
--- a/docs/CommandLine.rst
+++ b/docs/CommandLine.rst
@@ -925,7 +925,7 @@ This section describes the basic attributes that you can specify on options.
 
   .. code-block:: c++
 
-    cl::opt<**bool**> Quiet("quiet");
+    cl::opt<bool> Quiet("quiet");
 
 .. _cl::desc(...):
 
diff --git a/docs/CompilerWriterInfo.rst b/docs/CompilerWriterInfo.rst
index 44e07b0..6110d0b 100644
--- a/docs/CompilerWriterInfo.rst
+++ b/docs/CompilerWriterInfo.rst
@@ -20,6 +20,8 @@ ARM
 
 * `ABI <http://www.arm.com/products/DevTools/ABI.html>`_
 
+* `ABI Addenda and Errata <http://infocenter.arm.com/help/topic/com.arm.doc.ihi0045d/IHI0045D_ABI_addenda.pdf>`_
+
 * `ARM C Language Extensions <http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053a/IHI0053A_acle.pdf>`_
 
 AArch64
@@ -64,6 +66,17 @@ Other documents, collections, notes
 * `PowerPC64 alignment of long doubles (from GCC) <http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00997.html>`_
 * `Long branch stubs for powerpc64-linux (from binutils) <http://sources.redhat.com/ml/binutils/2002-04/msg00573.html>`_
 
+R600
+----
+
+* `AMD R6xx shader ISA <http://developer.amd.com/wordpress/media/2012/10/R600_Instruction_Set_Architecture.pdf>`_
+* `AMD R7xx shader ISA <http://developer.amd.com/wordpress/media/2012/10/R700-Family_Instruction_Set_Architecture.pdf>`_
+* `AMD Evergreen shader ISA <http://developer.amd.com/wordpress/media/2012/10/AMD_Evergreen-Family_Instruction_Set_Architecture.pdf>`_
+* `AMD Cayman/Trinity shader ISA <http://developer.amd.com/wordpress/media/2012/10/AMD_HD_6900_Series_Instruction_Set_Architecture.pdf>`_
+* `AMD Southern Islands Series ISA <http://developer.amd.com/wordpress/media/2012/12/AMD_Southern_Islands_Instruction_Set_Architecture.pdf>`_
+* `AMD GPU Programming Guide <http://developer.amd.com/download/AMD_Accelerated_Parallel_Processing_OpenCL_Programming_Guide.pdf>`_
+* `AMD Compute Resources <http://developer.amd.com/tools/heterogeneous-computing/amd-accelerated-parallel-processing-app-sdk/documentation/>`_
+
 SPARC
 -----
 
diff --git a/docs/Extensions.rst b/docs/Extensions.rst
index 062804a..78ff874 100644
--- a/docs/Extensions.rst
+++ b/docs/Extensions.rst
@@ -4,7 +4,6 @@ LLVM Extensions
 
 .. contents::
    :local:
-   :depth: 1
 
 .. toctree::
    :hidden:
@@ -21,6 +20,9 @@ Machine-specific Assembly Syntax
 X86/COFF-Dependent
 ------------------
 
+Relocations
+^^^^^^^^^^^
+
 The following additional relocation type is supported:
 
 **@IMGREL** (AT&T syntax only) generates an image-relative relocation that
@@ -37,3 +39,55 @@ corresponds to the COFF relocation types ``IMAGE_REL_I386_DIR32NB`` (32-bit) or
     .long fun@IMGREL
     .long (fun@imgrel + 0x3F)
     .long $unwind$fun@imgrel
+
+
+``.linkonce`` Directive
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Syntax:
+
+   ``.linkonce [ comdat type [ section identifier ] ]``
+
+Supported COMDAT types:
+
+``discard``
+   Discards duplicate sections with the same COMDAT symbol. This is the default
+   if no type is specified.
+
+``one_only``
+   If the symbol is defined multiple times, the linker issues an error.
+
+``same_size``
+   Duplicates are discarded, but the linker issues an error if any have
+   different sizes.
+
+``same_contents``
+   Duplicates are discarded, but the linker issues an error if any duplicates
+   do not have exactly the same content.
+
+``associative``
+   Links the section if a certain other COMDAT section is linked. This other
+   section is indicated by its section identifier following the comdat type.
+   The following restrictions apply to the associated section:
+
+   1. It must be the name of a section already defined.
+   2. It must differ from the current section.
+   3. It must be a COMDAT section.
+   4. It cannot be another associative COMDAT section.
+
+``largest``
+   Links the largest section from among the duplicates.
+
+``newest``
+   Links the newest section from among the duplicates.
+
+
+.. code-block:: gas
+
+  .section .text$foo
+  .linkonce
+    ...
+
+  .section .xdata$foo
+  .linkonce associative .text$foo
+    ...
diff --git a/docs/GarbageCollection.rst b/docs/GarbageCollection.rst
index 5c3a1af..b722277 100644
--- a/docs/GarbageCollection.rst
+++ b/docs/GarbageCollection.rst
@@ -764,8 +764,8 @@ The following can be used as a template:
 
 .. code-block:: c++
 
-  #include "llvm/Module.h"
-  #include "llvm/IntrinsicInst.h"
+  #include "llvm/IR/Module.h"
+  #include "llvm/IR/IntrinsicInst.h"
 
   bool MyGC::initializeCustomLowering(Module &M) {
     return false;
@@ -915,10 +915,10 @@ map for the entire module, and may access the ``GCFunctionInfo`` using its own
 .. code-block:: c++
 
   #include "llvm/CodeGen/AsmPrinter.h"
-  #include "llvm/Function.h"
-  #include "llvm/Target/TargetMachine.h"
-  #include "llvm/DataLayout.h"
+  #include "llvm/IR/Function.h"
+  #include "llvm/IR/DataLayout.h"
   #include "llvm/Target/TargetAsmInfo.h"
+  #include "llvm/Target/TargetMachine.h"
 
   void MyGCPrinter::beginAssembly(std::ostream &OS, AsmPrinter &AP,
                                   const TargetAsmInfo &TAI) {
diff --git a/docs/GettingStarted.rst b/docs/GettingStarted.rst
index 3498b88..40dfc45 100644
--- a/docs/GettingStarted.rst
+++ b/docs/GettingStarted.rst
@@ -758,7 +758,7 @@ The following options can be used to set or enable LLVM specific options:
   target names that you want available in llc. The target names use all lower
   case. The current set of targets is:
 
-    ``arm, cpp, hexagon, mblaze, mips, mipsel, msp430, powerpc, ptx, sparc, spu,
+    ``arm, cpp, hexagon, mips, mipsel, msp430, powerpc, ptx, sparc, spu,
     systemz, x86, x86_64, xcore``.
 
 ``--enable-doxygen``
diff --git a/docs/GettingStartedVS.rst b/docs/GettingStartedVS.rst
index a80a9e2..9847c83 100644
--- a/docs/GettingStartedVS.rst
+++ b/docs/GettingStartedVS.rst
@@ -45,13 +45,13 @@ and software you will need.
 
 Hardware
 --------
-Any system that can adequately run Visual Studio 2008 is fine. The LLVM
+Any system that can adequately run Visual Studio 2010 is fine. The LLVM
 source tree and object files, libraries and executables will consume
 approximately 3GB.
 
 Software
 --------
-You will need Visual Studio 2008 or higher.  Earlier versions of Visual
+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.
 
diff --git a/docs/LangRef.rst b/docs/LangRef.rst
index 2c55d33..b69e2a3 100644
--- a/docs/LangRef.rst
+++ b/docs/LangRef.rst
@@ -733,14 +733,13 @@ Currently, only the following parameter attributes are defined:
     attribute for return values and can only be applied to one parameter.
 
 ``returned``
-    This indicates that the value of the function always returns the value
-    of the parameter as its return value. This is an optimization hint to
-    the code generator when generating the caller, allowing tail call
-    optimization and omission of register saves and restores in some cases;
-    it is not checked or enforced when generating the callee. The parameter
-    and the function return type must be valid operands for the
-    :ref:`bitcast instruction <i_bitcast>`. This is not a valid attribute for
-    return values and can only be applied to one parameter.
+    This indicates that the function always returns the argument as its return
+    value. This is an optimization hint to the code generator when generating
+    the caller, allowing tail call optimization and omission of register saves
+    and restores in some cases; it is not checked or enforced when generating
+    the callee. The parameter and the function return type must be valid
+    operands for the :ref:`bitcast instruction <i_bitcast>`. This is not a
+    valid attribute for return values and can only be applied to one parameter.
 
 .. _gc:
 
@@ -818,15 +817,17 @@ example:
     This attribute indicates that the inliner should attempt to inline
     this function into callers whenever possible, ignoring any active
     inlining size threshold for this caller.
+``builtin``
+    This indicates that the callee function at a call site should be
+    recognized as a built-in function, even though the function's declaration
+    uses the ``nobuiltin`` attribute. This is only valid at call sites for
+    direct calls to functions which are declared with the ``nobuiltin``
+    attribute.
 ``cold``
     This attribute indicates that this function is rarely called. When
     computing edge weights, basic blocks post-dominated by a cold
     function call are also considered to be cold; and, thus, given low
     weight.
-``nonlazybind``
-    This attribute suppresses lazy symbol binding for the function. This
-    may make calls to the function faster, at the cost of extra program
-    startup time if the function is not called during program startup.
 ``inlinehint``
     This attribute indicates that the source code contained a hint that
     inlining this function is desirable (such as the "inline" keyword in
@@ -836,11 +837,11 @@ example:
     This attribute disables prologue / epilogue emission for the
     function. This can have very system-specific consequences.
 ``nobuiltin``
-    This indicates that the callee function at a call site is not
-    recognized as a built-in function. LLVM will retain the original call
-    and not replace it with equivalent code based on the semantics of the
-    built-in function. This is only valid at call sites, not on function
-    declarations or definitions.
+    This indicates that the callee function at a call site is not recognized as
+    a built-in function. LLVM will retain the original call and not replace it
+    with equivalent code based on the semantics of the built-in function, unless
+    the call site uses the ``builtin`` attribute. This is valid at call sites
+    and on function declarations and definitions.
 ``noduplicate``
     This attribute indicates that calls to the function cannot be
     duplicated. A call to a ``noduplicate`` function may be moved
@@ -858,6 +859,10 @@ example:
     This attribute indicates that the inliner should never inline this
     function in any situation. This attribute may not be used together
     with the ``alwaysinline`` attribute.
+``nonlazybind``
+    This attribute suppresses lazy symbol binding for the function. This
+    may make calls to the function faster, at the cost of extra program
+    startup time if the function is not called during program startup.
 ``noredzone``
     This attribute indicates that the code generator should not use a
     red zone, even if the target-specific ABI normally permits it.
@@ -874,17 +879,21 @@ example:
     passes make choices that keep the code size of this function low,
     and otherwise do optimizations specifically to reduce code size.
 ``readnone``
-    This attribute indicates that the function computes its result (or
-    decides to unwind an exception) based strictly on its arguments,
+    On a function, this attribute indicates that the function computes its
+    result (or decides to unwind an exception) based strictly on its arguments,
     without dereferencing any pointer arguments or otherwise accessing
     any mutable state (e.g. memory, control registers, etc) visible to
     caller functions. It does not write through any pointer arguments
     (including ``byval`` arguments) and never changes any state visible
     to callers. This means that it cannot unwind exceptions by calling
     the ``C++`` exception throwing methods.
+    
+    On an argument, this attribute indicates that the function does not
+    dereference that pointer argument, even though it may read or write the
+    memory that the pointer points to if accessed through other pointers.
 ``readonly``
-    This attribute indicates that the function does not write through
-    any pointer arguments (including ``byval`` arguments) or otherwise
+    On a function, this attribute indicates that the function does not write
+    through any pointer arguments (including ``byval`` arguments) or otherwise
     modify any state (e.g. memory, control registers, etc) visible to
     caller functions. It may dereference pointer arguments and read
     state that may be set in the caller. A readonly function always
@@ -892,6 +901,10 @@ example:
     called with the same set of arguments and global state. It cannot
     unwind an exception by calling the ``C++`` exception throwing
     methods.
+    
+    On an argument, this attribute indicates that the function does not write
+    through this pointer argument, even though it may write to the memory that
+    the pointer points to.
 ``returns_twice``
     This attribute indicates that this function can return twice. The C
     ``setjmp`` is an example of such a function. The compiler disables
@@ -1048,7 +1061,9 @@ the specifications in the ``datalayout`` keyword. The default
 specifications are given in this list:
 
 -  ``E`` - big endian
--  ``p:64:64:64`` - 64-bit pointers with 64-bit alignment
+-  ``p:64:64:64`` - 64-bit pointers with 64-bit alignment.
+-  ``p[n]:64:64:64`` - Other address spaces are assumed to be the
+   same as the default address space.
 -  ``S0`` - natural stack alignment is unspecified
 -  ``i1:8:8`` - i1 is 8-bit (byte) aligned
 -  ``i8:8:8`` - i8 is 8-bit (byte) aligned
@@ -2570,7 +2585,7 @@ Examples:
 It is sometimes useful to attach information to loop constructs. Currently,
 loop metadata is implemented as metadata attached to the branch instruction
 in the loop latch block. This type of metadata refer to a metadata node that is
-guaranteed to be separate for each loop. The loop identifier metadata is 
+guaranteed to be separate for each loop. The loop identifier metadata is
 specified with the name ``llvm.loop``.
 
 The loop identifier metadata is implemented using a metadata that refers to
@@ -4641,16 +4656,16 @@ alignment results in undefined behavior. Underestimating the alignment
 may produce less efficient code. An alignment of 1 is always safe.
 
 The optional ``!nontemporal`` metadata must reference a single
-metatadata name ``<index>`` corresponding to a metadata node with one
+metadata name ``<index>`` corresponding to a metadata node with one
 ``i32`` entry of value 1. The existence of the ``!nontemporal``
-metatadata on the instruction tells the optimizer and code generator
+metadata on the instruction tells the optimizer and code generator
 that this load is not expected to be reused in the cache. The code
 generator may select special instructions to save cache bandwidth, such
 as the ``MOVNT`` instruction on x86.
 
 The optional ``!invariant.load`` metadata must reference a single
-metatadata name ``<index>`` corresponding to a metadata node with no
-entries. The existence of the ``!invariant.load`` metatadata on the
+metadata name ``<index>`` corresponding to a metadata node with no
+entries. The existence of the ``!invariant.load`` metadata on the
 instruction tells the optimizer and code generator that this load
 address points to memory which does not change value during program
 execution. The optimizer may then move this load around, for example, by
@@ -4726,9 +4741,9 @@ alignment results in undefined behavior. Underestimating the
 alignment may produce less efficient code. An alignment of 1 is always
 safe.
 
-The optional ``!nontemporal`` metadata must reference a single metatadata
+The optional ``!nontemporal`` metadata must reference a single metadata
 name ``<index>`` corresponding to a metadata node with one ``i32`` entry of
-value 1. The existence of the ``!nontemporal`` metatadata on the instruction
+value 1. The existence of the ``!nontemporal`` metadata on the instruction
 tells the optimizer and code generator that this load is not expected to
 be reused in the cache. The code generator may select special
 instructions to save cache bandwidth, such as the MOVNT instruction on
@@ -5600,24 +5615,24 @@ Arguments:
 
 The '``bitcast``' instruction takes a value to cast, which must be a
 non-aggregate first class value, and a type to cast it to, which must
-also be a non-aggregate :ref:`first class <t_firstclass>` type. The bit
-sizes of ``value`` and the destination type, ``ty2``, must be identical.
-If the source type is a pointer, the destination type must also be a
-pointer. This instruction supports bitwise conversion of vectors to
-integers and to vectors of other types (as long as they have the same
-size).
+also be a non-aggregate :ref:`first class <t_firstclass>` type. The
+bit sizes of ``value`` and the destination type, ``ty2``, must be
+identical.  If the source type is a pointer, the destination type must
+also be a pointer of the same size. This instruction supports bitwise
+conversion of vectors to integers and to vectors of other types (as
+long as they have the same size).
 
 Semantics:
 """"""""""
 
-The '``bitcast``' instruction converts ``value`` to type ``ty2``. It is
-always a *no-op cast* because no bits change with this conversion. The
-conversion is done as if the ``value`` had been stored to memory and
-read back as type ``ty2``. Pointer (or vector of pointers) types may
-only be converted to other pointer (or vector of pointers) types with
-this instruction. To convert pointers to other types, use the
-:ref:`inttoptr <i_inttoptr>` or :ref:`ptrtoint <i_ptrtoint>` instructions
-first.
+The '``bitcast``' instruction converts ``value`` to type ``ty2``. It
+is always a *no-op cast* because no bits change with this
+conversion. The conversion is done as if the ``value`` had been stored
+to memory and read back as type ``ty2``. Pointer (or vector of
+pointers) types may only be converted to other pointer (or vector of
+pointers) types with this instruction if the pointer sizes are
+equal. To convert pointers to other types, use the :ref:`inttoptr
+<i_inttoptr>` or :ref:`ptrtoint <i_ptrtoint>` instructions first.
 
 Example:
 """"""""
diff --git a/docs/MakefileGuide.rst b/docs/MakefileGuide.rst
index 3e90907..0bb4a3c 100644
--- a/docs/MakefileGuide.rst
+++ b/docs/MakefileGuide.rst
@@ -172,26 +172,6 @@ intend to be loaded into an tool via the ``-load`` option.  `Pass documentation
 <writing-an-llvm-pass-makefile>`_ has an example of why you might want to do
 this.
 
-Bitcode Modules
-^^^^^^^^^^^^^^^
-
-In some situations, it is desirable to build a single bitcode module from a
-variety of sources, instead of an archive, shared library, or bitcode
-library. Bitcode modules can be specified in addition to any of the other types
-of libraries by defining the `MODULE_NAME`_ variable. For example:
-
-.. code-block:: makefile
-
-  LIBRARYNAME = mylib
-  BYTECODE_LIBRARY = 1
-  MODULE_NAME = mymod
-
-will build a module named ``mymod.bc`` from the sources in the directory. This
-module will be an aggregation of all the bitcode modules derived from the
-sources. The example will also build a bitcode archive containing a bitcode
-module for each compiled source file. The difference is subtle, but important
-depending on how the module or library is to be linked.
-
 Loadable Modules
 ^^^^^^^^^^^^^^^^
 
@@ -486,9 +466,6 @@ system that tell it what to do for the current directory.
     files. These sources will be built before any other target processing to
     ensure they are present.
 
-``BYTECODE_LIBRARY``
-    If set to any value, causes a bitcode library (.bc) to be built.
-
 ``CONFIG_FILES``
     Specifies a set of configuration files to be installed.
 
@@ -590,13 +567,6 @@ system that tell it what to do for the current directory.
     setting this variable without also setting ``SHARED_LIBRARY`` will have no
     effect.
 
-.. _MODULE_NAME:
-
-``MODULE_NAME``
-    Specifies the name of a bitcode module to be created. A bitcode module can
-    be specified in conjunction with other kinds of library builds or by
-    itself. It constructs from the sources a single linked bitcode file.
-
 ``NO_INSTALL``
     Specifies that the build products of the directory should not be installed
     but should be built even if the ``install`` target is given.  This is handy
@@ -739,12 +709,6 @@ The override variables are given below:
 ``LLVMAS`` (defaulted)
     Specifies the path to the ``llvm-as`` tool.
 
-``LLVMCC``
-    Specifies the path to the LLVM capable compiler.
-
-``LLVMCXX``
-    Specifies the path to the LLVM C++ capable compiler.
-
 ``LLVMGCC`` (defaulted)
     Specifies the path to the LLVM version of the GCC 'C' Compiler.
 
@@ -888,8 +852,6 @@ internal. You should not use these variables under any circumstances.
     Archive
     AR.Flags
     BaseNameSources
-    BCCompile.C
-    BCCompile.CXX
     BCLinkLib
     C.Flags
     Compile.C
@@ -936,7 +898,6 @@ internal. You should not use these variables under any circumstances.
     LLVMUsedLibs
     LocalTargets
     Module
-    ObjectsBC
     ObjectsLO
     ObjectsO
     ObjMakefiles
diff --git a/docs/Phabricator.rst b/docs/Phabricator.rst
index efab10c..0c6990e 100644
--- a/docs/Phabricator.rst
+++ b/docs/Phabricator.rst
@@ -56,7 +56,7 @@ to upload your patch):
 To upload a new patch:
 
 * Click *Differential*.
-* Click *Create Revision*.
+* Click *Create Diff*.
 * Paste the text diff or upload the patch file.
   Note that TODO
 * Leave the drop down on *Create a new Revision...* and click *Continue*.
diff --git a/docs/ProgrammersManual.rst b/docs/ProgrammersManual.rst
index 7864165..2910a2a 100644
--- a/docs/ProgrammersManual.rst
+++ b/docs/ProgrammersManual.rst
@@ -2421,7 +2421,7 @@ place the ``vptr`` in the first word of the instances.)
 The Core LLVM Class Hierarchy Reference
 =======================================
 
-``#include "llvm/Type.h"``
+``#include "llvm/IR/Type.h"``
 
 header source: `Type.h <http://llvm.org/doxygen/Type_8h-source.html>`_
 
@@ -2524,7 +2524,7 @@ Important Derived Types
 The ``Module`` class
 --------------------
 
-``#include "llvm/Module.h"``
+``#include "llvm/IR/Module.h"``
 
 header source: `Module.h <http://llvm.org/doxygen/Module_8h-source.html>`_
 
@@ -2611,7 +2611,7 @@ Important Public Members of the ``Module`` class
 The ``Value`` class
 -------------------
 
-``#include "llvm/Value.h"``
+``#include "llvm/IR/Value.h"``
 
 header source: `Value.h <http://llvm.org/doxygen/Value_8h-source.html>`_
 
@@ -2702,7 +2702,7 @@ Important Public Members of the ``Value`` class
 The ``User`` class
 ------------------
 
-``#include "llvm/User.h"``
+``#include "llvm/IR/User.h"``
 
 header source: `User.h <http://llvm.org/doxygen/User_8h-source.html>`_
 
@@ -2748,7 +2748,7 @@ interface and through an iterator based interface.
 The ``Instruction`` class
 -------------------------
 
-``#include "llvm/Instruction.h"``
+``#include "llvm/IR/Instruction.h"``
 
 header source: `Instruction.h
 <http://llvm.org/doxygen/Instruction_8h-source.html>`_
@@ -2896,7 +2896,7 @@ Important Subclasses of Constant
 The ``GlobalValue`` class
 -------------------------
 
-``#include "llvm/GlobalValue.h"``
+``#include "llvm/IR/GlobalValue.h"``
 
 header source: `GlobalValue.h
 <http://llvm.org/doxygen/GlobalValue_8h-source.html>`_
@@ -2955,7 +2955,7 @@ Important Public Members of the ``GlobalValue`` class
 The ``Function`` class
 ----------------------
 
-``#include "llvm/Function.h"``
+``#include "llvm/IR/Function.h"``
 
 header source: `Function.h <http://llvm.org/doxygen/Function_8h-source.html>`_
 
@@ -3063,7 +3063,7 @@ Important Public Members of the ``Function``
 The ``GlobalVariable`` class
 ----------------------------
 
-``#include "llvm/GlobalVariable.h"``
+``#include "llvm/IR/GlobalVariable.h"``
 
 header source: `GlobalVariable.h
 <http://llvm.org/doxygen/GlobalVariable_8h-source.html>`_
@@ -3121,7 +3121,7 @@ Important Public Members of the ``GlobalVariable`` class
 The ``BasicBlock`` class
 ------------------------
 
-``#include "llvm/BasicBlock.h"``
+``#include "llvm/IR/BasicBlock.h"``
 
 header source: `BasicBlock.h
 <http://llvm.org/doxygen/BasicBlock_8h-source.html>`_
diff --git a/docs/ReleaseNotes.rst b/docs/ReleaseNotes.rst
index ba23543..7b143f6 100644
--- a/docs/ReleaseNotes.rst
+++ b/docs/ReleaseNotes.rst
@@ -41,11 +41,35 @@ Non-comprehensive list of changes in this release
    functionality, or simply have a lot to talk about), see the `NOTE` below
    for adding a new subsection.
 
+* 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.
+
+* The library call simplification pass has been removed.  Its functionality
+  has been integrated into the instruction combiner and function attribute
+  marking passes.
+
+* 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.
+
+* The Loop Vectorizer that was previously enabled for -O3 is now enabled for
+  -Os and -O2.
+
+* The new SLP Vectorizer is now enabled by default.
+
+* llvm-ar now uses the new Object library and produces archives and
+  symbol tables in the gnu format.
+
 * ... next change ...
 
 .. NOTE
diff --git a/docs/TestingGuide.rst b/docs/TestingGuide.rst
index 79cedee..3cfbb21 100644
--- a/docs/TestingGuide.rst
+++ b/docs/TestingGuide.rst
@@ -275,6 +275,66 @@ This test will fail if placed into a ``download`` directory.
 To make your tests robust, always use ``opt ... < %s`` in the RUN line.
 :program:`opt` does not output a ``ModuleID`` when input comes from stdin.
 
+Platform-Specific Tests
+-----------------------
+
+Whenever adding tests that require the knowledge of a specific platform,
+either related to code generated, specific output or back-end features,
+you must make sure to isolate the features, so that buildbots that
+run on different architectures (and don't even compile all back-ends),
+don't fail.
+
+The first problem is to check for target-specific output, for example sizes
+of structures, paths and architecture names, for example:
+
+* Tests containing Windows paths will fail on Linux and vice-versa.
+* Tests that check for ``x86_64`` somewhere in the text will fail anywhere else.
+* Tests where the debug information calculates the size of types and structures.
+
+Also, if the test rely on any behaviour that is coded in any back-end, it must
+go in its own directory. So, for instance, code generator tests for ARM go
+into ``test/CodeGen/ARM`` and so on. Those directories contain a special
+``lit`` configuration file that ensure all tests in that directory will
+only run if a specific back-end is compiled and available.
+
+For instance, on ``test/CodeGen/ARM``, the ``lit.local.cfg`` is:
+
+.. code-block:: python
+
+  config.suffixes = ['.ll', '.c', '.cpp', '.test']
+  targets = set(config.root.targets_to_build.split())
+  if not 'ARM' in targets:
+    config.unsupported = True
+
+Other platform-specific tests are those that depend on a specific feature
+of a specific sub-architecture, for example only to Intel chips that support ``AVX2``.
+
+For instance, ``test/CodeGen/X86/psubus.ll`` tests three sub-architecture
+variants:
+
+.. code-block:: llvm
+
+  ; RUN: llc -mcpu=core2 < %s | FileCheck %s -check-prefix=SSE2
+  ; RUN: llc -mcpu=corei7-avx < %s | FileCheck %s -check-prefix=AVX1
+  ; RUN: llc -mcpu=core-avx2 < %s | FileCheck %s -check-prefix=AVX2
+
+And the checks are different:
+
+.. code-block:: llvm
+
+  ; SSE2: @test1
+  ; SSE2: psubusw LCPI0_0(%rip), %xmm0
+  ; AVX1: @test1
+  ; AVX1: vpsubusw LCPI0_0(%rip), %xmm0, %xmm0
+  ; AVX2: @test1
+  ; AVX2: vpsubusw LCPI0_0(%rip), %xmm0, %xmm0
+
+So, if you're testing for a behaviour that you know is platform-specific or
+depends on special features of sub-architectures, you must add the specific
+triple, test with the specific FileCheck and put it into the specific
+directory that will filter out all other architectures.
+
+
 Variables and substitutions
 ---------------------------
 
diff --git a/docs/Vectorizers.rst b/docs/Vectorizers.rst
index d565c21..61ebca2 100644
--- a/docs/Vectorizers.rst
+++ b/docs/Vectorizers.rst
@@ -7,11 +7,13 @@ Auto-Vectorization in LLVM
 
 LLVM has two vectorizers: The :ref:`Loop Vectorizer <loop-vectorizer>`,
 which operates on Loops, and the :ref:`SLP Vectorizer
-<slp-vectorizer>`, which optimizes straight-line code. These vectorizers
+<slp-vectorizer>`. These vectorizers
 focus on different optimization opportunities and use different techniques.
 The SLP vectorizer merges multiple scalars that are found in the code into
-vectors while the Loop Vectorizer widens instructions in the original loop
-to operate on multiple consecutive loop iterations.
+vectors while the Loop Vectorizer widens instructions in loops
+to operate on multiple consecutive iterations.
+
+Both the Loop Vectorizer and the SLP Vectorizer are enabled by default.
 
 .. _loop-vectorizer:
 
@@ -21,9 +23,8 @@ The Loop Vectorizer
 Usage
 -----
 
-LLVM's Loop Vectorizer is now enabled by default for -O3.
-We plan to enable parts of the Loop Vectorizer on -O2 and -Os in future releases.
-The vectorizer can be disabled using the command line:
+The Loop Vectorizer is enabled by default, but it can be disabled
+through clang using the command line flag:
 
 .. code-block:: console
 
@@ -302,10 +303,9 @@ Details
 -------
 
 The goal of SLP vectorization (a.k.a. superword-level parallelism) is
-to combine similar independent instructions within simple control-flow regions
-into vector instructions. Memory accesses, arithemetic operations, comparison
-operations and some math functions can all be vectorized using this technique
-(subject to the capabilities of the target architecture).
+to combine similar independent instructions
+into vector instructions. Memory accesses, arithmetic operations, comparison
+operations, PHI-nodes, can all be vectorized using this technique.
 
 For example, the following function performs very similar operations on its
 inputs (a1, b1) and (a2, b2). The basic-block vectorizer may combine these
@@ -318,18 +318,17 @@ into vector operations.
     A[1] = a2*(a2 + b2)/b2 + 50*b2/a2;
   }
 
-The SLP-vectorizer has two phases, bottom-up, and top-down. The top-down vectorization
-phase is more aggressive, but takes more time to run.
+The SLP-vectorizer processes the code bottom-up, across basic blocks, in search of scalars to combine.
 
 Usage
 ------
 
-The SLP Vectorizer is not enabled by default, but it can be enabled
+The SLP Vectorizer is enabled by default, but it can be disabled
 through clang using the command line flag:
 
 .. code-block:: console
 
-   $ clang -fslp-vectorize file.c
+   $ clang -fno-slp-vectorize file.c
 
 LLVM has a second basic block vectorization phase
 which is more compile-time intensive (The BB vectorizer). This optimization
@@ -339,24 +338,3 @@ can be enabled through clang using the command line flag:
 
    $ clang -fslp-vectorize-aggressive file.c
 
-
-The SLP vectorizer is in early development stages but can already vectorize
-and accelerate many programs in the LLVM test suite.
-
-=======================   ============
-Benchmark Name              Gain
-=======================   ============
-Misc/flops-7               -32.70%
-Misc/matmul_f64_4x4        -23.23%
-Olden/power                -21.45%
-Misc/flops-4               -14.90%
-ASC_Sequoia/AMGmk          -13.85%
-TSVC/LoopRerolling-flt     -11.76%
-Misc/flops-6               -9.70%
-Misc/flops-5               -8.54%
-Misc/flops                 -8.12%
-TSVC/NodeSplitting-dbl     -6.96%
-Misc-C++/sphereflake       -6.74%
-Ptrdist/yacr2              -6.31%
-=======================   ============
-
diff --git a/docs/WritingAnLLVMBackend.rst b/docs/WritingAnLLVMBackend.rst
index a03a5e4..73381b5 100644
--- a/docs/WritingAnLLVMBackend.rst
+++ b/docs/WritingAnLLVMBackend.rst
@@ -1,6 +1,6 @@
-================================
-Writing an LLVM Compiler Backend
-================================
+=======================
+Writing an LLVM Backend
+=======================
 
 .. toctree::
    :hidden:
@@ -911,6 +911,47 @@ format instructions will bind the operands to the ``rd``, ``rs1``, and ``rs2``
 fields.  This results in the ``XNORrr`` instruction binding ``$dst``, ``$b``,
 and ``$c`` operands to the ``rd``, ``rs1``, and ``rs2`` fields respectively.
 
+TableGen will also generate a function called getNamedOperandIdx() which
+can be used to look up an operand's index in a MachineInstr based on its
+TableGen name.  Setting the UseNamedOperandTable bit in an instruction's
+TableGen definition will add all of its operands to an enumeration in the
+llvm::XXX:OpName namespace and also add an entry for it into the OperandMap
+table, which can be queried using getNamedOperandIdx()
+
+.. code-block:: llvm
+
+  int DstIndex = SP::getNamedOperandIdx(SP::XNORrr, SP::OpName::dst); // => 0
+  int BIndex = SP::getNamedOperandIdx(SP::XNORrr, SP::OpName::b);     // => 1
+  int CIndex = SP::getNamedOperandIdx(SP::XNORrr, SP::OpName::c);     // => 2
+  int DIndex = SP::getNamedOperandIdx(SP::XNORrr, SP::OpName::d);     // => -1
+
+  ...
+
+The entries in the OpName enum are taken verbatim from the TableGen definitions,
+so operands with lowercase names will have lower case entries in the enum.
+
+To include the getNamedOperandIdx() function in your backend, you will need
+to define a few preprocessor macros in XXXInstrInfo.cpp and XXXInstrInfo.h.
+For example:
+
+XXXInstrInfo.cpp:
+
+.. code-block:: c++ 
+
+  #define GET_INSTRINFO_NAMED_OPS // For getNamedOperandIdx() function
+  #include "XXXGenInstrInfo.inc"
+
+XXXInstrInfo.h:
+
+.. code-block:: c++
+
+  #define GET_INSTRINFO_OPERAND_ENUM // For OpName enum
+  #include "XXXGenInstrInfo.inc"
+
+  namespace XXX {
+    int16_t getNamedOperandIdx(uint16_t Opcode, uint16_t NamedIndex);
+  } // End namespace XXX
+
 Instruction Relation Mapping
 ----------------------------
 
diff --git a/docs/WritingAnLLVMPass.rst b/docs/WritingAnLLVMPass.rst
index b10d98f..1114fa0 100644
--- a/docs/WritingAnLLVMPass.rst
+++ b/docs/WritingAnLLVMPass.rst
@@ -96,7 +96,7 @@ Start out with:
 .. code-block:: c++
 
   #include "llvm/Pass.h"
-  #include "llvm/Function.h"
+  #include "llvm/IR/Function.h"
   #include "llvm/Support/raw_ostream.h"
 
 Which are needed because we are writing a `Pass
@@ -184,7 +184,7 @@ As a whole, the ``.cpp`` file looks like:
 .. code-block:: c++
 
     #include "llvm/Pass.h"
-    #include "llvm/Function.h"
+    #include "llvm/IR/Function.h"
     #include "llvm/Support/raw_ostream.h"
 
     using namespace llvm;
@@ -454,7 +454,7 @@ external functions.
 
 To be explicit, ``FunctionPass`` subclasses are not allowed to:
 
-#. Modify a ``Function`` other than the one currently being processed.
+#. Inspect or modify a ``Function`` other than the one currently being processed.
 #. Add or remove ``Function``\ s from the current ``Module``.
 #. Add or remove global variables from the current ``Module``.
 #. Maintain state across invocations of:ref:`runOnFunction
diff --git a/docs/tutorial/index.rst b/docs/tutorial/index.rst
index 69a9aee..dde53ba 100644
--- a/docs/tutorial/index.rst
+++ b/docs/tutorial/index.rst
@@ -34,7 +34,7 @@ External Tutorials
    A simple guide for how to implement an LLVM integrated assembler for an
    architecture.
 
-.. _`Howto: Implementing LLVM Integrated Assembler`: http://www.embecosm.com/download/ean10.html
+.. _`Howto: Implementing LLVM Integrated Assembler`: http://www.embecosm.com/appnotes/ean10/ean10-howto-llvmas-1.0.html
 
 Advanced Topics
 ===============