[docs] Fix typos

docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst

@@ -96,7 +96,7 @@ compiler [:ref:`GCC <amdgpu-dwarf-GCC>`] and the Perforce TotalView HPC debugger
 [:ref:`Perforce-TotalView <amdgpu-dwarf-Perforce-TotalView>`].
 
 However, the extensions are intended to be vendor and architecture neutral. They
-are believed to apply to other heterogenous hardware devices including GPUs,
+are believed to apply to other heterogeneous hardware devices including GPUs,
 DSPs, FPGAs, and other specialized hardware. These collectively include similar
 characteristics and requirements as AMDGPU devices. Some of the extension can
 also apply to traditional CPU hardware that supports large vector registers.
@@ -2068,7 +2068,7 @@ register starting at the specified bit offset.
 
     *An implementation may evaluate the call frame information immediately, or
     may defer evaluation until L is accessed by an operation. If evaluation is
-    defered, R and the current context can be recorded in L. When accessed, the
+    deferred, R and the current context can be recorded in L. When accessed, the
     recorded context is used to evaluate the call frame information, not the
     current context of the access operation.*
 

docs/AMDGPUUsage.rst

@@ -1139,7 +1139,7 @@ The loaded code object path URI syntax is defined by the following BNF syntax:
 **file_path**
   Is the file's path specified as a URI encoded UTF-8 string. In URI encoding,
   every character that is not in the regular expression ``[a-zA-Z0-9/_.~-]`` is
-  encoded as two uppercase hexidecimal digits proceeded by "%".  Directories in
+  encoded as two uppercase hexadecimal digits proceeded by "%".  Directories in
   the path are separated by "/".
 
 **offset**
@@ -6568,7 +6568,7 @@ On exit from a function:
       VGPR232-239
       VGPR248-255
 
-        *Except the argument registers, the VGPR cloberred and the preserved
+        *Except the argument registers, the VGPR clobbered and the preserved
         registers are intermixed at regular intervals in order to
         get a better occupancy.*
 

docs/AliasAnalysis.rst

@@ -81,7 +81,7 @@ In this case, the ``basic-aa`` pass will disambiguate the stores to ``C[0]`` and
 ``C[1]`` because they are accesses to two distinct locations one byte apart, and
 the accesses are each one byte.  In this case, the Loop Invariant Code Motion
 (LICM) pass can use store motion to remove the stores from the loop.  In
-constrast, the following code:
+contrast, the following code:
 
 .. code-block:: c++
 

docs/BugLifeCycle.rst

@@ -116,7 +116,7 @@ Examples of reasons for resolving are:
     clearly understand the problem being reported (e.g. not reproducible). It is
     fine to resolve such a bug e.g. with resolution WORKSFORME and leaving a
     comment to encourage the reporter to reopen the bug with more information
-    if it's still reproducable on their end.
+    if it's still reproducible on their end.
 
 If a bug is resolved, please fill in the revision number it was fixed in in the
 "Fixed by Commit(s)" field.

docs/CMake.rst

@@ -447,7 +447,7 @@ LLVM-specific variables
 **LLVM_STATIC_LINK_CXX_STDLIB**:BOOL
   Statically link to the C++ standard library if possible. This uses the flag
   "-static-libstdc++", but a Clang host compiler will statically link to libc++
-  if used in conjuction with the **LLVM_ENABLE_LIBCXX** flag. Defaults to OFF.
+  if used in conjunction with the **LLVM_ENABLE_LIBCXX** flag. Defaults to OFF.
 
 **LLVM_ENABLE_LLD**:BOOL
   This option is equivalent to `-DLLVM_USE_LINKER=lld`, except during a 2-stage

docs/CommandGuide/llvm-extract.rst

@@ -39,7 +39,7 @@ OPTIONS
 
 **--bb** *basic-block-specifier*
 
- Extract basic blocks(s) specicified in *basic-block-specifier*. May be
+ Extract basic blocks(s) specified in *basic-block-specifier*. May be
  specified multiple times. Each <function:bb[;bb]> specifier pair will create
  a function. If multiple basic blocks are specified in one pair, the first
  block in the sequence should dominate the rest.

docs/ExceptionHandling.rst

@@ -530,7 +530,7 @@ on Itanium C++ ABI platforms. The fundamental difference between the two models
 is that Itanium EH is designed around the idea of "successive unwinding," while
 Windows EH is not.
 
-Under Itanium, throwing an exception typically involes allocating thread local
+Under Itanium, throwing an exception typically involves allocating thread local
 memory to hold the exception, and calling into the EH runtime. The runtime
 identifies frames with appropriate exception handling actions, and successively
 resets the register context of the current thread to the most recently active

docs/GlobalISel/GMIR.rst

@@ -104,7 +104,7 @@ In practice, register files A and B are rarely equal. They can typically store
 the same data but there's usually some restrictions on what operations you can
 do on each register file. A fairly common pattern is for one of them to be
 accessible to integer operations and the other accessible to floating point
-operations. To accomodate this, let's rename A and B to GPR (general purpose
+operations. To accommodate this, let's rename A and B to GPR (general purpose
 registers) and FPR (floating point registers).
 
 We now have some additional constraints that limit us. An operation like G_FMUL

docs/GlobalISel/GenericOpcode.rst

@@ -153,7 +153,7 @@ G_BITCAST
 ^^^^^^^^^
 
 Reinterpret a value as a new type. This is usually done without
-changing any bits but this is not always the case due a sublety in the
+changing any bits but this is not always the case due a subtlety in the
 definition of the :ref:`LLVM-IR Bitcast Instruction <i_bitcast>`. It
 is allowed to bitcast between pointers with the same size, but
 different address spaces.

docs/HowToSetUpLLVMStyleRTTI.rst

@@ -430,7 +430,7 @@ template argument and the parent class as the second argument. Any class that
 uses ``RTTIExtends`` must define a ``static char ID`` member, the address of
 which will be used to identify the type.
 
-This open-hierarchy RTTI support should only be used if your use case requries
+This open-hierarchy RTTI support should only be used if your use case requires
 it. Otherwise the standard LLVM RTTI system should be preferred.
 
 .. _`Curiously Recurring Template Idiom`:

docs/LangRef.rst

@@ -4882,7 +4882,7 @@ raw data, if they aren't equivalent. This is only supported for array types,
 particularly to describe Fortran arrays, which have an array descriptor in
 addition to the array data. Alternatively it can also be DIVariable which
 has the address of the actual raw data. The Fortran language supports pointer
-arrays which can be attached to actual arrays, this attachement between pointer
+arrays which can be attached to actual arrays, this attachment between pointer
 and pointee is called association.  The optional ``associated`` is a
 DIExpression that describes whether the pointer array is currently associated.
 The optional ``allocated`` is a DIExpression that describes whether the
@@ -6915,7 +6915,7 @@ We can expect the record like this:
 
     params: ((param: 0, offset: [0, 7]),(param: 2, offset: [5, 5], calls: ((callee: ^3, param: 1, offset: [-128, 127]))))
 
-The function may access just 8 bytes of the paramenter %0 . ``calls`` is empty,
+The function may access just 8 bytes of the parameter %0 . ``calls`` is empty,
 so the parameter is either not used for function calls or ``offset`` already
 covers all accesses from nested function calls.
 Parameter %1 escapes, so access is unknown.
@@ -16943,7 +16943,7 @@ Back-edge Taken Count (BTC). Thus, these intrinsics perform an element-wise
 less than or equal comparison of VIV with BTC, producing a mask of true/false
 values representing active/inactive vector lanes, except if the VIV overflows
 in which case they return false in the lanes where the VIV overflows.  The
-arguments are scalar types to accomodate scalable vector types, for which it is
+arguments are scalar types to accommodate scalable vector types, for which it is
 unknown what the type of the step vector needs to be that enumerate its
 lanes without overflow.
 

docs/MemorySSA.rst

@@ -55,7 +55,7 @@ always introduces a new version of the entire memory and is linked with a single
 ``MemoryDef/MemoryPhi`` which is the version of memory that the new
 version is based on. This implies that there is a *single*
 ``Def`` chain that connects all the ``Def``\ s, either directly
-or indireclty. For example in:
+or indirectly. For example in:
 
 .. code-block:: llvm
 

docs/Phabricator.rst

@@ -49,7 +49,7 @@ The tool to create and review patches in Phabricator is called
 *Differential*.
 
 Note that you can upload patches created through git, but using `arc` on the
-command line (see previous section) is prefered: it adds more metadata to
+command line (see previous section) is preferred: it adds more metadata to
 Phabricator which are useful for the pre-merge testing system and for
 propagating attribution on commits when someone else has to push it for you.
 

docs/Security.rst

@@ -25,7 +25,7 @@ Security Group Members
 The members of the group represent a wide cross-section of the community, and meet the criteria for inclusion below.
 
 * Akila Srinivasan (Apple)
-* Dimitry Andric (invidual; FreeBSD)
+* Dimitry Andric (individual; FreeBSD)
 * Ed Maste (individual; FreeBSD)
 * JF Bastien (Apple)
 * Josh Eads (Sony)

docs/TestSuiteGuide.md

@@ -185,7 +185,7 @@ benchmarks. CMake can print a list of them:
 
 - `TEST_SUITE_COLLECT_STATS`
 
-  Collect internal LLVM statistics. Appends `-save-stats=obj` when invocing the
+  Collect internal LLVM statistics. Appends `-save-stats=obj` when invoking the
   compiler and makes the lit runner collect and merge the statistic files.
 
 - `TEST_SUITE_RUN_BENCHMARKS`