[llvm] NFC: fix trivial typos in documents

[kiszk]

I do not have commit rights to the repository yet. Could someone commit this change if it is OK?

llvm/docs/AMDGPU/AMDGPUAsmGFX10.rst

 
 This document describes the syntax of *core* GFX10 instructions.
 
 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>`.
 
 Instructions
 ============
 
 
 DPP16

llvm/docs/AMDGPU/AMDGPUAsmGFX7.rst

 
 This document describes the syntax of *core* GFX7 instructions.
 
 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>`.
 
 Instructions
 ============
 
 
 DS

llvm/docs/AMDGPU/AMDGPUAsmGFX8.rst

 
 This document describes the syntax of *core* GFX8 instructions.
 
 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>`.
 
 Instructions
 ============
 
 
 DS

llvm/docs/AMDGPU/AMDGPUAsmGFX9.rst

 
 This document describes the syntax of *core* GFX9 instructions.
 
 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>`.
 
 Instructions
 ============
 
 
 DS

llvm/docs/AMDGPU/AMDGPUAsmGFX900.rst

 
 For a description of other gfx900, gfx902 and gfx909 instructions see :doc:`Syntax of Core GFX9 Instructions<AMDGPUAsmGFX9>`.
 
 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>`.
 
 Instructions
 ============
 
 
 VOP3P

llvm/docs/AMDGPU/AMDGPUAsmGFX904.rst

 
 For a description of other gfx904 instructions see :doc:`Syntax of Core GFX9 Instructions<AMDGPUAsmGFX9>`.
 
 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>`.
 
 Instructions
 ============
 
 
 VOP3P

llvm/docs/AMDGPU/AMDGPUAsmGFX906.rst

 
 For a description of other gfx906 instructions see :doc:`Syntax of Core GFX9 Instructions<AMDGPUAsmGFX9>`.
 
 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>`.
 
 Instructions
 ============
 
 
 VOP2

llvm/docs/AMDGPU/AMDGPUAsmGFX908.rst

 
 For a description of other gfx908 instructions see :doc:`Syntax of Core GFX9 Instructions<AMDGPUAsmGFX9>`.
 
 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>`.
 
 Instructions
 ============
 
 
 FLAT

llvm/docs/Atomics.rst

 Libcalls: __sync_*
 ==================
 
 Some targets or OS/target combinations can support lock-free atomics, but for
 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
 instructions are not encodable. However, those instructions are available via a
 function call to a function with the longer encoding.
 
 Additionally, a few OS/target pairs provide kernel-supported lock-free
 atomics. ARM/Linux is an example of this: the kernel `provides

llvm/docs/BigEndianNEON.rst

 ==============================================
 Using ARM NEON instructions in big endian mode
 ==============================================
 
 .. contents::
     :local:
 
 Introduction
 ============
 
 Generating code for big endian ARM processors is for the most part straightforward. NEON loads and stores however have some interesting properties that make code generation decisions less obvious in big endian mode.
 
 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
 ---------------------------------------
 
 It may be helpful first to illustrate how C-level ARM NEON intrinsics are lowered to instructions.
 
 This trivial C function takes a vector of four ints and sets the zero'th lane to the value "42"::
 

llvm/docs/BlockFrequencyTerminology.rst

 represents a number just above ``0.0``.
 
 After mass is fully distributed, in any cut of the DAG that separates the exit
 nodes from the entry node, the sum of the block masses of the nodes succeeded
 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
 ==========
 
 Loop scale is a metric that indicates how many times a loop iterates per entry.
 As mass is distributed through the loop's DAG, the (otherwise ignored) backedge
 mass is collected.  This backedge mass is used to compute the exit frequency,

llvm/docs/Bugpoint.rst

 
 * In the code generator and miscompilation debuggers, ``bugpoint`` only works
   with programs that have deterministic output.  Thus, if the program outputs
   ``argv[0]``, the date, time, or any other "random" data, ``bugpoint`` may
   misinterpret differences in these data, when output, as the result of a
   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
   message, see ``-compile-command`` in :doc:`CommandGuide/bugpoint`.
 
 * In the code generator and miscompilation debuggers, debugging will go faster
   if you manually modify the program or its inputs to reduce the runtime, but
   still exhibit the problem.

llvm/docs/CMakePrimer.rst

 
 Argument Handling
 -----------------
 
 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
 list of arguments (both named and unnamed) in a list named ``ARGV``, and the
 sublist of unnamed arguments in ``ARGN``. Below is a trivial example of
 providing a wrapper function for CMake's built in function ``add_dependencies``.
 
 .. code-block:: cmake

llvm/docs/CodeGenerator.rst

bool RegMapping_Fer::compatible_class(MachineFunction &mf,
     assert(TargetRegisterInfo::isPhysicalRegister(p_reg) &&
            "Target register must be physical");
     const TargetRegisterClass *trc = mf.getRegInfo().getRegClass(v_reg);
     return trc->contains(p_reg);
   }
 
 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
 definition of the ``GR8`` register class in
 ``lib/Target/X86/X86RegisterInfo.td`` for an example of this.
 
 Virtual registers are also denoted by integer numbers. Contrary to physical
 registers, different virtual registers never share the same number. Whereas

 there are not enough registers or the callee is a thunk or vararg function,
 these register arguments can be spilled into the parameter area.  Thus, the
 parameter area must be large enough to store all the parameters for the largest
 call sequence made by the caller.  The size must also be minimally large enough
 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
 stack frame is minimally 64 bytes in 32 bit mode and 128 bytes in 64 bit mode.
 
 The *dynamic area* starts out as size zero.  If a function uses dynamic alloca
 then space is added to the stack, the linkage and parameter areas are shifted to
 top of stack, and the new space is available immediately below the linkage and

llvm/docs/CodingStandards.rst

 like ``vector``/``MapVector``/``SetVector`` if you want to iterate pointer
 keys.
 
 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
 of ``std::sort``.
 
 Style Issues
 ============
 
.. code-block:: c++
   for (Instruction &I : *BB)
     ... use I ...
 
 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++
 
   BasicBlock *BB = ...
   for (auto I = BB->begin(); I != BB->end(); ++I)
     ... use I ...
 

llvm/docs/CommandGuide/lit.rst

  Run the tests in a random order.
 
 .. option:: --num-shards=M
 
  Divide the set of selected tests into ``M`` equal-sized subsets or
  "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).
 
 .. option:: --run-shard=N
 
  Select which shard to run, assuming the ``--num-shards=M`` option was
  provided. The two options must be used together, and the value of ``N``
  must be in the range ``1..M``. The environment variable

llvm/docs/CommandGuide/tblgen.rst

  Generate disassembler.
 
 .. option:: -gen-pseudo-lowering
 
  Generate pseudo instruction lowering.
 
 .. option:: -gen-dag-isel
 
- Generate a DAG (Directed Acycle Graph) instruction selector.
+ Generate a DAG (Directed Acyclic Graph) instruction selector.
 
 .. option:: -gen-asm-matcher
 
  Generate assembly instruction matcher.
 
 .. option:: -gen-dfa-packetizer
 
  Generate DFA Packetizer for VLIW targets.

llvm/docs/CompileCudaWithLLVM.rst

 
 * `Aggressive speculative execution
   <http://llvm.org/docs/doxygen/html/SpeculativeExecution_8cpp_source.html>`_
   -- This is mainly for promoting straight-line scalar optimizations, which are
   most effective on code along dominator paths.
 
 * `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
   annotated with their address space, so it's up to LLVM to infer it where
   possible.
 
 * `Bypassing 64-bit divides
   <http://llvm.org/docs/doxygen/html/BypassSlowDivision_8cpp_source.html>`_ --
   This was an existing optimization that we enabled for the PTX backend.
 
   64-bit integer divides are much slower than 32-bit ones on NVIDIA GPUs.
   Many of the 64-bit divides in our benchmarks have a divisor and dividend
   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
   SROA, which sometimes speed up code by over 10x.
 
   (Programmers can force unrolling and inline using clang's `loop unrolling pragmas
   <http://clang.llvm.org/docs/AttributeReference.html#pragma-unroll-pragma-nounroll>`_
   and ``__attribute__((always_inline))``.)

llvm/docs/CoverageMappingFormat.rst

 .. role:: raw-html(raw)
    :format: html
 
 =================================
 LLVM Code Coverage Mapping Format
 =================================
 
 .. contents::
    :local:
 
 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
 code coverage analysis for their own programs, and for those who would like
 to know how it works under the hood. A prior knowledge of how Clang's profile
 guided optimization works is useful, but not required.
 
 We start by showing how to use LLVM and Clang for code coverage analysis,

llvm/docs/DependenceGraphs/index.rst

 Implementation Details
 ======================
 
 The current implementation of DDG differs slightly from the dependence
 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
 ----------
 .. [1] "D. J. Kuck, R. H. Kuhn, D. A. Padua, B. Leasure, and M. Wolfe (1981). DEPENDENCE GRAPHS AND COMPILER OPTIMIZATIONS."
 .. [2] "J. FERRANTE (IBM), K. J. OTTENSTEIN (Michigan Technological University) and JOE D. WARREN (Rice University), 1987. The Program Dependence Graph and Its Use in Optimization."

llvm/docs/DeveloperPolicy.rst

 #. Multiple violations of these policies or a single egregious violation may
    cause commit access to be revoked.
 
 In any case, your changes are still subject to `code review`_ (either before or
 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:[e-mail]>`_ with your
 SVN username and GitHub username.
 
 .. _discuss the change/gather consensus:
 
 Making a Major Change
 ---------------------

 project, including the main LLVM repository, runtime libraries (compiler_rt,
 OpenMP, etc), Polly, and all other subprojects.  There are a few exceptions:
 
 * Code imported from other projects (e.g. Google Test, Autoconf, etc) will
   remain as it is.  This code isn't developed as part of the LLVM project, it
   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
 of code in the repository, or potentially remove/rewrite code if we cannot.
 This is a large
 and challenging project which will take a significant amount of time to
 complete.  In the interim, **all contributions to the project will be made under
 the terms of both the new license and the legacy license scheme** (each of which
holds though)::
    to Apache's Grant of Patent License, is there a way any of those claims would
    later become subject to the Grant of Patent License solely due to subsequent
    contributions by other parties who are not licensees of that patent.
 
    A1: No.
 
    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.
 
    Q3: If I own or control a licensable patent and contribute code to a specific
    Apache product, which of my patent claims are subject to Apache's Grant of
    Patent License?
 

llvm/docs/Extensions.rst

 
 ELF-Dependent
 -------------
 
 ``.section`` Directive
 ^^^^^^^^^^^^^^^^^^^^^^
 
 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
 
   .section  .text,"ax",@progbits,unique,1
         nop
 
   .section  .text,"ax",@progbits,unique,2

llvm/docs/Frontend/PerformanceTips.rst

 use the existing -O2 or -O3 pass pipelines as is.  These pass pipelines make a
 good starting point for an optimizing compiler for any language, but they have
 been carefully tuned for C and C++, not your target language.  You will almost
 certainly need to use a custom pass order to achieve optimal performance.  A
 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.
 
 #. If you language uses range checks, consider using the IRCE pass.  It is not
    currently part of the standard pass order.
 
 #. A useful sanity check to run is to run your optimized IR back through the
    -O2 pipeline again.  If you see noticeable improvement in the resulting IR,

llvm/docs/FuzzingLLVM.rst

.. code-block:: shell
 
    % bin/llvm-isel-fuzzer--aarch64-O0-gisel <corpus-dir>
 
 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
 format suitable for the new pass manager. You can find some documentation about
 this format in the doxygen for ``PassBuilder::parsePassPipeline``.
 
 .. code-block:: shell
 

llvm/docs/GettingStarted.rst

 |                         | slow and generates a lot of output. Sphinx version |
 |                         | 1.5 or later recommended.                          |
 +-------------------------+----------------------------------------------------+
 | LLVM_BUILD_LLVM_DYLIB   | Generate libLLVM.so. This library contains a       |
 |                         | default set of LLVM components that can be         |
 |                         | 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     |
 |                         | debug builds.                                      |
 +-------------------------+----------------------------------------------------+
 
 To configure LLVM, follow these steps:
 

llvm/docs/GlobalISel/GenericOpcode.rst

.. caution::
   I found no documentation for this instruction at the time of writing.
 
 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::
 
   Unlike SelectionDAG, there is no _VOID variant. Both of these are permitted
   to have zero, one, or multiple results.
 
 Variadic Arguments
 ------------------

llvm/docs/GwpAsan.rst

 support compiler-rt as the reference implementation.
 
 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):
 
 .. code:: cpp
 
   #ifdef INSTALL_GWP_ASAN_STUBS
     gwp_asan::GuardedPoolAllocator GWPASanAllocator;

llvm/docs/HowToBuildOnARM.rst

 Here are some notes on building/testing LLVM/Clang on ARM. Note that
 ARM encompasses a wide variety of CPUs; this advice is primarily based
 on the ARMv6 and ARMv7 architectures and may be inapplicable to older chips.
 
 #. The most popular Linaro/Ubuntu OS's for ARM boards, e.g., the
    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
    you'll use an ARM board to cross-compile to other arches. If you're
    running Compiler-RT tests, also include the x86 back-end, or some tests
    will fail.
 
    .. code-block:: bash
 
      cmake $LLVM_SRC_DIR -DCMAKE_BUILD_TYPE=Release \
                          -DLLVM_TARGETS_TO_BUILD="ARM;X86;AArch64"
 
    Other options you can use are:
 
    .. code-block:: bash
 
      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.
    ``make -jN check-all`` or ``ninja check-all`` will run all compiler tests. For
    running the test suite, please refer to :doc:`TestingGuide`.
 
 #. If you are building LLVM/Clang on an ARM board with 1G of memory or less,
    please use ``gold`` rather then GNU ``ld``. In any case it is probably a good

llvm/docs/HowToCrossCompileBuiltinsOnArm.rst

 See https://llvm.org/docs/GettingStarted.html for information about obtaining
 the source for LLVM and compiler-rt. Note that the getting started guide
 places compiler-rt in the projects subdirectory, but this is not essential and
 if you are using the BaremetalARM.cmake cache for v6-M, v7-M and v7-EM then
 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
 to supply a sysroot is to download the arm-linux-gnueabihf toolchain. This can
 be found at:
 * https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads for gcc 8 and above
 * https://releases.linaro.org/components/toolchain/binaries/ for gcc 4.9 to 7.3
 

llvm/docs/LangRef.rst

 
 A ``llvm.dbg.addr`` or ``llvm.dbg.declare`` intrinsic describes an indirect
 value (the address) of a source variable. The first operand of the intrinsic
 must be an address of some kind. A DIExpression attached to the intrinsic
 refines this address to produce a concrete location for the source variable.
 
 A ``llvm.dbg.value`` intrinsic describes the direct value of a source variable.
 The first operand of the intrinsic may be a direct or indirect value. A
-DIExpresion attached to the intrinsic refines the first operand to produce a
+DIExpression attached to the intrinsic refines the first operand to produce a
 direct value. For example, if the first operand is an indirect value, it may be
-necessary to insert ``DW_OP_deref`` into the DIExpresion in order to produce a
+necessary to insert ``DW_OP_deref`` into the DIExpression in order to produce a
 valid debug intrinsic.
 
 .. note::
 
    A DIExpression is interpreted in the same way regardless of which kind of
    debug intrinsic it's attached to.
 
 .. code-block:: text

 with language extensions which allow source files to explicitly declare the
 libraries they depend on, and have these automatically be transmitted to the
 linker via object files.
 
 The list is encoded in the IR using named metadata with the name
 ``!llvm.dependent-libraries``. Each operand is expected to be a metadata node
 which should contain a single string operand.
 
-For example, the following metadata section contains two library specfiers::
+For example, the following metadata section contains two library specifiers::
 
     !0 = !{!"a library specifier"}
     !1 = !{!"another library specifier"}
     !llvm.dependent-libraries = !{ !0, !1 }
 
 Each library specifier will be handled independently by the consuming linker.
 The effect of the library specifiers are defined by the consuming linker.
 

 ::
 
       declare <16 x float>  @llvm.masked.expandload.v16f32 (float* <ptr>, <16 x i1> <mask>, <16 x float> <passthru>)
       declare <2 x i64>     @llvm.masked.expandload.v2i64 (i64* <ptr>, <2 x i1>  <mask>, <2 x i64> <passthru>)
 
 Overview:
 """""""""
 
-Reads a number of scalar values sequentially from memory location provided in '``ptr``' and spreads them in a vector. The '``mask``' holds a bit for each vector lane. The number of elements read from memory is equal to the number of '1' bits in the mask. The loaded elements are positioned in the destination vector according to the sequence of '1' and '0' bits in the mask. E.g., if the mask vector is '10010001', "explandload" reads 3 values from memory addresses ptr, ptr+1, ptr+2 and places them in lanes 0, 3 and 7 accordingly. The masked-off lanes are filled by elements from the corresponding lanes of the '``passthru``' operand.
+Reads a number of scalar values sequentially from memory location provided in '``ptr``' and spreads them in a vector. The '``mask``' holds a bit for each vector lane. The number of elements read from memory is equal to the number of '1' bits in the mask. The loaded elements are positioned in the destination vector according to the sequence of '1' and '0' bits in the mask. E.g., if the mask vector is '10010001', "expandload" reads 3 values from memory addresses ptr, ptr+1, ptr+2 and places them in lanes 0, 3 and 7 accordingly. The masked-off lanes are filled by elements from the corresponding lanes of the '``passthru``' operand.
 
 
 Arguments:
 """"""""""
 
 The first operand is the base pointer for the load. It has the same underlying type as the element of the returned vector. The second operand, mask, is a vector of boolean values with the same number of elements as the return type. The third is a pass-through value that is used to fill the masked-off lanes of the result. The return type and the type of the '``passthru``' operand have the same vector type.
 
 Semantics:

llvm/docs/LibFuzzer.rst

 ``-max_total_time``
   If positive, indicates the maximum total time in seconds to run the fuzzer.
   If 0 (the default), run indefinitely.
 ``-merge``
   If set to 1, any corpus inputs from the 2nd, 3rd etc. corpus directories
   that trigger new code coverage will be merged into the first corpus
   directory.  Defaults to 0. This flag can be used to minimize a corpus.
 ``-merge_control_file``
-  Specify a control file used for the merge proccess.
+  Specify a control file used for the merge process.
   If a merge process gets killed it tries to leave this file in a state
   suitable for resuming the merge. By default a temporary file will be used.
 ``-minimize_crash``
   If 1, minimizes the provided crash input.
   Use with -runs=N or -max_total_time=N to limit the number of attempts.
 ``-reload``
   If set to 1 (the default), the corpus directory is re-read periodically to
   check for new inputs; this allows detection of new inputs that were discovered

 Value Profile
 -------------
 
 With  ``-fsanitize-coverage=trace-cmp`` (default with ``-fsanitize=fuzzer``)
 and extra run-time flag ``-use_value_profile=1`` the fuzzer will
 collect value profiles for the parameters of compare instructions
 and treat some new values as new coverage.
 
-The current imlpementation does roughly the following:
+The current implementation does roughly the following:
 
 * The compiler instruments all CMP instructions with a callback that receives both CMP arguments.
 * The callback computes `(caller_pc&4095) | (popcnt(Arg1 ^ Arg2) << 12)` and uses this value to set a bit in a bitset.
 * Every new observed bit in the bitset is treated as new coverage.
 
 
 This feature has a potential to discover many interesting inputs,
 but there are two downsides.

llvm/docs/MarkedUpDisassembly.rst

 Instruction Annotations
 =======================
 
 .. _contextual markups:
 
 Contextual markups
 ------------------
 
-Annoated assembly display will supply contextual markup to help clients more
+Annotated assembly display will supply contextual markup to help clients more
 efficiently implement things like pretty printers. Most markup will be target
 independent, so clients can effectively provide good display without any target
 specific knowledge.
 
 Annotated assembly goes through the normal instruction printer, but optionally
 includes contextual tags on portions of the instruction string. An annotation
 is any '<' '>' delimited section of text(1).
 

llvm/docs/MemTagSanitizer.rst

 will only work when targeting AArch64 with MemTag extension. One
 possible way to achieve that is to add ``-target
 aarch64-linux -march=armv8+memtag`` to compilation flags.
 
 Implementation
 ==============
 
 See `HardwareAssistedAddressSanitizer`_ for a general overview of a
-tag-based approach to memory safety.  MemTagSanitizer followes a
+tag-based approach to memory safety.  MemTagSanitizer follows a
 similar implementation strategy, but with the tag storage (shadow)
 provided by the hardware.
 
 A quick overview of MTE hardware capabilities:
 
 * Every 16 aligned bytes of memory can be assigned a 4-bit Allocation Tag.
 * Every pointer can have a 4-bit Address Tag that is in its most significant byte.
 * Most memory access instructions generate an exception if Address Tag != Allocation Tag.

llvm/docs/ORCv2.rst

if (!EntrySym)
     return EntrySym.takeError();
 
   // Cast the entry point address to a function pointer.
   auto *Entry = (void(*)())EntrySym.getAddress();
 
   // Call into JIT'd code.
   Entry();
 
-The builder clasess provide a number of configuration options that can be
+The builder classes provide a number of configuration options that can be
 specified before the JIT instance is constructed. For example:
 
 .. code-block:: c++
 
   // Build an LLLazyJIT instance that uses four worker threads for compilation,
   // and jumps to a specific error handler (rather than null) on lazy compile
   // failures.
 
1. ORCv2 fully adopts the JIT-as-linker model that began with MCJIT. Modules
      (and other program representations, e.g. Object Files)  are no longer added
      directly to JIT classes or layers. Instead, they are added to ``JITDylib``
      instances *by* layers. The ``JITDylib`` determines *where* the definitions
      reside, the layers determine *how* the definitions will be compiled.
      Linkage relationships between ``JITDylibs`` determine how inter-module
      references are resolved, and symbol resolvers are no longer used. See the
      section `Design Overview`_ for more details.
 
-     Unless multiple JITDylibs are needed to model linkage relationsips, ORCv1
+     Unless multiple JITDylibs are needed to model linkage relationships, ORCv1
      clients should place all code in the main JITDylib (returned by
      ``ExecutionSession::getMainJITDylib()``). MCJIT clients should use LLJIT
      (see `LLJIT and LLLazyJIT`_).
 
   2. All JIT stacks now need an ``ExecutionSession`` instance. ExecutionSession
      manages the string pool, error reporting, synchronization, and symbol
      lookup.
 

llvm/docs/ProgrammersManual.rst

 Note that LLVM's support for multithreading is still relatively young.  Up
 through version 2.5, the execution of threaded hosted applications was
 supported, but not threaded client access to the APIs.  While this use case is
 now supported, clients *must* adhere to the guidelines specified below to ensure
 proper operation in multithreaded mode.
 
 Note that, on Unix-like platforms, LLVM requires the presence of GCC's atomic
 intrinsics in order to support threaded operation.  If you need a
-multhreading-capable LLVM on a platform without a suitably modern system
+multithreading-capable LLVM on a platform without a suitably modern system
 compiler, consider compiling LLVM and LLVM-GCC in single-threaded mode, and
 using the resultant compiler to build a copy of LLVM with multithreading
 support.
 
 .. _shutdown:
 
 Ending Execution with ``llvm_shutdown()``
 -----------------------------------------

 For layout b) instead of the ``User`` we find a pointer (``User*`` with LSBit
 set).  Following this pointer brings us to the ``User``.  A portable trick
 ensures that the first bytes of ``User`` (if interpreted as a pointer) never has
 the LSBit set. (Portability is relying on the fact that all known compilers
 place the ``vptr`` in the first word of the instances.)
 
 .. _polymorphism:
 
-Designing Type Hiercharies and Polymorphic Interfaces
+Designing Type Hierarchies and Polymorphic Interfaces
 -----------------------------------------------------
 
 There are two different design patterns that tend to result in the use of
 virtual dispatch for methods in a type hierarchy in C++ programs. The first is
 a genuine type hierarchy where different types in the hierarchy model
 a specific subset of the functionality and semantics, and these types nest
 strictly within each other. Good examples of this can be seen in the ``Value``
 or ``Type`` type hierarchies.
#. `Inheritance Is The Base Class of Evil
    <http://channel9.msdn.com/Events/GoingNative/2013/Inheritance-Is-The-Base-Class-of-Evil>`_
    - The GoingNative 2013 talk describing this technique, and probably the best
    place to start.
 #. `Value Semantics and Concepts-based Polymorphism
    <http://www.youtube.com/watch?v=_BpMYeUFXv8>`_ - The C++Now! 2012 talk
    describing this technique in more detail.
 #. `Sean Parent's Papers and Presentations
    <http://github.com/sean-parent/sean-parent.github.com/wiki/Papers-and-Presentations>`_
-   - A Github project full of links to slides, video, and sometimes code.
+   - A GitHub project full of links to slides, video, and sometimes code.
 
 When deciding between creating a type hierarchy (with either tagged or virtual
 dispatch) and using templates or concepts-based polymorphism, consider whether
 there is some refinement of an abstract base class which is a semantically
 meaningful type on an interface boundary. If anything more refined than the
 root abstract interface is meaningless to talk about as a partial extension of
 the semantic model, then your use case likely fits better with polymorphism and
 you should avoid using virtual dispatch. However, there may be some exigent

 
 The Core LLVM Class Hierarchy Reference
 =======================================
 
 ``#include "llvm/IR/Type.h"``
 
 header source: `Type.h <http://llvm.org/doxygen/Type_8h_source.html>`_
 
-doxygen info: `Type Clases <http://llvm.org/doxygen/classllvm_1_1Type.html>`_
+doxygen info: `Type Classes <http://llvm.org/doxygen/classllvm_1_1Type.html>`_
 
 The Core LLVM classes are the primary means of representing the program being
 inspected or transformed.  The core LLVM classes are defined in header files in
 the ``include/llvm/IR`` directory, and implemented in the ``lib/IR``
 directory. It's worth noting that, for historical reasons, this library is
 called ``libLLVMCore.so``, not ``libLLVMIR.so`` as you might expect.
 
 .. _Type:

llvm/docs/Proposals/GitHubMove.rst

 
 Step #4 : Post Move
 -------------------
 
 13. Archive the SVN repository.
 14. Update links on the LLVM website pointing to viewvc/klaus/phab etc. to
     point to GitHub instead.
 
-Github Repository Description
+GitHub Repository Description
 =============================
 
 Monorepo
 ----------------
 
 The LLVM git repository hosted at https://github.com/llvm/llvm-project contains all
-sub-projects in a single source tree.  It is often refered to as a monorepo and
+sub-projects in a single source tree.  It is often referred to as a monorepo and
 mimics an export of the current SVN repository, with each sub-project having its
 own top-level directory. Not all sub-projects are used for building toolchains.
 For example, www/ and test-suite/ are not part of the monorepo.
 
 Putting all sub-projects in a single checkout makes cross-project refactoring
 naturally simple:
 
  * New sub-projects can be trivially split out for better reuse and/or layering

 ------------------
 
  * Using the monolithic repository may add overhead for those contributing to a
    standalone sub-project, particularly on runtimes like libcxx and compiler-rt
    that don't rely on LLVM; currently, a fresh clone of libcxx is only 15MB (vs.
    1GB for the monorepo), and the commit rate of LLVM may cause more frequent
    `git push` collisions when upstreaming. Affected contributors may be able to
    use the SVN bridge or the single-subproject Git mirrors. However, it's
-   undecided if these projects will continue to be mantained.
+   undecided if these projects will continue to be maintained.
  * Using the monolithic repository may add overhead for those *integrating* a
    standalone sub-project, even if they aren't contributing to it, due to the
    same disk space concern as the point above. The availability of the
    sub-project Git mirrors would addresses this.
  * Preservation of the existing read/write SVN-based workflows relies on the
    GitHub SVN bridge, which is an extra dependency. Maintaining this locks us
    into GitHub and could restrict future workflow changes.
 
directories using a Git sparse checkout::
   git read-tree -mu HEAD
 
 The data for all sub-projects is still in your `.git` directory, but in your
 checkout, you only see `compiler-rt`.
 Before you push, you'll need to fetch and rebase (`git pull --rebase`) as
 usual.
 
 Note that when you fetch you'll likely pull in changes to sub-projects you don't
-care about. If you are using spasre checkout, the files from other projects
+care about. If you are using sparse checkout, the files from other projects
 won't appear on your disk. The only effect is that your commit hash changes.
 
 You can check whether the changes in the last fetch are relevant to your commit
 by running::
 
   git log origin/master@{1}..origin/master -- libcxx
 
 This command can be hidden in a script so that `git llvmpush` would perform all

 monorepo and all components are unified by a giant octopus merge.
 
 If additional active local branches need to be preserved, the above
 operations following the assignment to ``my_local_branch`` should be
 done for each branch.  Ref paths will need to be updated to map the
 local branch to the corresponding upstream branch.  If local branches
 have no corresponding upstream branch, then the creation of
 ``local/octopus/<local branch>`` need not use ``git-merge-base`` to
-pinpont its root commit; it may simply be branched from the
+pinpoint its root commit; it may simply be branched from the
 appropriate component branch (say, ``llvm/local_release_X``).
 
 Zipping local history
 ---------------------
 
 The octopus merge is suboptimal for many cases, because walking back
 through the history of one component leaves the other components fixed
 at a history that likely makes things unbuildable.

 discarded and any local tags would then be migrated manually.
 
 **Example 2: Nested sources layout**
 
 The tool handles nested submodules (e.g. llvm is a submodule in
 umbrella and clang is a submodule in llvm).  The file
 ``submodule-map.txt`` is a list of pairs, one per line.  The first
 pair item describes the path to a submodule in the umbrella
-repository.  The second pair item secribes the path where trees for
+repository.  The second pair item describes the path where trees for
 that submodule should be written in the zipped history.  
 
 Let's say your umbrella repository is actually the llvm repository and
 it has submodules in the "nested sources" layout (clang in
 tools/clang, etc.).  Let's also say ``projects/myproj`` is a submodule
 pointing to some downstream repository.  The submodule map file should
 look like this (we still want myproj mapped the same way as
 previously)::
(
     import-downstream-repo.py \
       refs/remotes/myrepo \
       ${my_local_tags[@]} \
       --new-repo-prefix=refs/remotes/upstream/monorepo \
       --subdir=myrepo \
       --tag-prefix="myrepo-"
    )
 
-   # Preserve release braches.
+   # Preserve release branches.
    for ref in $(git -C my-monorepo for-each-ref --format="%(refname)" \
                   refs/remotes/myrepo/release); do
      branch=${ref#refs/remotes/myrepo/}
      git -C my-monorepo branch --no-track myrepo/${branch} ${ref}
    done
 
    # Preserve master.
    git -C my-monorepo branch --no-track myrepo/master refs/remotes/myrepo/master

llvm/docs/Proposals/TestSuite.rst

 =====================
-Test-Suite Extentions
+Test-Suite Extensions
 =====================
 
 .. contents::
    :depth: 1
    :local:
 
 Abstract
 ========

 RAJA Performance Suite
 ----------------------
 https://github.com/LLNL/RAJAPerf
 
 CORAL-2 Benchmarks
 ------------------
 https://asc.llnl.gov/coral-2-benchmarks/
 
-Many of its programs have already been integreated in
+Many of its programs have already been integrated in
 MultiSource/Benchmarks/DOE-ProxyApps-C and
 MultiSource/Benchmarks/DOE-ProxyApps-C++.
 
  * Nekbone
  * QMCPack
  * LAMMPS
  * Kripke
  * Quicksilver

llvm/docs/Proposals/VariableNames.rst

 TargetInstrInfo              tii
 TargetLibraryInfo            tli
 TargetRegisterInfo           tri
 ============================ =============
 
 In some cases renaming acronyms to the full type name will result in overly
 verbose code. Unlike most classes, a variable's scope is limited and therefore
 some of its purpose can implied from that scope, meaning that fewer words are
-necessary to give it a clear name. For example, in an optization pass the reader
+necessary to give it a clear name. For example, in an optimization pass the reader
 can assume that a variable's purpose relates to optimization and therefore an
 ``OptimizationRemarkEmitter`` variable could be given the name ``remarkEmitter``
 or even ``remarker``.
 
 The following is a list of longer class names and the associated shorter
 variable name.
 
 ========================= =============

llvm/docs/ReleaseProcess.rst

* Compare the results, report all errors on Bugzilla and publish the binary blob
   where the release manager can grab it.
 
 Once the release manages announces that the latest candidate is the good one,
 you have to pack the ``Release`` (no Asserts) install directory on ``Phase3``
 and that will be the official binary.
 
 * Rename (or link) ``clang+llvm-REL-ARCH-ENV`` to the .install directory
 
-* Tar that into the same name with ``.tar.gz`` extensioan from outside the
+* Tar that into the same name with ``.tar.gz`` extension from outside the
   directory
 
 * Make it available for the release manager to download
 
 .. _bug-reporting:
 
 Bug Reporting Process
 =====================

llvm/docs/ReportingGuide.rst

 Once we've determined our response, we will separately contact the original
 reporter and other individuals to let them know what actions (if any) we'll be
 taking. We will take into account feedback from the individuals involved on the
 appropriateness of our response, but we don't guarantee we'll act on it.
 
 After any incident, the advisory committee will make a report on the situation
 to the LLVM Foundation board. The board may choose to make a public statement
 about the incident. If that's the case, the identities of anyone involved will
-remain confidential unless instructed by those inviduals otherwise.
+remain confidential unless instructed by those individuals otherwise.
 
 Appealing
 =========
 
 Only permanent resolutions (such as bans) or requests for public actions may be
 appealed. To appeal a decision of the working group, contact the LLVM
 Foundation board at [e-mail] with your appeal and the board will review
 the case.
 
 In general, it is **not** appropriate to appeal a particular decision on
 a public mailing list. Doing so would involve disclosure of information which
-whould be confidential. Disclosing this kind of information publicly may be
+would be confidential. Disclosing this kind of information publicly may be
 considered a separate and (potentially) more serious violation of the Code of
 Conduct. This is not meant to limit discussion of the Code of Conduct, the
 advisory board itself, or the appropriateness of responses in general, but
 **please** refrain from mentioning specific facts about cases without the
 explicit permission of all parties involved.
 
 .. _members:
 

llvm/docs/SourceLevelDebugging.rst

 
 .. code-block:: c
 
   class foo {
    public:
      foo(const foo&) = deleted;
   };
 
-A C++ frontend would generate follwing:
+A C++ frontend would generate following:
 
 .. code-block:: text
 
   !17 = !DISubprogram(name: "foo", scope: !11, file: !1, line: 5, type: !18, scopeLine: 5, flags: DIFlagPublic | DIFlagPrototyped, spFlags: DISPFlagDeleted)
 
-and this will produce an additional DWARF attibute as:
+and this will produce an additional DWARF attribute as:
 
 .. code-block:: text
 
   DW_TAG_subprogram [7] *
     DW_AT_name [DW_FORM_strx1]    (indexed (00000006) string = "foo")
     DW_AT_decl_line [DW_FORM_data1]       (5)
     ...
     DW_AT_deleted [DW_FORM_flag_present]  (true)

 
 The most straightforward way to use ``debugify`` is as follows::
 
   $ opt -debugify -pass-to-test -check-debugify sample.ll
 
 This will inject synthetic DI to ``sample.ll`` run the ``pass-to-test``
 and then check for missing DI.
 
-Some other ways to run debugify are avaliable:
+Some other ways to run debugify are available:
 
 .. code-block:: bash
 
    # Same as the above example.
    $ opt -enable-debugify -pass-to-test sample.ll
 
    # Suppresses verbose debugify output.
    $ opt -enable-debugify -debugify-quiet -pass-to-test sample.ll

llvm/docs/TableGen/LangRef.rst

 
 A ``class`` declaration creates a record which other records can inherit
 from. A class can be parametrized by a list of "template arguments", whose
 values can be used in the class body.
 
 A given class can only be defined once. A ``class`` declaration is
 considered to define the class if any of the following is true:
 
-.. break ObjectBody into its consituents so that they are present here?
+.. break ObjectBody into its constituents so that they are present here?
 
 #. The :token:`TemplateArgList` is present.
 #. The :token:`Body` in the :token:`ObjectBody` is present and is not empty.
 #. The :token:`BaseClassList` in the :token:`ObjectBody` is present.
 
 You can declare an empty class by giving an empty :token:`TemplateArgList`
 and an empty :token:`ObjectBody`. This can serve as a restricted form of
 forward declaration: note that records deriving from the forward-declared

llvm/docs/TransformMetadata.rst

 loop versioning is required. If undefined, the fallback loop inherits
 all attributes from the original loop.
 
 Attributes defined in ``llvm.loop.distribute.followup_all`` are added to
 all of the aforementioned output loops.
 
 It is recommended to add ``llvm.loop.disable_nonforced`` to
 ``llvm.loop.distribute.followup_fallback``. This avoids that the
-fallback version (which is likely never executed) is further optimzed
+fallback version (which is likely never executed) is further optimized
 which would increase the code size.
 
 Versioning LICM
 ---------------
 
 The pass hoists code out of loops that are only loop-invariant when
 dynamic conditions apply. For instance, it transforms the loop
 

llvm/docs/XRayFDRFormat.rst

 
 General
 =======
 
 Each trace file corresponds to a sequence of events in a particular thread.
 
 The file has a header followed by a sequence of discriminated record types.
 
-The endianness of byte fields matches the endianess of the platform which
+The endianness of byte fields matches the endianness of the platform which
 produced the trace file.
 
 
 Header Section
 ==============
 
 A trace file begins with a 32 byte header.
 

llvm/docs/YamlIO.rst

 
 Tags
 ----
 
 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 different 
+tag on a map. Using this functionality it is even possible to support different 
 mappings, as long as they are convertible.  
 
 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
 ----------
 

llvm/docs/tutorial/BuildingAJIT1.rst

 reference to the ExecutionSession, (2) A reference to our object layer, and (3)
 a compiler instance to use to perform the actual compilation from IR to object
 files. We use the off-the-shelf ConcurrentIRCompiler utility as our compiler,
 which we construct using this constructor's JITTargetMachineBuilder argument.
 The ConcurrentIRCompiler utility will use the JITTargetMachineBuilder to build
 llvm TargetMachines (which are not thread safe) as needed for compiles. After
 this, we initialize our supporting members: ``DL``, ``Mangler`` and ``Ctx`` with
 the input DataLayout, the ExecutionSession and DL member, and a new default
-constucted LLVMContext respectively. Now that our members have been initialized,
+constructed LLVMContext respectively. Now that our members have been initialized,
 so the one thing that remains to do is to tweak the configuration of the
 *JITDylib* that we will store our code in. We want to modify this dylib to
 contain not only the symbols that we add to it, but also the symbols from our
 REPL process as well. We do this by attaching a
 ``DynamicLibrarySearchGenerator`` instance using the
 ``DynamicLibrarySearchGenerator::GetForCurrentProcess`` method.
 
 
.. code-block:: c++
   }
 
   const DataLayout &getDataLayout() const { return DL; }
 
   LLVMContext &getContext() { return *Ctx.getContext(); }
 
 Next we have a named constructor, ``Create``, which will build a KaleidoscopeJIT
 instance that is configured to generate code for our host process. It does this
-by first generating a JITTargetMachineBuilder instance using that clases's
+by first generating a JITTargetMachineBuilder instance using that classes'
 detectHost method and then using that instance to generate a datalayout for
 the target process. Each of these operations can fail, so each returns its
 result wrapped in an Expected value [3]_ that we must check for error before
 continuing. If both operations succeed we can unwrap their results (using the
 dereference operator) and pass them into KaleidoscopeJIT's constructor on the
 last line of the function.
 
 Following the named constructor we have the ``getDataLayout()`` and
.. [2] +-----------------------------+-----------------------------------------------+
        |   SectionMemoryManager.h    | Provides the SectionMemoryManager class.      |
        +-----------------------------+-----------------------------------------------+
        |        DataLayout.h         | Provides the DataLayout class.                |
        +-----------------------------+-----------------------------------------------+
        |        LLVMContext.h        | Provides the LLVMContext class.               |
        +-----------------------------+-----------------------------------------------+
 
 .. [3] See the ErrorHandling section in the LLVM Programmer's Manual
-       (http://llvm.org/docs/ProgrammersManual.html#error-handling)
+       (http://llvm.org/docs/ProgrammersManual.html#error-handling)
 

llvm/docs/tutorial/BuildingAJIT2.rst

public:
 
     void emit(MaterializationResponsibility R, ThreadSafeModule TSM) override;
 
   private:
     IRLayer &BaseLayer;
     TransformFunction Transform;
   };
 
-  // From IRTransfomrLayer.cpp:
+  // From IRTransformLayer.cpp:
 
   IRTransformLayer::IRTransformLayer(ExecutionSession &ES,
                                      IRLayer &BaseLayer,
                                      TransformFunction Transform)
       : IRLayer(ES), BaseLayer(BaseLayer), Transform(std::move(Transform)) {}
 
   void IRTransformLayer::emit(MaterializationResponsibility R,
                               ThreadSafeModule TSM) {

llvm/docs/tutorial/OCamlLangImpl3.rst

.. code-block:: ocaml
 
     let context = global_context ()
     let the_module = create_module context "my cool jit"
     let builder = builder context
     let named_values:(string, llvalue) Hashtbl.t = Hashtbl.create 10
     let double_type = double_type context
 
 The static variables will be used during code generation.
-``Codgen.the_module`` is the LLVM construct that contains all of the
+``Codegen.the_module`` is the LLVM construct that contains all of the
 functions and global variables in a chunk of code. In many ways, it is
 the top-level structure that the LLVM IR uses to contain code.
 
 The ``Codegen.builder`` object is a helper object that makes it easy to
 generate LLVM instructions. Instances of the
 `IRBuilder <http://llvm.org/doxygen/IRBuilder_8h-source.html>`_
 class keep track of the current place to insert instructions and has
 methods to create new instructions.
 
 The ``Codegen.named_values`` map keeps track of which values are defined
 in the current scope and what their LLVM representation is. (In other
 words, it is a symbol table for the code). In this form of Kaleidoscope,
 the only things that can be referenced are function parameters. As such,
 function parameters will be in this map when generating code for their
 function body.
 
 With these basics in place, we can start talking about how to generate
 code for each expression. Note that this assumes that the
-``Codgen.builder`` has been set up to generate code *into* something.
+``Codegen.builder`` has been set up to generate code *into* something.
 For now, we'll assume that this has already been done, and we'll just
 use it to emit code.
 
 Expression Code Generation
 ==========================
 
 Generating LLVM code for expression nodes is very straightforward: less
 than 30 lines of commented code for all four of our expression nodes.