diff --git a/llvm/docs/HowToBuildWindowsItaniumPrograms.rst b/llvm/docs/HowToBuildWindowsItaniumPrograms.rst index d932d9dd00bfd..a18df992adf10 100644 --- 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 `_. -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 index ca420e709d556..507d1de84c5d5 100644 --- 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 index ac03f31b77ddf..39ae169c0c50f 100644 --- 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 index bd55e49b502d8..0f6f638f545a8 100644 --- 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 index dac642f1ffc65..9e397a977f298 100644 --- 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 index 820cc1cfd02ee..83d68d5fe4bee 100644 --- 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 index 05315a82b55a1..29799079d37cd 100644 --- 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 index 9e0c2cc9f6227..68335ef7753b1 100644 --- 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 index 2443835ea2fff..de4d30e251d4b 100644 --- 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 index 0f070c6644748..bcecca64f6891 100644 --- 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 index 39f0556aef5a2..f2b168f6cb0e3 100644 --- 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 `__ -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 `__ -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 index 4238ce687e3c3..4602ef0c60b32 100644 --- 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 index 0e73ec5c8be78..01c1f6f9d0032 100644 --- 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 index 69a209cbc66d8..82f841f8d62c5 100644 --- 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 index 56dc5e9831994..779684a275a81 100644 --- 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 index d95b55217aef5..7678e58ff6daf 100644 --- 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 --------------------