RPCSX/llvm
1
0
Fork 0
mirror of https://github.com/RPCSX/llvm.git synced 2024-11-23 11:49:50 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

fix some various typos in the doc

Browse Source 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274449 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Sylvestre Ledru 2016-07-02 19:28:40 +00:00
parent 3e60eeae91
commit e0f2f6011e
7 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/Atomics.rst
View File

@ -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)::

4
docs/LangRef.rst
View File

@ -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

2
docs/ReportingGuide.rst
View File

@ -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

2
docs/TableGen/LangRef.rst
View File

@ -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
-----

4
docs/tutorial/BuildingAJIT1.rst
View File

@ -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,

2
docs/tutorial/BuildingAJIT2.rst
View File

@ -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

4
docs/tutorial/LangImpl08.rst
View File

@ -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.