[llvm] Fix typos in documentation (#140275)

kazutakahirata · arsenm · web-flow · commit ad6bb7077302 · 2025-05-16T12:37:43.000-07:00
Co-authored-by: Matt Arsenault &lt;arsenm2@gmail.com&gt;
diff --git a/llvm/docs/AMDGPUUsage.rst b/llvm/docs/AMDGPUUsage.rst
@@ -1352,7 +1352,7 @@ The AMDGPU backend implements the following LLVM IR intrinsics.
 
   llvm.amdgcn.sched.group.barrier                  Creates schedule groups with specific properties to create custom scheduling
                                                    pipelines. The ordering between groups is enforced by the instruction scheduler.
-                                                   The intrinsic applies to the code that preceeds the intrinsic. The intrinsic
+                                                   The intrinsic applies to the code that precedes the intrinsic. The intrinsic
                                                    takes three values that control the behavior of the schedule groups.
 
                                                    - Mask : Classify instruction groups using the llvm.amdgcn.sched_barrier mask values.
@@ -1669,7 +1669,7 @@ The AMDGPU backend supports the following LLVM IR attributes.
 
      "amdgpu-git-ptr-high"                            The hard-wired high half of the address of the global information table
                                                       for AMDPAL OS type. 0xffffffff represents no hard-wired high half, since
-                                                      current hardware only allows a 16 bit value.
+                                                      current hardware only allows a 16-bit value.
 
      "amdgpu-32bit-address-high-bits"                 Assumed high 32-bits for 32-bit address spaces which are really truncated
                                                       64-bit addresses (i.e., addrspace(6))
@@ -4884,7 +4884,7 @@ apertures address can be used. For GFX7-GFX8 these are available in the
 :ref:`amdgpu-amdhsa-hsa-aql-queue` the address of which can be obtained with
 Queue Ptr SGPR (see :ref:`amdgpu-amdhsa-initial-kernel-execution-state`). For
 GFX9-GFX11 the aperture base addresses are directly available as inline constant
-registers ``SRC_SHARED_BASE/LIMIT`` and ``SRC_PRIVATE_BASE/LIMIT``. In 64 bit
+registers ``SRC_SHARED_BASE/LIMIT`` and ``SRC_PRIVATE_BASE/LIMIT``. In 64-bit
 address mode the aperture sizes are 2^32 bytes and the base is aligned to 2^32
 which makes it easier to convert from flat to segment or segment to flat.
 
diff --git a/llvm/docs/CIBestPractices.rst b/llvm/docs/CIBestPractices.rst
@@ -61,7 +61,7 @@ just a release, which looks like the following:
 However, it is best practice to specify an exact commit SHA from which to pull
 the action from, noting the version in a comment:
 
-We plan on revisting this reccomendation once Github's immutable actions have
+We plan on revisiting this recommendation once Github's immutable actions have
 been rolled out as GA.
 
 .. code-block:: yaml
diff --git a/llvm/docs/CMake.rst b/llvm/docs/CMake.rst
@@ -589,7 +589,7 @@ enabled sub-projects. Nearly all of these variable names begin with
 
   .. note::
     Some projects listed here can also go in ``LLVM_ENABLE_RUNTIMES``. They
-    should only appear in one of the two lists. If a project is a valid possiblity
+    should only appear in one of the two lists. If a project is a valid possibility
     for both, prefer putting it in ``LLVM_ENABLE_RUNTIMES``.
 
 **LLVM_ENABLE_RTTI**:BOOL
diff --git a/llvm/docs/CodeGenerator.rst b/llvm/docs/CodeGenerator.rst
@@ -2088,7 +2088,7 @@ frame.  LLVM takes advantage of having no TOC to provide space to save the frame
 pointer in the PowerPC linkage area of the caller frame.  Other details of
 PowerPC ABI can be found at `PowerPC ABI
 <http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/Articles/32bitPowerPC.html>`_\
-. Note: This link describes the 32 bit ABI.  The 64 bit ABI is similar except
+. Note: This link describes the 32-bit ABI.  The 64-bit ABI is similar except
 space for GPRs are 8 bytes wide (not 4) and r13 is reserved for system use.
 
 Frame Layout
@@ -2137,8 +2137,8 @@ function epilog can also use the link to pop the frame from the stack.  The
 third entry in the linkage area is used to save the return address from the lr
 register. Finally, as mentioned above, the last entry is used to save the
 previous frame pointer (r31.)  The entries in the linkage area are the size of a
-GPR, thus the linkage area is 24 bytes long in 32 bit mode and 48 bytes in 64
-bit mode.
+GPR, thus the linkage area is 24 bytes long in 32-bit mode and 48 bytes in
+64-bit mode.
 
 32 bit linkage area:
 
@@ -2207,21 +2207,21 @@ 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
+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 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.
+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
 parameter areas.  The cost of shifting the linkage and parameter areas is minor
 since only the link value needs to be copied.  The link value can be easily
 fetched by adding the original frame size to the base pointer.  Note that
-allocations in the dynamic space need to observe 16 byte alignment.
+allocations in the dynamic space need to observe 16-byte alignment.
 
 The *locals area* is where the llvm compiler reserves space for local variables.
 
@@ -2343,7 +2343,7 @@ When BPF_CLASS(code) == BPF_ALU or BPF_ALU64 or BPF_JMP,
 ::
 
   BPF_X     0x1  use src_reg register as source operand
-  BPF_K     0x0  use 32 bit immediate as source operand
+  BPF_K     0x0  use 32-bit immediate as source operand
 
 and four MSB bits store operation code
 
diff --git a/llvm/docs/Coroutines.rst b/llvm/docs/Coroutines.rst
@@ -606,7 +606,7 @@ be used to communicate with the coroutine. This distinguished alloca is called
 **coroutine promise** and is provided as the second parameter to the
 `coro.id`_ intrinsic.
 
-The following coroutine designates a 32 bit integer `promise` and uses it to
+The following coroutine designates a 32-bit integer `promise` and uses it to
 store the current value produced by a coroutine.
 
 .. code-block:: llvm
@@ -2055,7 +2055,7 @@ coroutine, and things that happen after the resumption of the coroutine
 are not guaranteed to happen only after the end of `await_suspend`.
 
 This version of intrinsic corresponds to 
-'``std::corouine_handle<> awaiter.await_suspend(...)``' variant.
+'``std::coroutine_handle<> awaiter.await_suspend(...)``' variant.
 
 Arguments:
 """"""""""
diff --git a/llvm/docs/CoverageMappingFormat.rst b/llvm/docs/CoverageMappingFormat.rst
@@ -412,7 +412,7 @@ IR for the `coverage mapping sample`_ that was shown earlier:
   for the first function record.
 
 * The two trailing bytes are zeroes and are used to pad the coverage mapping
-  data to give it the 8 byte alignment.
+  data to give it the 8-byte alignment.
 
 Encoding
 ========
diff --git a/llvm/docs/DeveloperPolicy.rst b/llvm/docs/DeveloperPolicy.rst
@@ -54,7 +54,7 @@ to the categories of interest for notifications.
 Paying attention to changes being made by others is a good way to see what other people
 are interested in and watching the flow of the project as a whole.
 
-Contibutions to the project are made through :ref:`GitHub Pull Requests <github-reviews>`.
+Contributions to the project are made through :ref:`GitHub Pull Requests <github-reviews>`.
 You can subscribe to notification for areas of the codebase by joining
 one of the `pr-subscribers-* <https://github.com/orgs/llvm/teams?query=pr-subscribers>`_
 GitHub teams. This `mapping <https://github.com/llvm/llvm-project/blob/main/.github/new-prs-labeler.yml>`_
diff --git a/llvm/docs/ExtendingLLVM.rst b/llvm/docs/ExtendingLLVM.rst
@@ -127,7 +127,7 @@ complicated behavior in a single node (rotate).
    Add a case for your node in ``ExpandOp`` to teach the legalizer how to
    perform the action represented by the new node on a value that has been split
    into high and low halves.  This case will be used to support your node with a
-   64 bit operand on a 32 bit target.
+   64-bit operand on a 32-bit target.
 
 #. ``lib/CodeGen/SelectionDAG/DAGCombiner.cpp``:
 
diff --git a/llvm/docs/InstrProfileFormat.rst b/llvm/docs/InstrProfileFormat.rst
@@ -32,7 +32,7 @@ data from an executable or a shared library [3]_ consists of a header and
 multiple sections, with each section as a memory dump. The raw profile data needs
 to be reasonably compact and fast to generate.
 
-There are no backward or forward version compatiblity guarantees for the raw profile
+There are no backward or forward version compatibility guarantees for the raw profile
 format. That is, compilers and tools `require`_ a specific raw profile version
 to parse the profiles.
 
@@ -381,7 +381,7 @@ This section contains the profile data for value profiling.
 The value profiles corresponding to a profile metadata are serialized contiguously
 as one record, and value profile records are stored in the same order as the
 respective profile data, such that a raw profile reader `advances`_ the pointer to
-profile data and the pointer to value profile records simutaneously [5]_ to find
+profile data and the pointer to value profile records simultaneously [5]_ to find
 value profiles for a per function, per `FuncHash`_ profile data.
 
 .. _`advances`: https://github.com/llvm/llvm-project/blob/7e15fa9161eda7497a5d6abf0d951a1d12d86550/llvm/include/llvm/ProfileData/InstrProfReader.h#L456-L457
@@ -520,7 +520,7 @@ based profile data. For supported usages, check out `llvm-profdata documentation
 .. [4] The counter section is used by a few variant types (like temporal
    profiling) and might have different semantics there.
 .. [5] The step size of data pointer is the ``sizeof(ProfileData)``, and the step
-   size of value profile pointer is calcuated based on the number of collected
+   size of value profile pointer is calculated based on the number of collected
    values.
 
 .. _`lightweight instrumentation`: https://groups.google.com/g/llvm-dev/c/r03Z6JoN7d4
diff --git a/llvm/docs/InterfaceExportAnnotations.rst b/llvm/docs/InterfaceExportAnnotations.rst
@@ -123,7 +123,7 @@ class declaration must be annotated with ``LLVM_ABI``.
 
    class ExampleClass {
    public:
-     // Public methods defined externally must be annotatated.
+     // Public methods defined externally must be annotated.
      LLVM_ABI int sourceDefinedPublicMethod(int a, int b);
 
      // Methods defined in the class definition do not need annotation.
@@ -135,7 +135,7 @@ class declaration must be annotated with ``LLVM_ABI``.
      ExampleClass() {}
      LLVM_ABI ~ExampleClass();
 
-     // Public static methods defined externally must be annotatated.
+     // Public static methods defined externally must be annotated.
      LLVM_ABI static int sourceDefinedPublicStaticMethod(int a, int b);
    };
 
