[llvm] Fix typos in documentation

[kazutakahirata]

No description provided.

[llvmbot]

@llvm/pr-subscribers-backend-risc-v
@llvm/pr-subscribers-backend-spir-v
@llvm/pr-subscribers-llvm-binary-utilities

@llvm/pr-subscribers-backend-directx

Author: Kazu Hirata (kazutakahirata)

Changes

---

Full diff: https://github.com/llvm/llvm-project/pull/141078.diff

10 Files Affected:

• (modified) llvm/docs/CommandGuide/llvm-dwarfdump.rst (+1-1)
• (modified) llvm/docs/CommandGuide/llvm-objcopy.rst (+1-1)
• (modified) llvm/docs/DirectX/DXContainer.rst (+6-6)
• (modified) llvm/docs/PDB/CodeViewTypes.rst (+2-2)
• (modified) llvm/docs/RISCV/RISCVVectorExtension.rst (+1-1)
• (modified) llvm/docs/SPIRVUsage.rst (+1-1)
• (modified) llvm/docs/ScudoHardenedAllocator.rst (+1-1)
• (modified) llvm/docs/SecurityTransparencyReports.rst (+1-1)
• (modified) llvm/docs/StackMaps.rst (+1-1)
• (modified) llvm/docs/TableGen/BackEnds.rst (+1-1)

diff --git a/llvm/docs/CommandGuide/llvm-dwarfdump.rst b/llvm/docs/CommandGuide/llvm-dwarfdump.rst
index 426a6d596a1b8..c566b40346f4b 100644
--- a/llvm/docs/CommandGuide/llvm-dwarfdump.rst
+++ b/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`).
 
diff --git a/llvm/docs/CommandGuide/llvm-objcopy.rst b/llvm/docs/CommandGuide/llvm-objcopy.rst
index 96f3247780b3b..35d907fbe44d4 100644
--- a/llvm/docs/CommandGuide/llvm-objcopy.rst
+++ b/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`
diff --git a/llvm/docs/DirectX/DXContainer.rst b/llvm/docs/DirectX/DXContainer.rst
index f2cd27257af7b..4ace8a13dd89f 100644
--- a/llvm/docs/DirectX/DXContainer.rst
+++ b/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.
 
diff --git a/llvm/docs/PDB/CodeViewTypes.rst b/llvm/docs/PDB/CodeViewTypes.rst
index 64fe745d116e8..7a93ebec75405 100644
--- a/llvm/docs/PDB/CodeViewTypes.rst
+++ b/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.
   };
 
diff --git a/llvm/docs/RISCV/RISCVVectorExtension.rst b/llvm/docs/RISCV/RISCVVectorExtension.rst
index 6b2d2b2f18e4f..cfe9abfbdfcdb 100644
--- a/llvm/docs/RISCV/RISCVVectorExtension.rst
+++ b/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::
 
diff --git a/llvm/docs/SPIRVUsage.rst b/llvm/docs/SPIRVUsage.rst
index 4d8b7996dec01..1afae43aa8bce 100644
--- a/llvm/docs/SPIRVUsage.rst
+++ b/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``
diff --git a/llvm/docs/ScudoHardenedAllocator.rst b/llvm/docs/ScudoHardenedAllocator.rst
index 3268268e939d1..328c883bbd5db 100644
--- a/llvm/docs/ScudoHardenedAllocator.rst
+++ b/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
diff --git a/llvm/docs/SecurityTransparencyReports.rst b/llvm/docs/SecurityTransparencyReports.rst
index e4d7c23236b6c..b9092785a1eac 100644
--- a/llvm/docs/SecurityTransparencyReports.rst
+++ b/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
diff --git a/llvm/docs/StackMaps.rst b/llvm/docs/StackMaps.rst
index 11b6b3e2ca321..56c82e2863c3b 100644
--- a/llvm/docs/StackMaps.rst
+++ b/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
 
diff --git a/llvm/docs/TableGen/BackEnds.rst b/llvm/docs/TableGen/BackEnds.rst
index 94af2e4ab8f5c..14232bc3f9f54 100644
--- a/llvm/docs/TableGen/BackEnds.rst
+++ b/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