[llvm] Fix typos in documentation

kazutakahirata · kazutakahirata · commit 96ddbd6dd85f · 2023-05-12T23:47:46.000-07:00
diff --git a/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst b/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst
@@ -4973,7 +4973,7 @@ A.7.32 Type Signature Computation
 
 .. note::
 
-  This augments (in alphebetical order) DWARF Version 5 section 7.32, Table
+  This augments (in alphabetical order) DWARF Version 5 section 7.32, Table
   7.32.
 
 .. table:: Attributes used in type signature computation
diff --git a/llvm/docs/AMDGPUUsage.rst b/llvm/docs/AMDGPUUsage.rst
@@ -816,7 +816,7 @@ supported for the ``amdgcn`` target.
   ``getelementptr`` operations, on buffer resources. They may be passed to
   AMDGPU buffer intrinsics, and they may be converted to and from ``i128``.
 
-  Casting a buffer resource to a bufer fat pointer is permitted and adds an offset
+  Casting a buffer resource to a buffer fat pointer is permitted and adds an offset
   of 0.
 
 **Streamout Registers**
@@ -1256,14 +1256,14 @@ The AMDGPU backend uses the following ELF header:
      ``EF_AMDGPU_FEATURE_XNACK_V4``               0x300 XNACK selection mask for
                                                         ``EF_AMDGPU_FEATURE_XNACK_*_V4``
                                                         values.
-     ``EF_AMDGPU_FEATURE_XNACK_UNSUPPORTED_V4``   0x000 XNACK unsuppored.
+     ``EF_AMDGPU_FEATURE_XNACK_UNSUPPORTED_V4``   0x000 XNACK unsupported.
      ``EF_AMDGPU_FEATURE_XNACK_ANY_V4``           0x100 XNACK can have any value.
      ``EF_AMDGPU_FEATURE_XNACK_OFF_V4``           0x200 XNACK disabled.
      ``EF_AMDGPU_FEATURE_XNACK_ON_V4``            0x300 XNACK enabled.
      ``EF_AMDGPU_FEATURE_SRAMECC_V4``             0xc00 SRAMECC selection mask for
                                                         ``EF_AMDGPU_FEATURE_SRAMECC_*_V4``
                                                         values.
-     ``EF_AMDGPU_FEATURE_SRAMECC_UNSUPPORTED_V4`` 0x000 SRAMECC unsuppored.
+     ``EF_AMDGPU_FEATURE_SRAMECC_UNSUPPORTED_V4`` 0x000 SRAMECC unsupported.
      ``EF_AMDGPU_FEATURE_SRAMECC_ANY_V4``         0x400 SRAMECC can have any value.
      ``EF_AMDGPU_FEATURE_SRAMECC_OFF_V4``         0x800 SRAMECC disabled,
      ``EF_AMDGPU_FEATURE_SRAMECC_ON_V4``          0xc00 SRAMECC enabled.
diff --git a/llvm/docs/BigEndianNEON.rst b/llvm/docs/BigEndianNEON.rst
@@ -68,7 +68,7 @@ A vector is a consecutive sequence of items that are operated on simultaneously.
 
 Because of this, the instruction ``LD1`` performs a vector load but performs byte swapping not on the entire 64 bits, but on the individual items within the vector. This means that the register content is the same as it would have been on a little endian system.
 
-It may seem that ``LD1`` should suffice to peform vector loads on a big endian machine. However there are pros and cons to the two approaches that make it less than simple which register format to pick.
+It may seem that ``LD1`` should suffice to perform vector loads on a big endian machine. However there are pros and cons to the two approaches that make it less than simple which register format to pick.
 
 There are two options:
 
diff --git a/llvm/docs/CodeOfConduct.rst b/llvm/docs/CodeOfConduct.rst
@@ -136,7 +136,7 @@ needed) email conduct@llvm.org.
 Code of Conduct Committee
 =========================
 
-The committee will consist of a mininum of 5 members and members are asked to
+The committee will consist of a minimum of 5 members and members are asked to
 serve at least a 1 year term. New committee members will be selected by the
 current committee and the LLVM Foundation Board of Directors.
 
diff --git a/llvm/docs/CommandGuide/llvm-mc.rst b/llvm/docs/CommandGuide/llvm-mc.rst
@@ -16,7 +16,7 @@ specified architecture and generate object file or executable as a output
 for a specified architecture. 
 
 :program:`llvm-mc` provide powerful set of the tool for working with the machine code such 
-as encoding of their instruction and their internal representation, dissasemble 
+as encoding of their instruction and their internal representation, disassemble
 string to bytes etc. 
 
 The choice of architecture for the output assembly code is automatically
diff --git a/llvm/docs/CommandGuide/tblgen.rst b/llvm/docs/CommandGuide/tblgen.rst
@@ -109,7 +109,7 @@ clang-tblgen Options
 
 .. option:: -gen-clang-attr-classes
 
-  Generate Clang attribute clases.
+  Generate Clang attribute classes.
 
 .. option:: -gen-clang-attr-parser-string-switches
 
diff --git a/llvm/docs/Coroutines.rst b/llvm/docs/Coroutines.rst
@@ -1705,7 +1705,7 @@ and `coro.promise`_ intrinsics.
 
 CoroSplit
 ---------
-The pass CoroSplit buides coroutine frame and outlines resume and destroy parts
+The pass CoroSplit builds coroutine frame and outlines resume and destroy parts
 into separate functions.
 
 CoroElide
diff --git a/llvm/docs/GarbageCollection.rst b/llvm/docs/GarbageCollection.rst
@@ -735,7 +735,7 @@ require them.
 | register   | NO   |        |          | **?** | **?**   | **?**       | **?**    | **?**      |
 | map        |      |        |          |       |         |             |          |            |
 +------------+------+--------+----------+-------+---------+-------------+----------+------------+
-| \* Derived pointers only pose a hasard to copying collections.                                |
+| \* Derived pointers only pose a hazard to copying collections.                                |
 +------------+------+--------+----------+-------+---------+-------------+----------+------------+
 | **?** denotes a feature which could be utilized if available.                                 |
 +------------+------+--------+----------+-------+---------+-------------+----------+------------+
diff --git a/llvm/docs/GettingStartedVS.rst b/llvm/docs/GettingStartedVS.rst
@@ -164,7 +164,7 @@ These instruction were tested with Visual Studio 2019 and Python 3.9.6:
    **RelWithDebInfo** which is also several time larger than Release.
    Another technique is to build all of LLVM in Release mode and change
    compiler flags, disabling optimization and enabling debug information, only
-   for specific librares or source files you actually need to debug.
+   for specific libraries or source files you actually need to debug.
 
 14. Test LLVM in Visual Studio:
 
diff --git a/llvm/docs/HowToAddABuilder.rst b/llvm/docs/HowToAddABuilder.rst
@@ -236,7 +236,7 @@ Use Ninja & LLD
   Ninja really does help build times over Make, particularly for highly
   parallel builds.  LLD helps to reduce both link times and memory usage
   during linking significantly.  With a build machine with sufficient
-  parallism, link times tend to dominate critical path of the build, and are
+  parallelism, link times tend to dominate critical path of the build, and are
   thus worth optimizing.
 
 Use CCache and NOT incremental builds
diff --git a/llvm/docs/JITLink.rst b/llvm/docs/JITLink.rst
@@ -422,7 +422,7 @@ JITLink provides a generic link algorithm which can be extended / modified at
 certain points by the introduction of JITLink :ref:`passes`.
 
 At the end of each phase the linker packages its state into a *continuation*
-and calls the ``JITLinkContext`` object to perform a (potentialy high-latency)
+and calls the ``JITLinkContext`` object to perform a (potentially high-latency)
 asynchronous operation: allocating memory, resolving external symbols, and
 finally transferring linked memory to the executing process.
 
@@ -721,7 +721,7 @@ and pass it to the ``OnFinalized`` callback.
 Finalized allocations (represented by ``FinalizedAlloc`` objects) can be
 deallocated by calling the ``JITLinkMemoryManager::dealloc`` method. This method
 takes a vector of ``FinalizedAlloc`` objects, since it is common to deallocate
-multiple objects at the same time and this allows us to batch these requsets for
+multiple objects at the same time and this allows us to batch these requests for
 transmission to the executing process.
 
 JITLink provides a simple in-process implementation of this interface:
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
@@ -4193,7 +4193,7 @@ or '``void``') and be used anywhere a constant is permitted.
 
 .. note::
 
-  A '``poison``' value (decribed in the next section) should be used instead of
+  A '``poison``' value (described in the next section) should be used instead of
   '``undef``' whenever possible. Poison values are stronger than undef, and
   enable more optimizations. Just the existence of '``undef``' blocks certain
   optimizations (see the examples below).
diff --git a/llvm/docs/MemorySSA.rst b/llvm/docs/MemorySSA.rst
@@ -470,10 +470,10 @@ In practice, there are implementation details in LLVM that also affect the
 results' precision provided by ``MemorySSA``. For example, AliasAnalysis has various
 caps, or restrictions on looking through phis which can affect what ``MemorySSA``
 can infer. Changes made by different passes may make MemorySSA either "overly
-optimized" (it can provide a more acccurate result than if it were recomputed
+optimized" (it can provide a more accurate result than if it were recomputed
 from scratch), or "under optimized" (it could infer more if it were recomputed).
 This can lead to challenges to reproduced results in isolation with a single pass
-when the result relies on the state aquired by ``MemorySSA`` due to being updated by
+when the result relies on the state acquired by ``MemorySSA`` due to being updated by
 multiple subsequent passes.
 Passes that use and update ``MemorySSA`` should do so through the APIs provided by the
 ``MemorySSAUpdater``, or through calls on the Walker.
diff --git a/llvm/docs/ProgrammersManual.rst b/llvm/docs/ProgrammersManual.rst
@@ -2475,7 +2475,7 @@ choice for representing sets which have lots of very short ranges. E.g. the set
 Useful Utility Functions
 ========================
 
-LLVM implements a number of general utility functions used acrossed the
+LLVM implements a number of general utility functions used across the
 codebase. You can find the most common ones in ``STLExtras.h``
 (`doxygen <https://llvm.org/doxygen/STLExtras_8h.html>`__). Some of these wrap
 well-known C++ standard library functions, while others are unique to LLVM.
diff --git a/llvm/docs/SourceLevelDebugging.rst b/llvm/docs/SourceLevelDebugging.rst
@@ -250,14 +250,14 @@ the complex expression derives the direct value.
                         Value *Address,
                         DIExpression *AddressExpression)
 
-This intrinsic marks the position in IR where a source assignment occured. It
+This intrinsic marks the position in IR where a source assignment occurred. It
 encodes the value of the variable. It references the store, if any, that
 performs the assignment, and the destination address.
 
 The first three arguments are the same as for an ``llvm.dbg.value``. The fourth
 argument is a ``DIAssignID`` used to reference a store. The fifth is the
 destination of the store (wrapped as metadata), and the sixth is a `complex
-expression <LangRef.html#diexpression>`_ that modfies it.
+expression <LangRef.html#diexpression>`_ that modifies it.
 
 The formal LLVM-IR signature is:
 
diff --git a/llvm/docs/TableGen/ProgRef.rst b/llvm/docs/TableGen/ProgRef.rst
@@ -1639,7 +1639,7 @@ and non-0 as true.
     ``(op a1-value:$name1, a2-value:$name2, ?:$name3)``.
 
 ``!div(``\ *a*\ ``,`` *b*\ ``)``
-    This operator preforms signed division of *a* by *b*, and produces the quotient.
+    This operator performs signed division of *a* by *b*, and produces the quotient.
     Division by 0 produces an error. Division of INT64_MIN by -1 produces an error.
 
 ``!empty(``\ *a*\ ``)``
