[llvm] Proofread *.rst (#168185)

kazutakahirata · web-flow · commit 63e059de2333 · 2025-11-15T08:06:23.000-08:00
This patch is limited to single-word replacements to fix spelling
and/or grammar to ease the review process.  Punctuation and markdown
fixes are specifically excluded.
diff --git a/llvm/docs/HowToBuildWindowsItaniumPrograms.rst b/llvm/docs/HowToBuildWindowsItaniumPrograms.rst
@@ -13,7 +13,7 @@ headers or additional runtime machinery (such as is used by mingw).
 
 Windows Itanium Stack:
 
-* Uses the Itanium C++ abi.
+* Uses the Itanium C++ ABI.
 * libc++.
 * libc++-abi.
 * libunwind.
@@ -75,7 +75,7 @@ It is also possible to cross-compile from Linux.
 
 To build the libraries in step 2, refer to the `libc++ documentation <https://libcxx.llvm.org/VendorDocumentation.html#the-default-build>`_.
 
-The next section discuss the salient options and modifications required for building and installing the
+The next section discusses the salient options and modifications required for building and installing the
 libraries. This assumes that we are building libunwind and libc++ as DLLs and statically linking libc++abi
 into libc++. Other build configurations are possible, but they are not discussed here.
 
diff --git a/llvm/docs/HowToUpdateDebugInfo.rst b/llvm/docs/HowToUpdateDebugInfo.rst
@@ -95,7 +95,7 @@ memory access occurred.
 To maintain distinct source locations for SamplePGO, it is often beneficial to
 retain an arbitrary but deterministic location instead of discarding line and
 column information as part of merging. In particular, loss of location
-information for calls inhibit optimizations such as indirect call promotion.
+information for calls inhibits optimizations such as indirect call promotion.
 This behavior can be optionally enabled until support for accurately
 representing merged instructions in the line table is implemented.
 
diff --git a/llvm/docs/HowToUseInstrMappings.rst b/llvm/docs/HowToUseInstrMappings.rst
@@ -67,7 +67,7 @@ depending on some input flag, ``inPredSense``. The first step in the process is
 to define a relationship model that relates predicated instructions to their
 non-predicated form by assigning appropriate values to the ``InstrMapping``
 fields. For this relationship, non-predicated instructions are treated as key
-instruction since they are the one used to query the interface function.
+instruction since they are the ones used to query the interface function.
 
 .. code-block:: text
 
diff --git a/llvm/docs/InstrProfileFormat.rst b/llvm/docs/InstrProfileFormat.rst
@@ -80,7 +80,7 @@ of all the sections ahead of it.
 
 .. note::
    Sections might be padded to meet specific alignment requirements. For
-   simplicity, header fields and data sections solely for padding purpose are
+   simplicity, header fields and data sections solely for padding purposes are
    omitted in the data layout graph above and the rest of this document.
 
 Header
@@ -195,7 +195,7 @@ The fields are documented as follows:
 
 ``FuncHash``
   A checksum of the function's IR, taking control flow graph and instrumented
-  value sites into accounts. See `computeCFGHash`_ for details.
+  value sites into account. See `computeCFGHash`_ for details.
 
 .. _`computeCFGHash`: https://github.com/llvm/llvm-project/blob/7c3b67d2038cfb48a80299089f6a1308eee1df7f/llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp#L616-L685
 
@@ -210,7 +210,7 @@ The fields are documented as follows:
 .. _`commit a1532ed`: https://github.com/llvm/llvm-project/commit/a1532ed27582038e2d9588108ba0fe8237f01844
 
   .. note::
-    ``CounterPtr`` might represent a different value for non-IRPGO use case. For
+    ``CounterPtr`` might represent a different value for non-IRPGO use cases. For
     example, for `binary profile correlation`_, it represents the absolute address of counter.
     When in doubt, check source code.
 
@@ -221,7 +221,7 @@ The fields are documented as follows:
   corresponding bitmap.
 
   .. note::
-    Similar to `CounterPtr`_, this field may represent a different value for non-IRPGO use case.
+    Similar to `CounterPtr`_, this field may represent a different value for non-IRPGO use cases.
 
 ``FunctionPointer``
   Records the function address when instrumented binary runs. This is used to
diff --git a/llvm/docs/KernelInfo.rst b/llvm/docs/KernelInfo.rst
@@ -8,7 +8,7 @@ KernelInfo
 Introduction
 ============
 
-This LLVM IR pass reports various statistics for codes compiled for GPUs.  The
+This LLVM IR pass reports various statistics for code compiled for GPUs.  The
 goal of these statistics is to help identify bad code patterns and ways to
 mitigate them.  The pass operates at the LLVM IR level so that it can, in
 theory, support any LLVM-based compiler for programming languages supporting
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
@@ -439,7 +439,7 @@ added in the future:
 "``preserve_allcc``" - The `PreserveAll` calling convention
     This calling convention attempts to make the code in the caller even less
     intrusive than the `PreserveMost` calling convention. This calling
-    convention also behaves identical to the `C` calling convention on how
+    convention also behaves identically to the `C` calling convention on how
     arguments and return values are passed, but it uses a different set of
     caller/callee-saved registers. This removes the burden of saving and
     recovering a large register set before and after the call in the caller. If
@@ -479,7 +479,7 @@ added in the future:
     preserving as many registers as possible (all the registers that are
     preserved on the fast path, composed of the entry and exit blocks).
 
-    This calling convention behaves identical to the `C` calling convention on
+    This calling convention behaves identically to the `C` calling convention on
     how arguments and return values are passed, but it uses a different set of
     caller/callee-saved registers.
 
diff --git a/llvm/docs/Lexicon.rst b/llvm/docs/Lexicon.rst
@@ -57,7 +57,7 @@ C
     This abbreviation has two meanings.
     Either:
     Call Frame Information. Used in DWARF debug info and in C++ unwind info
-    to show how the function prolog lays out the stack frame.
+    to show how the function prologue lays out the stack frame.
 
     Or:
     Control Flow Integrity. A general term for computer security techniques
@@ -194,7 +194,7 @@ L
     generic unwinding mechanism.  As the unwinder walks each frame, it calls
     a "personality" function to do language-specific analysis.  Each function's
     FDE points to an optional LSDA which is passed to the personality function.
-    For C++, the LSDA contain info about the type and location of catch
+    For C++, the LSDA contains info about the type and location of catch
     statements in that function.
 
 **Load-VN**
@@ -256,7 +256,7 @@ R
 
 **Reassociation**
     Rearranging associative expressions to promote better redundancy elimination
-    and other optimization.  For example, changing ``(A+B-A)`` into ``(B+A-A)``,
+    and other optimizations.  For example, changing ``(A+B-A)`` into ``(B+A-A)``,
     permitting it to be optimized into ``(B+0)`` then ``(B)``.
 
 **RFC**
diff --git a/llvm/docs/LinkTimeOptimization.rst b/llvm/docs/LinkTimeOptimization.rst
@@ -180,7 +180,7 @@ are needed by native object files. In the example above, the linker reports
 that only ``foo1()`` is used by native object files using
 ``lto_codegen_add_must_preserve_symbol()``. Next the linker invokes the LLVM
 optimizer and code generators using ``lto_codegen_compile()`` which returns a
-native object file creating by merging the LLVM bitcode files and applying
+native object file created by merging the LLVM bitcode files and applying
 various optimization passes.
 
 Phase 4 : Symbol Resolution after optimization
diff --git a/llvm/docs/MLGO.rst b/llvm/docs/MLGO.rst
@@ -29,7 +29,7 @@ This document is an outline of the tooling and APIs facilitating MLGO.
 Corpus Tooling
 ==============
 
-Within the LLVM monorepo, there is the ``mlgo-utils`` python packages that
+Within the LLVM monorepo, there is the ``mlgo-utils`` Python package that
 lives at ``llvm/utils/mlgo-utils``. This package primarily contains tooling
 for working with corpora, or collections of LLVM bitcode. We use these corpora
 to train and evaluate ML models. Corpora consist of a description in JSON
@@ -82,7 +82,7 @@ Options
 
 .. option:: --cmd_filter
 
-  Allows filtering of modules by command line. If set, only modules that much
+  Allows filtering of modules by command line. If set, only modules that match
   the filter will be extracted into the corpus. Regular expressions are
   supported in some instances.
 
@@ -690,7 +690,7 @@ This supports the ``ReleaseModeModelRunner`` model runners.
 
 You need a tensorflow pip package for the AOT (ahead-of-time) Saved Model compiler
 and a thin wrapper for the native function generated by it. We currently support
-TF 2.15. We recommend using a python virtual env (in which case, remember to
+TF 2.15. We recommend using a Python virtual env (in which case, remember to
 pass ``-DPython3_ROOT_DIR`` to ``cmake``).
 
 Once you install the pip package, find where it was installed:
diff --git a/llvm/docs/MemoryModelRelaxationAnnotations.rst b/llvm/docs/MemoryModelRelaxationAnnotations.rst
@@ -412,7 +412,7 @@ not break other constraints as single location coherence.
 Static reordering is one consequence of breaking *happens-before*,
 but is not the most interesting one.
 
-Run-time consequences are more interesting. When there is an
+Run-time consequences are more interesting. When there is a
 *happens-before* relation between instructions, the target has to emit
 synchronization code to ensure other threads will observe the effects of
 the instructions in the right order.
@@ -440,7 +440,7 @@ For every unique tag prefix P present in A or B:
   P from both sets are added to U.
 
 Passes should avoid aggressively combining MMRAs, as this can result
-in significant losses of information. While this cannot affect
+in significant loss of information. While this cannot affect
 correctness, it may affect performance.
 
 As a general rule of thumb, common passes such as SimplifyCFG that
diff --git a/llvm/docs/NVPTXUsage.rst b/llvm/docs/NVPTXUsage.rst
@@ -911,7 +911,7 @@ Semantics:
 """"""""""
 
 Unlike, '``llvm.fabs.*``', these intrinsics do not perfectly preserve NaN
-values. Instead, a NaN input yeilds an unspecified NaN output.
+values. Instead, a NaN input yields an unspecified NaN output.
 
 
 '``llvm.nvvm.fabs.ftz.*``' Intrinsic
@@ -2627,7 +2627,7 @@ the `nvvm.tcgen05.mma` will result in the initiation of the whole matrix and acc
 operation
 
 When `.sp` is specifed, the dimension of A matrix is `M x (K/2)` and requires
-specifiying an additional `%spmetadata` argument
+specifying an additional `%spmetadata` argument
 
 `.ashift` shifts the rows of the A matrix down by one row, except for the last row
 in the Tensor Memory. `.ashift` is only allowed with M = 128 or M = 256.
@@ -2639,7 +2639,7 @@ along with `.ashift`
 For more information, refer to the
 `PTX ISA <https://docs.nvidia.com/cuda/parallel-thread-execution/#tcgen05-mma-instructions-mma>`__
 
-The following tables describes the possible values of the flag arguments
+The following tables describe the possible values of the flag arguments
 
 `%kind_flag` flag:
 
@@ -2716,14 +2716,14 @@ Overview:
 
 `nvvm.tcgen05.mma.block_scale` has single thread semantics, unlike the collective instructions `nvvm.mma.sync` or the PTX `wgmma.mma_async` instruction. So, a single thread issuing the `nvvm.tcgen05.mma.block_scale` will result in the initiation of the whole matrix multiply and accumulate operation
 
-When `.sp` is specifed, the dimension of A matrix is `M x (K / 2)` and requires specifiying an additional `%spmetadata` argument
+When `.sp` is specified, the dimension of A matrix is `M x (K / 2)` and requires specifying an additional `%spmetadata` argument
 
 The `%collector_usage_a_op_flag` flag specifies the usage of collector buffer for matrix `A`
 
 For more information, refer to the
 `PTX ISA <https://docs.nvidia.com/cuda/parallel-thread-execution/#tcgen05-mma-instructions-mma>`__
 
-The following tables describes the possible values of the flag arguments
+The following tables describe the possible values of the flag arguments
 
 `%cta_group`:
 
diff --git a/llvm/docs/PCSectionsMetadata.rst b/llvm/docs/PCSectionsMetadata.rst
@@ -113,7 +113,7 @@ optimization passes shall preserve PC sections metadata as follows:
     3. Merging will preserve PC sections metadata of one of the two
        instructions (no guarantee on which instruction's metadata is used).
 
-    4. Deletions will loose PC sections metadata.
+    4. Deletions will lose PC sections metadata.
 
 This is similar to debug info, and the ``BuildMI()`` helper provides a
 convenient way to propagate debug info and ``!pcsections`` metadata in the
diff --git a/llvm/docs/QualGroup.rst b/llvm/docs/QualGroup.rst
@@ -181,7 +181,7 @@ Membership Review
 
 To ensure the group remains active and focused, member participation will be reviewed every six months. Inactive members may be removed following this review.
 
-Decision Taking
+Decision Making
 ---------------
 
 The LLVM Qualification Working Group aims to make decisions transparently, collaboratively, and without unnecessary formality. The goal is to maintain efficiency while encouraging broad participation and mutual understanding.
diff --git a/llvm/docs/ReleaseProcess.rst b/llvm/docs/ReleaseProcess.rst
@@ -143,7 +143,7 @@ than bad code generation.
 If the errors are in LLVM itself, please report every single regression found
 as blocker, and all the other bugs as important, but not necessarily blocking
 the release to proceed. They can be set as "known failures" and to be
-fix on a future date.
+fixed on a future date.
 
 .. _pre-release-process:
 
@@ -198,7 +198,7 @@ You should:
 * Compare the results, report all errors on Bugzilla and publish the binary blob
   where the release manager can grab it.
 
-Once the release manages announces that the latest candidate is the good one,
+Once the release manager announces that the latest candidate is the good one,
 you have to pack the ``Release`` (no Asserts) install directory on ``Phase3``
 and that will be the official binary.
 
diff --git a/llvm/docs/ResponseGuide.rst b/llvm/docs/ResponseGuide.rst
@@ -40,7 +40,7 @@ Reports are typically received by email (conduct@llvm.org) or in person from
 the reporter or event CoC response team.
 
 When receiving a report by email, the CoC Committee should acknowledge receipt
-within 24 hours.  The acknowledgement should be understanding and compassionate
+within 24 hours.  The acknowledgment should be understanding and compassionate
 but no commitment should be made on whether this is a violation or which action
 will be taken. Specific guidance is in the checklist below.
 
diff --git a/llvm/docs/Security.rst b/llvm/docs/Security.rst
@@ -95,7 +95,7 @@ Nomination process
 
 Anyone who feels they meet these criteria can nominate themselves, or may be nominated by a third party such as an existing LLVM Security Response Group member. The nomination should state whether the nominee is nominated as an individual, researcher, or as a vendor contact. It should clearly describe the grounds for nomination.
 
-For the moment, nominations are generally proposed, discussed, and voted on using a github pull request. An `example nomination is available here`_. The use of pull requests helps keep membership discussions open, transparent, and easily accessible to LLVM developers in many ways. If, for any reason, a fully-world-readable nomination seems inappropriate, you may reach out to the LLVM Security Response Group via the `report a vulnerability`_ route, and a discussion can be had about the best way to approach nomination, given the constraints that individuals are under.
+For the moment, nominations are generally proposed, discussed, and voted on using a GitHub pull request. An `example nomination is available here`_. The use of pull requests helps keep membership discussions open, transparent, and easily accessible to LLVM developers in many ways. If, for any reason, a fully-world-readable nomination seems inappropriate, you may reach out to the LLVM Security Response Group via the `report a vulnerability`_ route, and a discussion can be had about the best way to approach nomination, given the constraints that individuals are under.
 
 Choosing new members
 --------------------
