[llvm] Fix typos in documentation #140275
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@llvm/pr-subscribers-coroutines @llvm/pr-subscribers-backend-amdgpu Author: Kazu Hirata (kazutakahirata) ChangesFull diff: https://github.com/llvm/llvm-project/pull/140275.diff 10 Files Affected:
diff --git a/llvm/docs/AMDGPUUsage.rst b/llvm/docs/AMDGPUUsage.rst
index 3751bb3a332da..f6298fb0fa1de 100644
--- 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
index 0f2d446673448..9ccf39e350d5b 100644
--- 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 revising 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
index c5744ea0f2ecf..d861eed8ac5ea 100644
--- 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
index 70e4b7eef9599..020eb09ba7e1e 100644
--- 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,13 +2207,13 @@ 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
@@ -2221,7 +2221,7 @@ 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
index f64029547e648..7472c68a70df4 100644
--- 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
index 96bdf8fa71be7..438fd54ca7bdb 100644
--- 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
index ccd8e31fdb658..6b60812df83bd 100644
--- 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
index 3965112a20f90..50f0af3fafc4c 100644
--- 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
index 3b33c09f8c7a2..bd55e49b502d8 100644
--- 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
index 0b8c768b2b508..afea5b461d16c 100644
--- 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);
};
|
arsenm
reviewed
May 16, 2025
Co-authored-by: Matt Arsenault <[email protected]>
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/10/builds/5519 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/11/builds/15312 Here is the relevant piece of the build log for the reference |
|
LLVM Buildbot has detected a new failure on builder Full details are available at: https://lab.llvm.org/buildbot/#/builders/195/builds/9131 Here is the relevant piece of the build log for the reference |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.