[llvm] Fix typos in documentation (#141078)

Author: kazutakahirata

llvm/docs/CommandGuide/llvm-dwarfdump.rst

@@ -162,7 +162,7 @@ OPTIONS
 
 .. option:: --verify-json=<path>
 
-            Output JSON-formatted error summary to the a file specfied by
+            Output JSON-formatted error summary to the a file specified by
             <path>. Implies :option:`--verify`.  The output format is described
             in the section below (:ref:`verify-json-format`).
 

llvm/docs/CommandGuide/llvm-objcopy.rst

@@ -606,7 +606,7 @@ options. For GNU :program:`objcopy` compatibility, the values are all bfdnames.
 - `elf64-loongarch`
 - `elf64-s390`
 
-The following formats are suppoprted by :program:`llvm-objcopy` for the
+The following formats are supported by :program:`llvm-objcopy` for the
 :option:`--output-target` only:
 
 - `srec`

llvm/docs/DirectX/DXContainer.rst

@@ -222,7 +222,7 @@ is an index table, and the third block is the elements themselves, which in turn
 are separeated by input, output and patch constant or primitive elements.
 
 Signature elements capture much of the same data captured in the :ref:`SG1
-<ISG1>` parts. The use of an index table allows de-duplciation of data for a more
+<ISG1>` parts. The use of an index table allows de-duplication of data for a more
 compact final representation.
 
 The string table begins with a 32-bit unsigned integer specifying the table
@@ -430,7 +430,7 @@ Static Samplers          52                                          Many
 Root Signature Header
 ~~~~~~~~~~~~~~~~~~~~~
 
-The root signature header is 24 bytes long, consisting of six 32 bit values 
+The root signature header is 24 bytes long, consisting of six 32-bit values
 representing the version, number and offset of parameters, number and offset 
 of static samplers, and a flags field for global behaviours:
 
@@ -454,7 +454,7 @@ type having different size and fields.
 
 The slot of root parameters is preceded by a variable size section containing 
 the header information for such parameters. Such structure is 12 bytes long, 
-composed of three 32 bit values, representing the parameter type, a flag 
+composed of three 32-bit values, representing the parameter type, a flag
 encoding the pipeline stages where the data is visible, and an offset 
 calculated from the start of RTS0 section.
 
@@ -467,7 +467,7 @@ calculated from the start of RTS0 section.
    };
 
 After the header information has been serialized, the actual data for each of the
-root parameters is layout in a single continous blob. The parameters can be fetch 
+root parameters is layout in a single continuous blob. The parameters can be fetch 
 from such using the offset information, present in the header.
 
 The following sections will describe each of the root parameters types and their 
@@ -477,7 +477,7 @@ Root Constants
 ''''''''''''''
 
 The root constants are inline 32-bit values that show up in the shader 
-as a constant buffer. It is a 12 bytes long structure, two 32 bit values 
+as a constant buffer. It is a 12 bytes long structure, two 32-bit values
 encoding the register and space the constant is assigned to, and 
 the last 32 bits encode the number of constants being defined in the buffer.
 
@@ -520,7 +520,7 @@ Descriptor tables let shaders access multiple resources through a single pointer
 to a descriptor heap. 
 
 The tables are made of a collection of descriptor ranges. In Version 1.0, the 
-descriptor range is 20 bytes, containing five 32 bit values. It encodes a range 
+descriptor range is 20 bytes, containing five 32-bit values. It encodes a range
 of registers, including the register type, range length, register numbers and 
 space within range and the offset locating each range inside the table.
 

llvm/docs/PDB/CodeViewTypes.rst

@@ -43,12 +43,12 @@ records -- called ``member records`` do not.
 Leaf Records
 ------------
 
-All leaf records begin with the following 4 byte prefix:
+All leaf records begin with the following 4-byte prefix:
 
 .. code-block:: c++
 
   struct RecordHeader {
-    uint16_t RecordLen;  // Record length, not including this 2 byte field.
+    uint16_t RecordLen;  // Record length, not including this 2-byte field.
     uint16_t RecordKind; // Record kind enum.
   };
 

llvm/docs/RISCV/RISCVVectorExtension.rst

@@ -260,7 +260,7 @@ VMV0 elimination
 
 Because masked instructions must have the mask register in ``v0``, a specific register class ``vmv0`` is used that contains only one register, ``v0``.
 
-However register coalescing may end up coleascing copies into ``vmv0``, resulting in instructions with multiple uses of ``vmv0`` that the register allocator can't allocate:
+However register coalescing may end up coalescing copies into ``vmv0``, resulting in instructions with multiple uses of ``vmv0`` that the register allocator can't allocate:
 
 .. code-block::
 

llvm/docs/SPIRVUsage.rst

@@ -188,7 +188,7 @@ list of supported SPIR-V extensions, sorted alphabetically by their extension na
    * - ``SPV_INTEL_variable_length_array``
      - Allows to allocate local arrays whose number of elements is unknown at compile time.
    * - ``SPV_INTEL_joint_matrix``
-     - Adds few matrix capabilities on top of SPV_KHR_cooperative_matrix extension, such as matrix prefetch, get element coordinate and checked load/store/construct instructions, tensor float 32 and bfloat type interpretations for multuply-add instruction.
+     - Adds few matrix capabilities on top of SPV_KHR_cooperative_matrix extension, such as matrix prefetch, get element coordinate and checked load/store/construct instructions, tensor float 32 and bfloat type interpretations for multiply-add instruction.
    * - ``SPV_KHR_bit_instructions``
      - Enables bit instructions to be used by SPIR-V modules without requiring the Shader capability.
    * - ``SPV_KHR_expect_assume``

llvm/docs/ScudoHardenedAllocator.rst

@@ -36,7 +36,7 @@ The allocator combines several components that serve distinct purposes:
 
 - the Primary allocator: fast and efficient, it services smaller allocation
   sizes by carving reserved memory regions into blocks of identical size. There
-  are currently two Primary allocators implemented, specific to 32 and 64 bit
+  are currently two Primary allocators implemented, specific to 32- and 64-bit
   architectures. It is configurable via compile time options.
 
 - the Secondary allocator: slower, it services larger allocation sizes via the

llvm/docs/SecurityTransparencyReports.rst

@@ -218,7 +218,7 @@ Supply chain security related issues and project services-related issues
    Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=71 |br|
    redirect: https://issuetracker.google.com/issues/42410066 |br|
    archive: https://github.com/llvm/llvm-project/issues/132187
-2. “llvmbot account suspended due to supicious login” |br|
+2. “llvmbot account suspended due to suspicious login” |br|
    Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=72 |br|
    redirect: https://issuetracker.google.com/issues/42410067 |br|
    archive: https://github.com/llvm/llvm-project/issues/132243

llvm/docs/StackMaps.rst

@@ -144,7 +144,7 @@ destructive patching could overwrite program text or data outside the
 current function. We disallow overlapping stack map shadows so that
 the runtime does not need to consider this corner case.
 
-For example, a stack map with 8 byte shadow:
+For example, a stack map with 8-byte shadow:
 
 .. code-block:: llvm
 

llvm/docs/TableGen/BackEnds.rst

@@ -914,7 +914,7 @@ table, record with name ``Banana`` will come before the record with name
 ``Pear``. Because of this, the ``lookupCEntryByEncoding`` function will always
 return a pointer to the record with name ``Banana`` even though in some cases
 the correct result can be the record with name ``Pear``. Such kind of scenario
-makes the exisitng lookup function insufficient because they always return a
+makes the existing lookup function insufficient because they always return a
 pointer to a single entry from the table, but instead it should return a range
 of results because multiple entries match the criteria sought by the lookup
 function. In this case, the definition of the lookup function needs to be