mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-11-01 15:11:24 +00:00
Fix grammar in documentation.
Patch by Ralph Campbell! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229884 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
parent
f5bbc8ae1a
commit
0f842f925d
@ -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.
|
||||
|
@ -368,7 +368,7 @@ added in the future:
|
||||
|
||||
The idea behind this convention is to support calls to runtime functions
|
||||
that have a hot path and a cold path. The hot path is usually a small piece
|
||||
of code that doesn't many registers. The cold path might need to call out to
|
||||
of code that doesn't use many registers. The cold path might need to call out to
|
||||
another function and therefore only needs to preserve the caller-saved
|
||||
registers, which haven't already been saved by the caller. The
|
||||
`PreserveMost` calling convention is very similar to the `cold` calling
|
||||
@ -521,7 +521,7 @@ Global Variables
|
||||
Global variables define regions of memory allocated at compilation time
|
||||
instead of run-time.
|
||||
|
||||
Global variables definitions must be initialized.
|
||||
Global variable definitions must be initialized.
|
||||
|
||||
Global variables in other translation units can also be declared, in which
|
||||
case they don't have an initializer.
|
||||
@ -666,7 +666,7 @@ predecessors, it also cannot have any :ref:`PHI nodes <i_phi>`.
|
||||
|
||||
LLVM allows an explicit section to be specified for functions. If the
|
||||
target supports it, it will emit functions to the section specified.
|
||||
Additionally, the function can placed in a COMDAT.
|
||||
Additionally, the function can be placed in a COMDAT.
|
||||
|
||||
An explicit alignment may be specified for a function. If not present,
|
||||
or if the alignment is set to zero, the alignment of the function is set
|
||||
@ -674,7 +674,7 @@ by the target to whatever it feels convenient. If an explicit alignment
|
||||
is specified, the function is forced to have at least that much
|
||||
alignment. All alignments must be a power of 2.
|
||||
|
||||
If the ``unnamed_addr`` attribute is given, the address is know to not
|
||||
If the ``unnamed_addr`` attribute is given, the address is known to not
|
||||
be significant and two identical functions can be merged.
|
||||
|
||||
Syntax::
|
||||
@ -716,7 +716,7 @@ The linkage must be one of ``private``, ``internal``, ``linkonce``, ``weak``,
|
||||
``linkonce_odr``, ``weak_odr``, ``external``. Note that some system linkers
|
||||
might not correctly handle dropping a weak symbol that is aliased.
|
||||
|
||||
Alias that are not ``unnamed_addr`` are guaranteed to have the same address as
|
||||
Aliases that are not ``unnamed_addr`` are guaranteed to have the same address as
|
||||
the aliasee expression. ``unnamed_addr`` ones are only guaranteed to point
|
||||
to the same content.
|
||||
|
||||
@ -1782,7 +1782,7 @@ Fast-Math Flags
|
||||
|
||||
LLVM IR floating-point binary ops (:ref:`fadd <i_fadd>`,
|
||||
:ref:`fsub <i_fsub>`, :ref:`fmul <i_fmul>`, :ref:`fdiv <i_fdiv>`,
|
||||
:ref:`frem <i_frem>`) have the following flags that can set to enable
|
||||
:ref:`frem <i_frem>`) have the following flags that can be set to enable
|
||||
otherwise unsafe floating point operations
|
||||
|
||||
``nnan``
|
||||
|
Loading…
Reference in New Issue
Block a user