aboutsummaryrefslogtreecommitdiff
path: root/docs/CodeGenerator.rst
diff options
context:
space:
mode:
authorDimitry Andric <dim@FreeBSD.org>2015-05-27 18:44:32 +0000
committerDimitry Andric <dim@FreeBSD.org>2015-05-27 18:44:32 +0000
commit5a5ac124e1efaf208671f01c46edb15f29ed2a0b (patch)
treea6140557876943cdd800ee997c9317283394b22c /docs/CodeGenerator.rst
parentf03b5bed27d0d2eafd68562ce14f8b5e3f1f0801 (diff)
Diffstat (limited to 'docs/CodeGenerator.rst')
-rw-r--r--docs/CodeGenerator.rst6
1 files changed, 3 insertions, 3 deletions
diff --git a/docs/CodeGenerator.rst b/docs/CodeGenerator.rst
index 7e5b6eb76392..75d40db958c0 100644
--- a/docs/CodeGenerator.rst
+++ b/docs/CodeGenerator.rst
@@ -1340,7 +1340,7 @@ found before being stored or after being reloaded.
If the indirect strategy is used, after all the virtual registers have been
mapped to physical registers or stack slots, it is necessary to use a spiller
object to place load and store instructions in the code. Every virtual that has
-been mapped to a stack slot will be stored to memory after been defined and will
+been mapped to a stack slot will be stored to memory after being defined and will
be loaded before being used. The implementation of the spiller tries to recycle
load/store instructions, avoiding unnecessary instructions. For an example of
how to invoke the spiller, see ``RegAllocLinearScan::runOnMachineFunction`` in
@@ -1353,7 +1353,7 @@ With very rare exceptions (e.g., function calls), the LLVM machine code
instructions are three address instructions. That is, each instruction is
expected to define at most one register, and to use at most two registers.
However, some architectures use two address instructions. In this case, the
-defined register is also one of the used register. For instance, an instruction
+defined register is also one of the used registers. For instance, an instruction
such as ``ADD %EAX, %EBX``, in X86 is actually equivalent to ``%EAX = %EAX +
%EBX``.
@@ -1578,7 +1578,7 @@ three important things that you have to implement for your target:
correspond to. The MCInsts that are generated by this are fed into the
instruction printer or the encoder.
-Finally, at your choosing, you can also implement an subclass of MCCodeEmitter
+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
implement an assembler for your target.