caio/clang-p2996
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[llvm] Fix typos in documentation (#140275)

Browse Source 
Co-authored-by: Matt Arsenault <arsenm2@gmail.com>
This commit is contained in:
Kazu Hirata
2025-05-16 12:37:43 -07:00
committed by GitHub
parent dd4a73069c
commit ad6bb70773
10 changed files with 23 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
llvm/docs/AMDGPUUsage.rst
View File

@@ -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.

2
llvm/docs/CIBestPractices.rst
View File

@@ -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

2
llvm/docs/CMake.rst
View File

@@ -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

16
llvm/docs/CodeGenerator.rst
View File

@@ -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

4
llvm/docs/Coroutines.rst
View File

@@ -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:
""""""""""

2
llvm/docs/CoverageMappingFormat.rst
View File

@@ -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
========

2
llvm/docs/DeveloperPolicy.rst
View File

@@ -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>`_

2
llvm/docs/ExtendingLLVM.rst
View File

@@ -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``:

6
llvm/docs/InstrProfileFormat.rst
View File

@@ -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

4
llvm/docs/InterfaceExportAnnotations.rst
View File

@@ -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);
};