[llvm] [llvm] Proofread CodeGenerator.rst (PR #156814)
Kazu Hirata via llvm-commits
llvm-commits at lists.llvm.org
Wed Sep 3 23:29:05 PDT 2025
https://github.com/kazutakahirata created https://github.com/llvm/llvm-project/pull/156814
None
>From c10adaabf3cd255ab6f55322ad546c56de3b8f9a Mon Sep 17 00:00:00 2001
From: Kazu Hirata <kazu at google.com>
Date: Wed, 3 Sep 2025 08:52:08 -0700
Subject: [PATCH] [llvm] Proofread CodeGenerator.rst
---
llvm/docs/CodeGenerator.rst | 44 ++++++++++++++++++-------------------
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/llvm/docs/CodeGenerator.rst b/llvm/docs/CodeGenerator.rst
index eda8bf6489bda..7486054b55c9f 100644
--- a/llvm/docs/CodeGenerator.rst
+++ b/llvm/docs/CodeGenerator.rst
@@ -90,8 +90,8 @@ This design has two important implications. The first is that LLVM can support
completely non-traditional code generation targets. For example, the C backend
does not require register allocation, instruction selection, or any of the other
standard components provided by the system. As such, it only implements these
-two interfaces, and does its own thing. Note that C backend was removed from the
-trunk since LLVM 3.1 release. Another example of a code generator like this is a
+two interfaces, and does its own thing. Note that the C backend was removed from the
+trunk in the LLVM 3.1 release. Another example of a code generator like this is a
(purely hypothetical) backend that converts LLVM to the GCC RTL form and uses
GCC to emit machine code for a target.
@@ -565,7 +565,7 @@ Conceptually a MI bundle is a MI with a number of other MIs nested within:
MI bundle support does not change the physical representations of
MachineBasicBlock and MachineInstr. All the MIs (including top level and nested
ones) are stored as sequential list of MIs. The "bundled" MIs are marked with
-the 'InsideBundle' flag. A top level MI with the special BUNDLE opcode is used
+the 'InsideBundle' flag. A top-level MI with the special BUNDLE opcode is used
to represent the start of a bundle. It's legal to mix BUNDLE MIs with individual
MIs that are not inside bundles nor represent bundles.
@@ -575,7 +575,7 @@ The MachineBasicBlock iterator has been modified to skip over bundled MIs to
enforce the bundle-as-a-single-unit concept. An alternative iterator
instr_iterator has been added to MachineBasicBlock to allow passes to iterate
over all of the MIs in a MachineBasicBlock, including those which are nested
-inside bundles. The top level BUNDLE instruction must have the correct set of
+inside bundles. The top-level BUNDLE instruction must have the correct set of
register MachineOperand's that represent the cumulative inputs and outputs of
the bundled MIs.
@@ -602,7 +602,7 @@ level, devoid of "high level" information like "constant pools", "jump tables",
"global variables" or anything like that. At this level, LLVM handles things
like label names, machine instructions, and sections in the object file. The
code in this layer is used for a number of important purposes: the tail end of
-the code generator uses it to write a .s or .o file, and it is also used by the
+the code generator uses it to write a ``.s`` or ``.o`` file, and it is also used by the
llvm-mc tool to implement standalone machine code assemblers and disassemblers.
This section describes some of the important classes. There are also a number
@@ -615,8 +615,8 @@ 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
-file, etc) but whose API correspond directly to what you see in a .s file.
+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
assembly level directives. It also has an EmitInstruction method, which is used
@@ -629,7 +629,7 @@ higher level LLVM IR and Machine* constructs down to the MC layer, emitting
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
+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
MCObjectStreamer implements a full assembler.
@@ -639,7 +639,7 @@ Each target that needs it defines a class that inherits from it and is a lot
like MCStreamer itself: It has one method per directive and two classes that
inherit from it, a target object streamer and a target asm streamer. The target
asm streamer just prints it (``emitFnStart -> .fnstart``), and the object
-streamer implement the assembler logic for it.
+streamer implements the assembler logic for it.
To make llvm use these classes, the target initialization must call
TargetRegistry::RegisterAsmStreamer and TargetRegistry::RegisterMCObjectStreamer
@@ -667,7 +667,7 @@ MCSymbols are created by MCContext and uniqued there. This means that MCSymbols
can be compared for pointer equivalence to find out if they are the same symbol.
Note that pointer inequality does not guarantee the labels will end up at
different addresses though. It's perfectly legal to output something like this
-to the .s file:
+to the ``.s`` file:
::
@@ -685,7 +685,7 @@ 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"
-directive in a .s file).
+directive in a ``.s`` file).
.. _MCInst:
@@ -887,7 +887,7 @@ bundled into a single scheduling-unit node, and with immediate operands and
other nodes that aren't relevant for scheduling omitted.
The option ``-filter-view-dags`` allows to select the name of the basic block
-that you are interested to visualize and filters all the previous
+that you are interested in visualizing and filters all the previous
``view-*-dags`` options.
.. _Build initial DAG:
@@ -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 datatype (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
@@ -1077,7 +1077,7 @@ for your target. It has the following strengths:
if your patterns make sense or not.
* It can handle arbitrary constraints on operands for the pattern match. In
- particular, it is straight-forward to say things like "match any immediate
+ particular, it is straightforward to say things like "match any immediate
that is a 13-bit sign-extended value". For examples, see the ``immSExt16``
and related ``tblgen`` classes in the PowerPC backend.
@@ -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.
@@ -1648,7 +1648,7 @@ three important things that you have to implement for your target:
Finally, at your choosing, you can also implement a subclass of MCCodeEmitter
which lowers MCInst's into machine code bytes and relocations. This is
-important if you want to support direct .o file emission, or would like to
+important if you want to support direct ``.o`` file emission, or would like to
implement an assembler for your target.
Emitting function stack size information
@@ -1678,7 +1678,7 @@ Instructions in a VLIW target can typically be mapped to multiple functional
units. During the process of packetizing, the compiler must be able to reason
about whether an instruction can be added to a packet. This decision can be
complex since the compiler has to examine all possible mappings of instructions
-to functional units. Therefore to alleviate compilation-time complexity, the
+to functional units. Therefore, to alleviate compilation-time complexity, the
VLIW packetizer parses the instruction classes of a target and generates tables
at compiler build time. These tables can then be queried by the provided
machine-independent API to determine if an instruction can be accommodated in a
@@ -1729,7 +1729,7 @@ Instruction Alias Processing
----------------------------
Once the instruction is parsed, it enters the MatchInstructionImpl function.
-The MatchInstructionImpl function performs alias processing and then does actual
+The MatchInstructionImpl function performs alias processing and then performs actual
matching.
Alias processing is the phase that canonicalizes different lexical forms of the
@@ -1934,7 +1934,7 @@ following constraints are met:
* Caller and callee have matching return type or the callee result is not used.
-* If any of the callee arguments are being passed in stack, they must be
+* If any of the callee arguments are being passed on the stack, they must be
available in caller's own incoming argument stack and the frame offsets must
be the same.
@@ -2074,7 +2074,7 @@ character per operand with an optional special size. For example:
The PowerPC backend
-------------------
-The PowerPC code generator lives in the lib/Target/PowerPC directory. The code
+The PowerPC code generator lives in the ``lib/Target/PowerPC`` directory. The code
generation is retargetable to several variations or *subtargets* of the PowerPC
ISA; including ppc32, ppc64 and altivec.
@@ -2140,7 +2140,7 @@ 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.
-32 bit linkage area:
+32-bit linkage area:
:raw-html:`<table border="1" cellspacing="0">`
:raw-html:`<tr>`
@@ -2169,7 +2169,7 @@ GPR, thus the linkage area is 24 bytes long in 32-bit mode and 48 bytes in
:raw-html:`</tr>`
:raw-html:`</table>`
-64 bit linkage area:
+64-bit linkage area:
:raw-html:`<table border="1" cellspacing="0">`
:raw-html:`<tr>`
More information about the llvm-commits
mailing list