[llvm] [llvm] Proofread several *.rst files (PR #165835)
via llvm-commits
llvm-commits at lists.llvm.org
Thu Oct 30 23:18:43 PDT 2025
llvmbot wrote:
<!--LLVM PR SUMMARY COMMENT-->
@llvm/pr-subscribers-llvm-ir
Author: Kazu Hirata (kazutakahirata)
<details>
<summary>Changes</summary>
This patch mechanically replaces:
- "i.e." with "i.e.,"
- "e.g." with "e.g.,"
---
Patch is 45.50 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/165835.diff
3 Files Affected:
- (modified) llvm/docs/CodeGenerator.rst (+20-20)
- (modified) llvm/docs/LangRef.rst (+68-68)
- (modified) llvm/docs/ProgrammersManual.rst (+13-13)
``````````diff
diff --git a/llvm/docs/CodeGenerator.rst b/llvm/docs/CodeGenerator.rst
index fc704a3cdd51f..a74f16d7e9477 100644
--- a/llvm/docs/CodeGenerator.rst
+++ b/llvm/docs/CodeGenerator.rst
@@ -498,7 +498,7 @@ The ``MachineBasicBlock`` class
The ``MachineBasicBlock`` class contains a list of machine instructions
(:raw-html:`<tt>` `MachineInstr`_ :raw-html:`</tt>` instances). It roughly
corresponds to the LLVM code input to the instruction selector, but there can be
-a one-to-many mapping (i.e. one LLVM basic block can map to multiple machine
+a one-to-many mapping (i.e., one LLVM basic block can map to multiple machine
basic blocks). The ``MachineBasicBlock`` class has a "``getBasicBlock``" method,
which returns the LLVM basic block that it comes from.
@@ -522,7 +522,7 @@ LLVM code generator can model sequences of instructions as MachineInstr
bundles. A MI bundle can model a VLIW group / pack which contains an arbitrary
number of parallel instructions. It can also be used to model a sequential list
of instructions (potentially with data dependencies) that cannot be legally
-separated (e.g. ARM Thumb2 IT blocks).
+separated (e.g., ARM Thumb2 IT blocks).
Conceptually a MI bundle is a MI with a number of other MIs nested within:
@@ -583,8 +583,8 @@ Packing / bundling of MachineInstrs for VLIW architectures should
generally be done as part of the register allocation super-pass. More
specifically, the pass which determines what MIs should be bundled
together should be done after code generator exits SSA form
-(i.e. after two-address pass, PHI elimination, and copy coalescing).
-Such bundles should be finalized (i.e. adding BUNDLE MIs and input and
+(i.e., after two-address pass, PHI elimination, and copy coalescing).
+Such bundles should be finalized (i.e., adding BUNDLE MIs and input and
output register MachineOperands) after virtual registers have been
rewritten into physical registers. This eliminates the need to add
virtual register operands to BUNDLE instructions which would
@@ -615,7 +615,7 @@ The ``MCStreamer`` API
----------------------
MCStreamer is best thought of as an assembler API. It is an abstract API which
-is *implemented* in different ways (e.g. to output a ``.s`` file, output an ELF ``.o``
+is *implemented* in different ways (e.g., to output a ``.s`` file, output an ELF ``.o``
file, etc) but whose API corresponds directly to what you see in a ``.s`` file.
MCStreamer has one method per directive, such as EmitLabel, EmitSymbolAttribute,
switchSection, emitValue (for .byte, .word), etc, which directly correspond to
@@ -631,7 +631,7 @@ directives through MCStreamer.
On the implementation side of MCStreamer, there are two major implementations:
one for writing out a ``.s`` file (MCAsmStreamer), and one for writing out a ``.o``
file (MCObjectStreamer). MCAsmStreamer is a straightforward implementation
-that prints out a directive for each method (e.g. ``EmitValue -> .byte``), but
+that prints out a directive for each method (e.g., ``EmitValue -> .byte``), but
MCObjectStreamer implements a full assembler.
For target-specific directives, the MCStreamer has a MCTargetStreamer instance.
@@ -681,7 +681,7 @@ The ``MCSection`` class
-----------------------
The ``MCSection`` class represents an object-file specific section. It is
-subclassed by object file specific implementations (e.g. ``MCSectionMachO``,
+subclassed by object file specific implementations (e.g., ``MCSectionMachO``,
``MCSectionCOFF``, ``MCSectionELF``) and these are created and uniqued by
MCContext. The MCStreamer has a notion of the current section, which can be
changed with the SwitchToSection method (which corresponds to a ".section"
@@ -696,7 +696,7 @@ The ``MCInst`` class is a target-independent representation of an instruction.
It is a simple class (much more so than `MachineInstr`_) that holds a
target-specific opcode and a vector of MCOperands. MCOperand, in turn, is a
simple discriminated union of three cases: 1) a simple immediate, 2) a target
-register ID, 3) a symbolic expression (e.g. "``Lfoo-Lbar+42``") as an MCExpr.
+register ID, 3) a symbolic expression (e.g., "``Lfoo-Lbar+42``") as an MCExpr.
MCInst is the common currency used to represent machine instructions at the MC
layer. It is the type used by the instruction encoder, the instruction printer,
@@ -711,9 +711,9 @@ The MC layer's object writers support a variety of object formats. Because of
target-specific aspects of object formats each target only supports a subset of
the formats supported by the MC layer. Most targets support emitting ELF
objects. Other vendor-specific objects are generally supported only on targets
-that are supported by that vendor (i.e. MachO is only supported on targets
+that are supported by that vendor (i.e., MachO is only supported on targets
supported by Darwin, and XCOFF is only supported on targets that support AIX).
-Additionally some targets have their own object formats (i.e. DirectX, SPIR-V
+Additionally some targets have their own object formats (i.e., DirectX, SPIR-V
and WebAssembly).
The table below captures a snapshot of object file support in LLVM:
@@ -769,7 +769,7 @@ Introduction to SelectionDAGs
The SelectionDAG provides an abstraction for code representation in a way that
is amenable to instruction selection using automatic techniques
-(e.g. dynamic-programming based optimal pattern matching selectors). It is also
+(e.g., dynamic-programming based optimal pattern matching selectors). It is also
well-suited to other phases of code generation; in particular, instruction
scheduling (SelectionDAG's are very close to scheduling DAGs post-selection).
Additionally, the SelectionDAG provides a host representation where a large
@@ -898,7 +898,7 @@ Initial SelectionDAG Construction
The initial SelectionDAG is na\ :raw-html:`ï`\ vely peephole expanded from
the LLVM input by the ``SelectionDAGBuilder`` class. The intent of this pass
is to expose as much low-level, target-specific details to the SelectionDAG as
-possible. This pass is mostly hard-coded (e.g. an LLVM ``add`` turns into an
+possible. This pass is mostly hard-coded (e.g., an LLVM ``add`` turns into an
``SDNode add`` while a ``getelementptr`` is expanded into the obvious
arithmetic). This pass requires target-specific hooks to lower calls, returns,
varargs, etc. For these features, the :raw-html:`<tt>` `TargetLowering`_
@@ -944,7 +944,7 @@ The Legalize phase is in charge of converting a DAG to only use the operations
that are natively supported by the target.
Targets often have weird constraints, such as not supporting every operation on
-every supported data type (e.g. X86 does not support byte conditional moves and
+every supported data type (e.g., X86 does not support byte conditional moves and
PowerPC does not support sign-extending loads from a 16-bit memory location).
Legalize takes care of this by open-coding another sequence of operations to
emulate the operation ("expansion"), by promoting one type to a larger type that
@@ -995,7 +995,7 @@ SelectionDAG Optimization Phase: the DAG Combiner
The SelectionDAG optimization phase is run multiple times for code generation,
immediately after the DAG is built and once after each legalization. The first
-run of the pass allows the initial code to be cleaned up (e.g. performing
+run of the pass allows the initial code to be cleaned up (e.g., performing
optimizations that depend on knowing that the operators have restricted type
inputs). Subsequent runs of the pass clean up the messy code generated by the
Legalize passes, which allows Legalize to be very simple (it can focus on making
@@ -1120,10 +1120,10 @@ for your target. It has the following strengths:
16-bits of the immediate).
* When using the 'Pat' class to map a pattern to an instruction that has one
- or more complex operands (like e.g. `X86 addressing mode`_), the pattern may
+ or more complex operands (like e.g., `X86 addressing mode`_), the pattern may
either specify the operand as a whole using a ``ComplexPattern``, or else it
may specify the components of the complex operand separately. The latter is
- done e.g. for pre-increment instructions by the PowerPC back end:
+ done e.g., for pre-increment instructions by the PowerPC back end:
::
@@ -1145,13 +1145,13 @@ While it has many strengths, the system currently has some limitations,
primarily because it is a work in progress and is not yet finished:
* Overall, there is no way to define or match SelectionDAG nodes that define
- multiple values (e.g. ``SMUL_LOHI``, ``LOAD``, ``CALL``, etc). This is the
+ multiple values (e.g., ``SMUL_LOHI``, ``LOAD``, ``CALL``, etc). This is the
biggest reason that you currently still *have to* write custom C++ code
for your instruction selector.
* There is no great way to support matching complex addressing modes yet. In
the future, we will extend pattern fragments to allow them to define multiple
- values (e.g. the four operands of the `X86 addressing mode`_, which are
+ values (e.g., the four operands of the `X86 addressing mode`_, which are
currently matched with custom C++ code). In addition, we'll extend fragments
so that a fragment can match multiple different patterns.
@@ -1175,7 +1175,7 @@ SelectionDAG Scheduling and Formation Phase
The scheduling phase takes the DAG of target instructions from the selection
phase and assigns an order. The scheduler can pick an order depending on
-various constraints of the machines (i.e. order for minimal register pressure or
+various constraints of the machines (i.e., order for minimal register pressure or
try to cover instruction latencies). Once an order is established, the DAG is
converted to a list of :raw-html:`<tt>` `MachineInstr`_\s :raw-html:`</tt>` and
the SelectionDAG is destroyed.
@@ -1615,7 +1615,7 @@ Since the MC layer works at the level of abstraction of object files, it doesn't
have a notion of functions, global variables etc. Instead, it thinks about
labels, directives, and instructions. A key class used at this time is the
MCStreamer class. This is an abstract API that is implemented in different ways
-(e.g. to output a ``.s`` file, output an ELF ``.o`` file, etc) that is effectively an
+(e.g., to output a ``.s`` file, output an ELF ``.o`` file, etc) that is effectively an
"assembler API". MCStreamer has one method per directive, such as EmitLabel,
EmitSymbolAttribute, switchSection, etc, which directly correspond to assembly
level directives.
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 1c6823be44dcb..54c7d0fdfbf18 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -159,7 +159,7 @@ There are two kinds of escapes.
* ``\\`` represents a single ``\`` character.
* ``\`` followed by two hexadecimal characters (0-9, a-f, or A-F)
- represents the byte with the given value (e.g. ``\00`` represents a
+ represents the byte with the given value (e.g., ``\00`` represents a
null byte).
To represent a ``"`` character, use ``\22``. (``\"`` will end the string
@@ -168,7 +168,7 @@ with a trailing ``\``.)
Newlines do not terminate string constants; strings can span multiple
lines.
-The interpretation of string constants (e.g. their character encoding)
+The interpretation of string constants (e.g., their character encoding)
depends on context.
@@ -330,7 +330,7 @@ added in the future:
the function (as does normal C).
"``fastcc``" - The fast calling convention
This calling convention attempts to make calls as fast as possible
- (e.g. by passing things in registers). This calling convention
+ (e.g., by passing things in registers). This calling convention
allows the target to use whatever tricks it wants to produce fast
code for the target, without having to conform to an externally
specified ABI (Application Binary Interface). `Tail calls can only
@@ -465,7 +465,7 @@ added in the future:
This calling convention doesn't preserve any general registers. So all
general registers are caller saved registers. It also uses all general
registers to pass arguments. This attribute doesn't impact non-general
- purpose registers (e.g. floating point registers, on X86 XMMs/YMMs).
+ purpose registers (e.g., floating point registers, on X86 XMMs/YMMs).
Non-general purpose registers still follow the standard C calling
convention. Currently it is for x86_64 and AArch64 only.
"``cxx_fast_tlscc``" - The `CXX_FAST_TLS` calling convention for access functions
@@ -700,7 +700,7 @@ Unstable pointer representation
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Pointers in this address space have an *unspecified* bitwise representation
-(i.e. not backed by a fixed integer). The bitwise pattern of such pointers is
+(i.e., not backed by a fixed integer). The bitwise pattern of such pointers is
allowed to change in a target-specific way. For example, this could be a pointer
type used with copying garbage collection where the garbage collector could
update the pointer at any time in the collection sweep.
@@ -903,7 +903,7 @@ size is unknown at compile time. They are allowed in structs to facilitate
intrinsics returning multiple values. Generally, structs containing scalable
vectors are not considered "sized" and cannot be used in loads, stores, allocas,
or GEPs. The only exception to this rule is for structs that contain scalable
-vectors of the same type (e.g. ``{<vscale x 2 x i32>, <vscale x 2 x i32>}``
+vectors of the same type (e.g., ``{<vscale x 2 x i32>, <vscale x 2 x i32>}``
contains the same type while ``{<vscale x 2 x i32>, <vscale x 2 x i64>}``
doesn't). These kinds of structs (we may call them homogeneous scalable vector
structs) are considered sized and can be used in loads, stores, allocas, but
@@ -1221,7 +1221,7 @@ sections.
Note that certain IR constructs like global variables and functions may
create COMDATs in the object file in addition to any which are specified using
COMDAT IR. This arises when the code generator is configured to emit globals
-in individual sections (e.g. when `-data-sections` or `-function-sections`
+in individual sections (e.g., when `-data-sections` or `-function-sections`
is supplied to `llc`).
.. _namedmetadatastructure:
@@ -1722,7 +1722,7 @@ Currently, only the following parameter attributes are defined:
The function parameter marked with this attribute is the alignment in bytes of the
newly allocated block returned by this function. The returned value must either have
the specified alignment or be the null pointer. The return value MAY be more aligned
- than the requested alignment, but not less aligned. Invalid (e.g. non-power-of-2)
+ than the requested alignment, but not less aligned. Invalid (e.g., non-power-of-2)
alignments are permitted for the allocalign parameter, so long as the returned pointer
is null. This attribute may only be applied to integer parameters.
@@ -1989,7 +1989,7 @@ functions will use the same set of attributes. In the degenerate case of a
group will capture the important command line flags used to build that file.
An attribute group is a module-level object. To use an attribute group, an
-object references the attribute group's ID (e.g. ``#37``). An object may refer
+object references the attribute group's ID (e.g., ``#37``). An object may refer
to more than one attribute group. In that situation, the attributes from the
different groups are merged.
@@ -2222,7 +2222,7 @@ For example:
- ``errnomem``: This refers to accesses to the ``errno`` variable.
- The default access kind (specified without a location prefix) applies to
all locations that haven't been specified explicitly, including those that
- don't currently have a dedicated location kind (e.g. accesses to globals
+ don't currently have a dedicated location kind (e.g., accesses to globals
or captured pointers).
If the ``memory`` attribute is not specified, then ``memory(readwrite)``
@@ -2713,7 +2713,7 @@ For example:
``mustprogress``
This attribute indicates that the function is required to return, unwind,
- or interact with the environment in an observable way e.g. via a volatile
+ or interact with the environment in an observable way e.g., via a volatile
memory access, I/O, or other synchronization. The ``mustprogress``
attribute is intended to model the requirements of the first section of
[intro.progress] of the C++ Standard. As a consequence, a loop in a
@@ -2851,7 +2851,7 @@ are grouped into a single :ref:`attribute group <attrgrp>`.
with `__attribute__((no_sanitize("memtag")))`,
`__attribute__((disable_sanitizer_instrumentation))`, or included in the
`-fsanitize-ignorelist` file. The AArch64 Globals Tagging pass may remove
- this attribute when it's not possible to tag the global (e.g. it's a TLS
+ this attribute when it's not possible to tag the global (e.g., it's a TLS
variable).
``sanitize_address_dyninit``
This attribute indicates that the global variable, when instrumented with
@@ -3076,7 +3076,7 @@ the behavior is undefined, unless one of the following exceptions applies:
* ``dereferenceable(<n>)`` operand bundles only guarantee the pointer is
dereferenceable at the point of the assumption. The pointer may not be
- dereferenceable at later pointers, e.g. because it could have been freed.
+ dereferenceable at later pointers, e.g., because it could have been freed.
In addition to allowing operand bundles encoding function and parameter
attributes, an assume operand bundle may also encode a ``separate_storage``
@@ -3270,7 +3270,7 @@ as follows:
address space 0.
Note: variable declarations without an address space are always created in
address space 0, this property only affects the default value to be used
- when creating globals without additional contextual information (e.g. in
+ when creating globals without additional contextual information (e.g., in
LLVM passes).
.. _alloca_addrspace:
@@ -3282,7 +3282,7 @@ as follows:
This specifies the properties of a pointer in address space ``as``.
The ``<size>`` parameter specifies the size of the bitwise representation.
For :ref:`non-integral pointers <nointptrtype>` the representation size may
- be larger than the address width of the underlying address space (e.g. to
+ be larger than the address width of the underlying address space (e.g., to
accommodate additional metadata).
The alignment requirements are specified via the ``<abi>`` and
``<pref>``\erred alignments parameters.
@@ -3478,7 +3478,7 @@ variables) may *not* change their size. (``realloc``-style operations do not
change the size of an existing allocated object; instead, they create a new
allocated object. Even if the object is at the same location as the old one, old
pointers cannot be used to access this new object.) However, allocated objects
-can also be created by means not recognized by LLVM, e.g. by directly calling
+can also be created by means not recognized by LLVM, e.g., by directly calling
``mmap``. Those allocated objects are allowed to grow to the right (i.e.,
keeping the same base address, but increasing their size) while maintaining the
validity of existing pointers, as long as they always satisfy the properties
@@ -3632,7 +3632,7 @@ through the return value only:
}
However, we always consider direct inspection of the pointer address
-(e.g. using ``ptrtoint``) to be location-independent. The following example
+(e.g., using ``ptrtoint``) to be location-independent. The following example
is *not* considered a return-only capture, even though the ``ptrtoint``
ultimately only contributes to the return value:
@@ -4145,7 +4145,7 @@ output, given the original flags.
``a * (c / b)`` can be rewritten into ``a / (b / c)``.
``contract``
- Allow floating-point contraction (e.g. fusing a multiply followed by an
+ Allow floating-point contraction (e.g., fusing a multiply followed by an
addition into a fused multiply-and-add). This does not enable reassociation
to form arbitrary contractions. For example, ``(a*b) + (c*d) + e`` can not
be transformed into ``(a*b) + ((c*d) + e)`` to create two fma operations.
@@ -4440,7 +4440,7 @@ the default globals address space and ``...
[truncated]
``````````
</details>
https://github.com/llvm/llvm-project/pull/165835
More information about the llvm-commits
mailing list