mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-22 02:33:06 +01:00
fix some various typos in the doc
llvm-svn: 274449
This commit is contained in:
parent
05ba7e2547
commit
29d94cf96e
@ -578,7 +578,7 @@ runtime support library.
|
||||
LLVM will emit a call to an appropriate ``__sync_*`` routine if the target
|
||||
ISelLowering code has set the corresponding ``ATOMIC_CMPXCHG``, ``ATOMIC_SWAP``,
|
||||
or ``ATOMIC_LOAD_*`` operation to "Expand", and if it has opted-into the
|
||||
availablity of those library functions via a call to ``initSyncLibcalls()``.
|
||||
availability of those library functions via a call to ``initSyncLibcalls()``.
|
||||
|
||||
The full set of functions that may be called by LLVM is (for ``N`` being 1, 2,
|
||||
4, 8, or 16)::
|
||||
|
@ -1427,7 +1427,7 @@ example:
|
||||
generated for this function needs to follow certain conventions that
|
||||
make it possible for a runtime function to patch over it later.
|
||||
The exact effect of this attribute depends on its string value,
|
||||
for which there currently is one legal possiblity:
|
||||
for which there currently is one legal possibility:
|
||||
|
||||
* ``"prologue-short-redirect"`` - This style of patchable
|
||||
function is intended to support patching a function prologue to
|
||||
@ -4338,7 +4338,7 @@ DIMacro
|
||||
|
||||
``DIMacro`` nodes represent definition or undefinition of a macro identifiers.
|
||||
The ``name:`` field is the macro identifier, followed by macro parameters when
|
||||
definining a function-like macro, and the ``value`` field is the token-string
|
||||
defining a function-like macro, and the ``value`` field is the token-string
|
||||
used to expand the macro identifier.
|
||||
|
||||
.. code-block:: llvm
|
||||
|
@ -33,7 +33,7 @@ needed) email conduct@llvm.org.
|
||||
intended to discourage this self enforcement of community norms. Instead,
|
||||
the mechanisms described here are intended to supplement any self
|
||||
enforcement within the community. They provide avenues for handling severe
|
||||
cases or cases where the reporting party does not whish to respond directly
|
||||
cases or cases where the reporting party does not wish to respond directly
|
||||
for any reason.
|
||||
|
||||
Filing a report
|
||||
|
@ -154,7 +154,7 @@ programmer.
|
||||
.. productionlist::
|
||||
Declaration: `Type` `TokIdentifier` ["=" `Value`]
|
||||
|
||||
It assigns the value to the identifer.
|
||||
It assigns the value to the identifier.
|
||||
|
||||
Types
|
||||
-----
|
||||
|
@ -47,7 +47,7 @@ code for that chapter and replace it with optimization support in our JIT class
|
||||
in Chapter #2.
|
||||
|
||||
Finally, a word on API generations: ORC is the 3rd generation of LLVM JIT API.
|
||||
It was preceeded by MCJIT, and before that by the (now deleted) legacy JIT.
|
||||
It was preceded by MCJIT, and before that by the (now deleted) legacy JIT.
|
||||
These tutorials don't assume any experience with these earlier APIs, but
|
||||
readers acquainted with them will see many familiar elements. Where appropriate
|
||||
we will make this connection with the earlier APIs explicit to help people who
|
||||
@ -140,7 +140,7 @@ to build our LLVM compiler instance; A DataLayout, DL, which will be used for
|
||||
symbol mangling (more on that later), and two ORC *layers*: an
|
||||
ObjectLinkingLayer and a IRCompileLayer. We'll be talking more about layers in
|
||||
the next chapter, but for now you can think of them as analogous to LLVM
|
||||
Passes: they wrap up useful JIT utilities behind an easy to compose interace.
|
||||
Passes: they wrap up useful JIT utilities behind an easy to compose interface.
|
||||
The first layer, ObjectLinkingLayer, is the foundation of our JIT: it takes
|
||||
in-memory object files produced by a compiler and links them on the fly to make
|
||||
them executable. This JIT-on-top-of-a-linker design was introduced in MCJIT,
|
||||
|
@ -286,7 +286,7 @@ these choices will have different performance characteristics: Doing work
|
||||
eagerly means the JIT takes longer up-front, but proceeds smoothly once this is
|
||||
done. Deferring work allows the JIT to get up-and-running quickly, but will
|
||||
force the JIT to pause and wait whenever some code or data is needed that hasn't
|
||||
already been procesed.
|
||||
already been processed.
|
||||
|
||||
Our current REPL is eager: Each function definition is optimized and compiled as
|
||||
soon as it's typed in. If we were to make the transform layer lazy (but not
|
||||
|
@ -46,7 +46,7 @@ returns the target triple of the current machine.
|
||||
|
||||
LLVM doesn't require us to to link in all the target
|
||||
functionality. For example, if we're just using the JIT, we don't need
|
||||
the assembly printers. Similarly, if we're only targetting certain
|
||||
the assembly printers. Similarly, if we're only targeting certain
|
||||
architectures, we can only link in the functionality for those
|
||||
architectures.
|
||||
|
||||
@ -80,7 +80,7 @@ Target Machine
|
||||
==============
|
||||
|
||||
We will also need a ``TargetMachine``. This class provides a complete
|
||||
machine description of the machine we're targetting. If we want to
|
||||
machine description of the machine we're targeting. If we want to
|
||||
target a specific feature (such as SSE) or a specific CPU (such as
|
||||
Intel's Sandylake), we do so now.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user