[llvm] ea0ecd6 - [llvm] Proofread *.rst (#168254)
via llvm-commits
llvm-commits at lists.llvm.org
Sun Nov 16 08:09:11 PST 2025
Author: Kazu Hirata
Date: 2025-11-16T08:09:07-08:00
New Revision: ea0ecd63d4aa6ebe0fd11fe48bb707ba024d5a49
URL: https://github.com/llvm/llvm-project/commit/ea0ecd63d4aa6ebe0fd11fe48bb707ba024d5a49
DIFF: https://github.com/llvm/llvm-project/commit/ea0ecd63d4aa6ebe0fd11fe48bb707ba024d5a49.diff
LOG: [llvm] Proofread *.rst (#168254)
This patch is limited to hyphenation to ease the review process.
Added:
Modified:
llvm/docs/AMDGPUUsage.rst
llvm/docs/CodeGenerator.rst
llvm/docs/CommandLine.rst
llvm/docs/LangRef.rst
llvm/docs/SPIRVUsage.rst
llvm/docs/XRayFDRFormat.rst
Removed:
################################################################################
diff --git a/llvm/docs/AMDGPUUsage.rst b/llvm/docs/AMDGPUUsage.rst
index 7267f6bb88a58..bd2884481ee95 100644
--- a/llvm/docs/AMDGPUUsage.rst
+++ b/llvm/docs/AMDGPUUsage.rst
@@ -18986,8 +18986,8 @@ On entry to a function:
objects and to convert this address to a flat address by adding the flat
scratch aperture base address.
- The swizzled SP value is always 4 bytes aligned for the ``r600``
- architecture and 16 byte aligned for the ``amdgcn`` architecture.
+ The swizzled SP value is always 4-byte aligned for the ``r600``
+ architecture and 16-byte aligned for the ``amdgcn`` architecture.
.. note::
@@ -19278,7 +19278,7 @@ describes how the AMDGPU implements function calls:
The CFI will reflect the changed calculation needed to compute the CFA
from SP.
-7. 4 byte spill slots are used in the stack frame. One slot is allocated for an
+7. 4-byte spill slots are used in the stack frame. One slot is allocated for an
emergency spill slot. Buffer instructions are used for stack accesses and
not the ``flat_scratch`` instruction.
diff --git a/llvm/docs/CodeGenerator.rst b/llvm/docs/CodeGenerator.rst
index a74f16d7e9477..a960ea13df60c 100644
--- a/llvm/docs/CodeGenerator.rst
+++ b/llvm/docs/CodeGenerator.rst
@@ -269,7 +269,7 @@ Each register in the processor description has an associated
indicate whether one register overlaps with another).
In addition to the per-register description, the ``TargetRegisterInfo`` class
-exposes a set of processor specific register classes (instances of the
+exposes a set of processor-specific register classes (instances of the
``TargetRegisterClass`` class). Each register class contains sets of registers
that have the same properties (for example, they are all 32-bit integer
registers). Each SSA virtual register created by the instruction selector has
@@ -1295,7 +1295,7 @@ Physical registers, in LLVM, are grouped in *Register Classes*. Elements in the
same register class are functionally equivalent, and can be interchangeably
used. Each virtual register can only be mapped to physical registers of a
particular class. For instance, in the X86 architecture, some virtuals can only
-be allocated to 8 bit registers. A register class is described by
+be allocated to 8-bit registers. A register class is described by
``TargetRegisterClass`` objects. To discover if a virtual register is
compatible with a given physical, this code can be used:
diff --git a/llvm/docs/CommandLine.rst b/llvm/docs/CommandLine.rst
index 00d098745f55b..54a8b0d019399 100644
--- a/llvm/docs/CommandLine.rst
+++ b/llvm/docs/CommandLine.rst
@@ -1262,7 +1262,7 @@ specify boolean properties that modify the option.
.. _cl::DefaultOption:
* The **cl::DefaultOption** modifier is used to specify that the option is a
- default that can be overridden by application specific parsers. For example,
+ default that can be overridden by application-specific parsers. For example,
the ``-help`` alias, ``-h``, is registered this way, so it can be overridden
by applications that need to use the ``-h`` option for another purpose,
either as a regular option or an alias for another option.
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 83d68d5fe4bee..1a8886dd79c9c 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -691,7 +691,7 @@ correctly in a target-specific way.
An example of pointers with non-address bits are the AMDGPU buffer descriptors
which are 160 bits: a 128-bit fat pointer and a 32-bit offset.
-Similarly, CHERI capabilities contain a 32 or 64 bit address as well as the
+Similarly, CHERI capabilities contain a 32- or 64-bit address as well as the
same number of metadata bits, but unlike the AMDGPU buffer descriptors they have
external state in addition to non-address bits.
@@ -19600,7 +19600,7 @@ Syntax:
Overview:
"""""""""
-The '``llvm.canonicalize.*``' intrinsic returns the platform specific canonical
+The '``llvm.canonicalize.*``' intrinsic returns the platform-specific canonical
encoding of a floating-point number. This canonicalization is useful for
implementing certain numeric primitives such as frexp. The canonical encoding is
defined by IEEE-754-2008 to be:
diff --git a/llvm/docs/SPIRVUsage.rst b/llvm/docs/SPIRVUsage.rst
index 5ee3d83bd7aac..aedb6643cf581 100644
--- a/llvm/docs/SPIRVUsage.rst
+++ b/llvm/docs/SPIRVUsage.rst
@@ -216,7 +216,7 @@ Below is a list of supported SPIR-V extensions, sorted alphabetically by their e
* - ``SPV_KHR_float_controls``
- Provides new execution modes to control floating-point computations by overriding an implementation’s default behavior for rounding modes, denormals, signed zero, and infinities.
* - ``SPV_KHR_integer_dot_product``
- - Adds instructions for dot product operations on integer vectors with optional accumulation. Integer vectors includes 4-component vector of 8 bit integers and 4-component vectors of 8 bit integers packed into 32-bit integers.
+ - Adds instructions for dot product operations on integer vectors with optional accumulation. Integer vectors includes 4-component vector of 8-bit integers and 4-component vectors of 8-bit integers packed into 32-bit integers.
* - ``SPV_KHR_linkonce_odr``
- Allows to use the LinkOnceODR linkage type that lets a function or global variable to be merged with other functions or global variables of the same name when linkage occurs.
* - ``SPV_KHR_no_integer_wrap_decoration``
diff --git a/llvm/docs/XRayFDRFormat.rst b/llvm/docs/XRayFDRFormat.rst
index adb9d1e9a85ca..b21b55496d753 100644
--- a/llvm/docs/XRayFDRFormat.rst
+++ b/llvm/docs/XRayFDRFormat.rst
@@ -147,14 +147,14 @@ reconstruct a call stack of instrumented function and their durations.
+---------------+--------------+-----------------------------------------------+
On little-endian machines, the bitfields are ordered from least significant bit
-bit to most significant bit. A reader can read an 8 bit value and apply the mask
+bit to most significant bit. A reader can read an 8-bit value and apply the mask
``0x01`` for the discriminant. Similarly, they can read 32 bits and unsigned
shift right by ``0x04`` to obtain the function_id field.
On big-endian machine, the bitfields are written in order from most significant
-bit to least significant bit. A reader would read an 8 bit value and unsigned
+bit to least significant bit. A reader would read an 8-bit value and unsigned
shift right by 7 bits for the discriminant. The function_id field could be
-obtained by reading a 32 bit value and applying the mask ``0x0FFFFFFF``.
+obtained by reading a 32-bit value and applying the mask ``0x0FFFFFFF``.
Function action types are as follows.
@@ -288,11 +288,11 @@ Its data segment is as follows.
TSCWrap Records
---------------
-Since each function record uses a 32 bit value to represent the number of ticks
+Since each function record uses a 32-bit value to represent the number of ticks
of the timestamp counter since the last reference, it is possible for this value
to overflow, particularly for sparsely instrumented binaries.
-When this delta would not fit into a 32 bit representation, a reference absolute
+When this delta would not fit into a 32-bit representation, a reference absolute
timestamp counter record is written in the form of a TSCWrap record.
Its data segment is as follows.
More information about the llvm-commits
mailing list