[llvm] [llvm] Proofread *.rst (PR #168254)

Sat Nov 15 23:32:06 PST 2025

llvmbot wrote:




@llvm/pr-subscribers-backend-spir-v

Author: Kazu Hirata (kazutakahirata)

<details>
<summary>Changes</summary>

This patch is limited to hyphenation to ease the review process.


---
Full diff: https://github.com/llvm/llvm-project/pull/168254.diff


6 Files Affected:

- (modified) llvm/docs/AMDGPUUsage.rst (+3-3) 
- (modified) llvm/docs/CodeGenerator.rst (+2-2) 
- (modified) llvm/docs/CommandLine.rst (+1-1) 
- (modified) llvm/docs/LangRef.rst (+2-2) 
- (modified) llvm/docs/SPIRVUsage.rst (+1-1) 
- (modified) llvm/docs/XRayFDRFormat.rst (+5-5) 


``````````diff

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.

``````````

</details>


https://github.com/llvm/llvm-project/pull/168254
