swiftlang
diff --git a/‎llvm/docs/AMDGPU/AMDGPUAsmGFX10.rst
+2-2 b/‎llvm/docs/AMDGPU/AMDGPUAsmGFX10.rst
+2-2
diff --git a/‎llvm/docs/AMDGPU/AMDGPUAsmGFX7.rst
+2-2 b/‎llvm/docs/AMDGPU/AMDGPUAsmGFX7.rst
+2-2
diff --git a/‎llvm/docs/AMDGPU/AMDGPUAsmGFX8.rst
+2-2 b/‎llvm/docs/AMDGPU/AMDGPUAsmGFX8.rst
+2-2
diff --git a/‎llvm/docs/AMDGPU/AMDGPUAsmGFX9.rst
+2-2 b/‎llvm/docs/AMDGPU/AMDGPUAsmGFX9.rst
+2-2
diff --git a/‎llvm/docs/AMDGPU/AMDGPUAsmGFX900.rst
+2-2 b/‎llvm/docs/AMDGPU/AMDGPUAsmGFX900.rst
+2-2
diff --git a/‎llvm/docs/AMDGPU/AMDGPUAsmGFX904.rst
+2-2 b/‎llvm/docs/AMDGPU/AMDGPUAsmGFX904.rst
+2-2
diff --git a/‎llvm/docs/AMDGPU/AMDGPUAsmGFX906.rst
+2-2 b/‎llvm/docs/AMDGPU/AMDGPUAsmGFX906.rst
+2-2
diff --git a/‎llvm/docs/AMDGPU/AMDGPUAsmGFX908.rst
+2-2 b/‎llvm/docs/AMDGPU/AMDGPUAsmGFX908.rst
+2-2
diff --git a/‎llvm/docs/Atomics.rst
+1-1 b/‎llvm/docs/Atomics.rst
+1-1
diff --git a/‎llvm/docs/BigEndianNEON.rst
+1-1 b/‎llvm/docs/BigEndianNEON.rst
+1-1
diff --git a/‎llvm/docs/BlockFrequencyTerminology.rst
+1-1 b/‎llvm/docs/BlockFrequencyTerminology.rst
+1-1
diff --git a/‎llvm/docs/Bugpoint.rst
+1-1 b/‎llvm/docs/Bugpoint.rst
+1-1
diff --git a/‎llvm/docs/CMakePrimer.rst
+1-1 b/‎llvm/docs/CMakePrimer.rst
+1-1
diff --git a/‎llvm/docs/CodeGenerator.rst
+2-2 b/‎llvm/docs/CodeGenerator.rst
+2-2
diff --git a/‎llvm/docs/CodingStandards.rst
+2-2 b/‎llvm/docs/CodingStandards.rst
+2-2
diff --git a/‎llvm/docs/CommandGuide/lit.rst
+1-1 b/‎llvm/docs/CommandGuide/lit.rst
+1-1
diff --git a/‎llvm/docs/CommandGuide/tblgen.rst
+1-1 b/‎llvm/docs/CommandGuide/tblgen.rst
+1-1
diff --git a/‎llvm/docs/CompileCudaWithLLVM.rst
+2-2 b/‎llvm/docs/CompileCudaWithLLVM.rst
+2-2
diff --git a/‎llvm/docs/CoverageMappingFormat.rst
+1-1 b/‎llvm/docs/CoverageMappingFormat.rst
+1-1
diff --git a/‎llvm/docs/DependenceGraphs/index.rst
+1-1 b/‎llvm/docs/DependenceGraphs/index.rst
+1-1
diff --git a/‎llvm/docs/DeveloperPolicy.rst
+4-4 b/‎llvm/docs/DeveloperPolicy.rst
+4-4
diff --git a/‎llvm/docs/Extensions.rst
+1-1 b/‎llvm/docs/Extensions.rst
+1-1
diff --git a/‎llvm/docs/Frontend/PerformanceTips.rst
+1-1 b/‎llvm/docs/Frontend/PerformanceTips.rst
+1-1
diff --git a/‎llvm/docs/FuzzingLLVM.rst
+1-1 b/‎llvm/docs/FuzzingLLVM.rst
+1-1
diff --git a/‎llvm/docs/GettingStarted.rst
+1-1 b/‎llvm/docs/GettingStarted.rst
+1-1
diff --git a/‎llvm/docs/GlobalISel/GenericOpcode.rst
+1-1 b/‎llvm/docs/GlobalISel/GenericOpcode.rst
+1-1
diff --git a/‎llvm/docs/GwpAsan.rst
+1-1 b/‎llvm/docs/GwpAsan.rst
+1-1
diff --git a/‎llvm/docs/HowToBuildOnARM.rst
+2-2 b/‎llvm/docs/HowToBuildOnARM.rst
+2-2
diff --git a/‎llvm/docs/HowToCrossCompileBuiltinsOnArm.rst
+1-1 b/‎llvm/docs/HowToCrossCompileBuiltinsOnArm.rst
+1-1
@@ -22,8 +22,8 @@ Notation
 
 Notation used in this document is explained :ref:`here<amdgpu_syn_instruction_notation>`.
 
-Overvew
-=======
+Overview
+========
 
 An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document<amdgpu_syn_instructions>`.
 
 
@@ -22,8 +22,8 @@ Notation
 
 Notation used in this document is explained :ref:`here<amdgpu_syn_instruction_notation>`.
 
-Overvew
-=======
+Overview
+========
 
 An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document<amdgpu_syn_instructions>`.
 
 
@@ -22,8 +22,8 @@ Notation
 
 Notation used in this document is explained :ref:`here<amdgpu_syn_instruction_notation>`.
 
-Overvew
-=======
+Overview
+========
 
 An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document<amdgpu_syn_instructions>`.
 
 
@@ -22,8 +22,8 @@ Notation
 
 Notation used in this document is explained :ref:`here<amdgpu_syn_instruction_notation>`.
 
-Overvew
-=======
+Overview
+========
 
 An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document<amdgpu_syn_instructions>`.
 
 
@@ -24,8 +24,8 @@ Notation
 
 Notation used in this document is explained :ref:`here<amdgpu_syn_instruction_notation>`.
 
-Overvew
-=======
+Overview
+========
 
 An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document<amdgpu_syn_instructions>`.
 
 
@@ -24,8 +24,8 @@ Notation
 
 Notation used in this document is explained :ref:`here<amdgpu_syn_instruction_notation>`.
 
-Overvew
-=======
+Overview
+========
 
 An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document<amdgpu_syn_instructions>`.
 
 
@@ -24,8 +24,8 @@ Notation
 
 Notation used in this document is explained :ref:`here<amdgpu_syn_instruction_notation>`.
 
-Overvew
-=======
+Overview
+========
 
 An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document<amdgpu_syn_instructions>`.
 
 
@@ -24,8 +24,8 @@ Notation
 
 Notation used in this document is explained :ref:`here<amdgpu_syn_instruction_notation>`.
 
-Overvew
-=======
+Overview
+========
 
 An overview of generic syntax and other features of AMDGPU instructions may be found :ref:`in this document<amdgpu_syn_instructions>`.
 
 
@@ -562,7 +562,7 @@ various reasons, it is not practical to emit the instructions inline.
 
 There's two typical examples of this.
 
-Some CPUs support multiple instruction sets which can be swiched back and forth
+Some CPUs support multiple instruction sets which can be switched back and forth
 on function-call boundaries. For example, MIPS supports the MIPS16 ISA, which
 has a smaller instruction encoding than the usual MIPS32 ISA. ARM, similarly,
 has the Thumb ISA. In MIPS16 and earlier versions of Thumb, the atomic
 
@@ -12,7 +12,7 @@ Generating code for big endian ARM processors is for the most part straightforwa
 
 The aim of this document is to explain the problem with NEON loads and stores, and the solution that has been implemented in LLVM.
 
-In this document the term "vector" refers to what the ARM ABI calls a "short vector", which is a sequence of items that can fit in a NEON register. This sequence can be 64 or 128 bits in length, and can constitute 8, 16, 32 or 64 bit items. This document refers to A64 instructions throughout, but is almost applicable to the A32/ARMv7 instruction sets also. The ABI format for passing vectors in A32 is sligtly different to A64. Apart from that, the same concepts apply.
+In this document the term "vector" refers to what the ARM ABI calls a "short vector", which is a sequence of items that can fit in a NEON register. This sequence can be 64 or 128 bits in length, and can constitute 8, 16, 32 or 64 bit items. This document refers to A64 instructions throughout, but is almost applicable to the A32/ARMv7 instruction sets also. The ABI format for passing vectors in A32 is slightly different to A64. Apart from that, the same concepts apply.
 
 Example: C-level intrinsics -> assembly
 ---------------------------------------
 
@@ -82,7 +82,7 @@ by a cut edge should equal ``UINT64_MAX``.  In other words, mass is conserved
 as it "falls" through the DAG.
 
 If a function's basic block graph is a DAG, then block masses are valid block
-frequencies.  This works poorly in practise though, since downstream users rely
+frequencies.  This works poorly in practice though, since downstream users rely
 on adding block frequencies together without hitting the maximum.
 
 Loop Scale
 
@@ -121,7 +121,7 @@ non-obvious ways.  Here are some hints and tips:
   miscompilation.  Programs should be temporarily modified to disable outputs
   that are likely to vary from run to run.
 
-* In the `crash debugger`_, ``bugpoint`` does not distiguish different crashes
+* In the `crash debugger`_, ``bugpoint`` does not distinguish different crashes
   during reduction. Thus, if new crash or miscompilation happens, ``bugpoint``
   will continue with the new crash instead. If you would like to stick to
   particular crash, you should write check scripts to validate the error
 
@@ -333,7 +333,7 @@ When defining a CMake command handling arguments is very useful. The examples
 in this section will all use the CMake ``function`` block, but this all applies
 to the ``macro`` block as well.
 
-CMake commands can have named arguments that are requried at every call site. In
+CMake commands can have named arguments that are required at every call site. In
 addition, all commands will implicitly accept a variable number of extra
 arguments (In C parlance, all commands are varargs functions). When a command is
 invoked with extra arguments (beyond the named ones) CMake will store the full
 
@@ -1272,7 +1272,7 @@ compatible with a given physical, this code can be used:
 
 Sometimes, mostly for debugging purposes, it is useful to change the number of
 physical registers available in the target architecture. This must be done
-statically, inside the ``TargetRegsterInfo.td`` file. Just ``grep`` for
+statically, inside the ``TargetRegisterInfo.td`` file. Just ``grep`` for
 ``RegisterClass``, the last parameter of which is a list of registers. Just
 commenting some out is one simple way to avoid them being used. A more polite
 way is to explicitly exclude some registers from the *allocation order*. See the
@@ -2418,7 +2418,7 @@ to spill registers r3-r10.  This allows callees blind to the call signature,
 such as thunks and vararg functions, enough space to cache the argument
 registers.  Therefore, the parameter area is minimally 32 bytes (64 bytes in 64
 bit mode.)  Also note that since the parameter area is a fixed offset from the
-top of the frame, that a callee can access its spilt arguments using fixed
+top of the frame, that a callee can access its split arguments using fixed
 offsets from the stack pointer (or base pointer.)
 
 Combining the information about the linkage, parameter areas and alignment. A
 
@@ -647,7 +647,7 @@ Beware of non-deterministic sorting order of equal elements
 
 ``std::sort`` uses a non-stable sorting algorithm in which the order of equal
 elements is not guaranteed to be preserved. Thus using ``std::sort`` for a
-container having equal elements may result in non-determinstic behavior.
+container having equal elements may result in non-deterministic behavior.
 To uncover such instances of non-determinism, LLVM has introduced a new
 llvm::sort wrapper function. For an EXPENSIVE_CHECKS build this will randomly
 shuffle the container before sorting. Default to using ``llvm::sort`` instead
@@ -1206,7 +1206,7 @@ Don't evaluate ``end()`` every time through a loop
 
 In cases where range-based ``for`` loops can't be used and it is necessary
 to write an explicit iterator-based loop, pay close attention to whether
-``end()`` is re-evaluted on each loop iteration. One common mistake is to
+``end()`` is re-evaluated on each loop iteration. One common mistake is to
 write a loop in this style:
 
 .. code-block:: c++
 
@@ -176,7 +176,7 @@ SELECTION OPTIONS
  "shards", and run only one of them.  Must be used with the
  ``--run-shard=N`` option, which selects the shard to run. The environment
  variable ``LIT_NUM_SHARDS`` can also be used in place of this
- option. These two options provide a coarse mechanism for paritioning large
+ option. These two options provide a coarse mechanism for partitioning large
  testsuites, for parallel execution on separate machines (say in a large
  testing farm).
 
 
@@ -98,7 +98,7 @@ OPTIONS
 
 .. option:: -gen-dag-isel
 
- Generate a DAG (Directed Acycle Graph) instruction selector.
+ Generate a DAG (Directed Acyclic Graph) instruction selector.
 
 .. option:: -gen-asm-matcher
 
 
@@ -512,7 +512,7 @@ LLVM to make it generate good GPU code.  Among these changes are:
 
 * `Memory space inference
   <http://llvm.org/doxygen/NVPTXInferAddressSpaces_8cpp_source.html>`_ --
-  In PTX, we can operate on pointers that are in a paricular "address space"
+  In PTX, we can operate on pointers that are in a particular "address space"
   (global, shared, constant, or local), or we can operate on pointers in the
   "generic" address space, which can point to anything.  Operations in a
   non-generic address space are faster, but pointers in CUDA are not explicitly
@@ -528,7 +528,7 @@ LLVM to make it generate good GPU code.  Among these changes are:
   which fit in 32-bits at runtime. This optimization provides a fast path for
   this common case.
 
-* Aggressive loop unrooling and function inlining -- Loop unrolling and
+* Aggressive loop unrolling and function inlining -- Loop unrolling and
   function inlining need to be more aggressive for GPUs than for CPUs because
   control flow transfer in GPU is more expensive. More aggressive unrolling and
   inlining also promote other optimizations, such as constant propagation and
 
@@ -12,7 +12,7 @@ Introduction
 ============
 
 LLVM's code coverage mapping format is used to provide code coverage
-analysis using LLVM's and Clang's instrumenation based profiling
+analysis using LLVM's and Clang's instrumentation based profiling
 (Clang's ``-fprofile-instr-generate`` option).
 
 This document is aimed at those who use LLVM's code coverage mapping to provide
 
@@ -131,7 +131,7 @@ graph described in [1]_ in the following ways:
 
   1. The graph nodes in the paper represent three main program components, namely *assignment statements*, *for loop headers* and *while loop headers*. In this implementation, DDG nodes naturally represent LLVM IR instructions. An assignment statement in this implementation typically involves a node representing the ``store`` instruction along with a number of individual nodes computing the right-hand-side of the assignment that connect to the ``store`` node via a def-use edge.  The loop header instructions are not represented as special nodes in this implementation because they have limited uses and can be easily identified, for example, through ``LoopAnalysis``.
   2. The paper describes five types of dependency edges between nodes namely *loop dependency*, *flow-*, *anti-*, *output-*, and *input-* dependencies. In this implementation *memory* edges represent the *flow-*, *anti-*, *output-*, and *input-* dependencies. However, *loop dependencies* are not made explicit, because they mainly represent association between a loop structure and the program elements inside the loop and this association is fairly obvious in LLVM IR itself. 
-  3. The paper describes two types of pi-blocks; *recurrences* whose bodies are SCCs and *IN* nodes whose bodies are not part of any SCC. In this impelmentation, pi-blocks are only created for *recurrences*. *IN* nodes remain as simple DDG nodes in the graph.
+  3. The paper describes two types of pi-blocks; *recurrences* whose bodies are SCCs and *IN* nodes whose bodies are not part of any SCC. In this implementation, pi-blocks are only created for *recurrences*. *IN* nodes remain as simple DDG nodes in the graph.
 
 
 References
 
@@ -384,8 +384,8 @@ after they are committed, depending on the nature of the change).  You are
 encouraged to review other peoples' patches as well, but you aren't required
 to do so.
 
-Current Contributors - Transfering from SVN
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Current Contributors - Transferring from SVN
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 If you had commit access to SVN and would like to request commit access to
 GitHub, please email `llvm-admin <mailto:[email protected]>`_ with your
 SVN username and GitHub username.
@@ -744,7 +744,7 @@ OpenMP, etc), Polly, and all other subprojects.  There are a few exceptions:
   is used by LLVM.
 * Some subprojects are impractical or uninteresting to relicense (e.g. llvm-gcc
   and dragonegg). These will be split off from the LLVM project (e.g. to
-  separate Github projects), allowing interested people to continue their
+  separate GitHub projects), allowing interested people to continue their
   development elsewhere.
 
 To relicense LLVM, we will be seeking approval from all of the copyright holders
@@ -875,7 +875,7 @@ holds though)::
 
    Q2: If at any time after my contribution, I am able to license other patent
    claims that would have been subject to Apache's Grant of Patent License if
-   they were licenseable by me at the time of my contribution, do those other
+   they were licensable by me at the time of my contribution, do those other
    claims become subject to the Grant of Patent License?
 
    A2: Yes.
 
@@ -213,7 +213,7 @@ ELF-Dependent
 ^^^^^^^^^^^^^^^^^^^^^^
 
 In order to support creating multiple sections with the same name and comdat,
-it is possible to add an unique number at the end of the ``.seciton`` directive.
+it is possible to add an unique number at the end of the ``.section`` directive.
 For example, the following code creates two sections named ``.text``.
 
 .. code-block:: gas
 
@@ -255,7 +255,7 @@ couple specific suggestions:
 
 #. For languages with numerous rarely executed guard conditions (e.g. null
    checks, type checks, range checks) consider adding an extra execution or
-   two of LoopUnswith and LICM to your pass order.  The standard pass order,
+   two of LoopUnswitch and LICM to your pass order.  The standard pass order,
    which is tuned for C and C++ applications, may not be sufficient to remove
    all dischargeable checks from loops.
 
 
@@ -106,7 +106,7 @@ llvm-opt-fuzzer
 
 A |LLVM IR fuzzer| aimed at finding bugs in optimization passes.
 
-It receives optimzation pipeline and runs it for each fuzzer input.
+It receives optimization pipeline and runs it for each fuzzer input.
 
 Interface of this fuzzer almost directly mirrors ``llvm-isel-fuzzer``. Both
 ``mtriple`` and ``passes`` arguments are required. Passes are specified in a
 
@@ -599,7 +599,7 @@ used by people developing LLVM.
 |                         | overridden with ``LLVM_DYLIB_COMPONENTS``. The     |
 |                         | default contains most of LLVM and is defined in    |
 |                         | ``tools/llvm-shlib/CMakelists.txt``. This option is|
-|                         | not avialable on Windows.                          |
+|                         | not available on Windows.                          |
 +-------------------------+----------------------------------------------------+
 | LLVM_OPTIMIZED_TABLEGEN | Builds a release tablegen that gets used during    |
 |                         | the LLVM build. This can dramatically speed up     |
 
@@ -633,7 +633,7 @@ G_INTRINSIC, G_INTRINSIC_W_SIDE_EFFECTS
 Call an intrinsic
 
 The _W_SIDE_EFFECTS version is considered to have unknown side-effects and
-as such cannot be reordered acrosss other side-effecting instructions.
+as such cannot be reordered across other side-effecting instructions.
 
 .. note::
 
 
@@ -55,7 +55,7 @@ Allocator Support
 GWP-ASan is not a replacement for a traditional allocator. Instead, it works by
 inserting stubs into a supporting allocator to redirect allocations to GWP-ASan
 when they're chosen to be sampled. These stubs are generally implemented in the
-implementaion of ``malloc()``, ``free()`` and ``realloc()``. The stubs are
+implementation of ``malloc()``, ``free()`` and ``realloc()``. The stubs are
 extremely small, which makes using GWP-ASan in most allocators fairly trivial.
 The stubs follow the same general pattern (example ``malloc()`` pseudocode
 below):
 
@@ -22,7 +22,7 @@ on the ARMv6 and ARMv7 architectures and may be inapplicable to older chips.
    Pandaboard, have become hard-float platforms. There are a number of
    choices when using CMake. Autoconf usage is deprecated as of 3.8.
 
-   Building LLVM/Clang in ``Relese`` mode is preferred since it consumes
+   Building LLVM/Clang in ``Release`` mode is preferred since it consumes
    a lot less memory. Otherwise, the building process will very likely
    fail due to insufficient memory. It's also a lot quicker to only build
    the relevant back-ends (ARM and AArch64), since it's very unlikely that
@@ -42,7 +42,7 @@ on the ARMv6 and ARMv7 architectures and may be inapplicable to older chips.
      Use Ninja instead of Make: "-G Ninja"
      Build with assertions on: "-DLLVM_ENABLE_ASSERTIONS=True"
      Force Python2: "-DPYTHON_EXECUTABLE=/usr/bin/python2"
-     Local (non-sudo) install path: "-DCMAKE_INSTALL_PREFIX=$HOME/llvm/instal"
+     Local (non-sudo) install path: "-DCMAKE_INSTALL_PREFIX=$HOME/llvm/install"
      CPU flags: "DCMAKE_C_FLAGS=-mcpu=cortex-a15" (same for CXX_FLAGS)
 
    After that, just typing ``make -jN`` or ``ninja`` will build everything.
 
@@ -43,7 +43,7 @@ compiler-rt must be placed in the runtimes directory.
 
 ``qemu-arm`` should be available as a package for your Linux distribution.
 
-The most complicated of the prequisites to satisfy is the arm-linux-gnueabihf
+The most complicated of the prerequisites to satisfy is the arm-linux-gnueabihf
 sysroot. In theory it is possible to use the Linux distributions multiarch
 support to fulfill the dependencies for building but unfortunately due to
 /usr/local/include being added some host includes are selected. The easiest way