mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-22 02:33:06 +01:00
[docs] NFC: Fix typos in documents
"the the" -> "the" "an" -> "a" Patch by Kazuaki Ishizaki <ishizaki@jp.ibm.com>! Differential revision: https://reviews.llvm.org/D72091
This commit is contained in:
parent
e8c8bfd37b
commit
c7ebd85525
@ -1708,7 +1708,7 @@ tables.
|
||||
|
||||
Additional information can be added to the maps. To avoid conflicts,
|
||||
any key names should be prefixed by "*vendor-name*." where
|
||||
``vendor-name`` can be the the name of the vendor and specific vendor
|
||||
``vendor-name`` can be the name of the vendor and specific vendor
|
||||
tool that generates the information. The prefix is abbreviated to
|
||||
simply "." when it appears within a map that has been added by the
|
||||
same *vendor-name*.
|
||||
|
@ -292,7 +292,7 @@ Notes for frontends
|
||||
Notes for optimizers
|
||||
Optimizers not aware of atomics can treat this like a nothrow call. It is
|
||||
also possible to move loads from after a Release store or read-modify-write
|
||||
operation to before it, and move non-Release stores from after an Release
|
||||
operation to before it, and move non-Release stores from after a Release
|
||||
operation to before it.
|
||||
|
||||
Notes for code generation
|
||||
|
@ -270,7 +270,7 @@ couple specific suggestions:
|
||||
I Still Can't Find What I'm Looking For
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you didn't find what you were looking for above, consider proposing an piece
|
||||
If you didn't find what you were looking for above, consider proposing a piece
|
||||
of metadata which provides the optimization hint you need. Such extensions are
|
||||
relatively common and are generally well received by the community. You will
|
||||
need to ensure that your proposal is sufficiently general so that it benefits
|
||||
|
@ -143,7 +143,7 @@ Convert an integer to a pointer.
|
||||
G_PTRTOINT
|
||||
^^^^^^^^^^
|
||||
|
||||
Convert an pointer to an integer.
|
||||
Convert a pointer to an integer.
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
|
@ -18,7 +18,7 @@ Using the script
|
||||
|
||||
We have a script at ``utils/collect_and_build_with_pgo.py``. This script is
|
||||
tested on a few Linux flavors, and requires a checkout of LLVM, Clang, and
|
||||
compiler-rt. Despite the the name, it performs four clean builds of Clang, so it
|
||||
compiler-rt. Despite the name, it performs four clean builds of Clang, so it
|
||||
can take a while to run to completion. Please see the script's ``--help`` for
|
||||
more information on how to run it, and the different options available to you.
|
||||
If you want to get the most out of PGO for a particular use-case (e.g. compiling
|
||||
|
@ -10308,7 +10308,7 @@ This instruction requires several arguments:
|
||||
#. If the musttail call appears in a function with the ``"thunk"`` attribute
|
||||
and the caller and callee both have varargs, than any unprototyped
|
||||
arguments in register or memory are forwarded to the callee. Similarly,
|
||||
the return value of the callee is returned the the caller's caller, even
|
||||
the return value of the callee is returned to the caller's caller, even
|
||||
if a void return type is in use.
|
||||
|
||||
Both markers imply that the callee does not access allocas from the caller.
|
||||
|
@ -40,7 +40,7 @@ Features
|
||||
ORC provides the following features:
|
||||
|
||||
- *JIT-linking* links relocatable object files (COFF, ELF, MachO) [1]_ into a
|
||||
target process an runtime. The target process may be the same process that
|
||||
target process at runtime. The target process may be the same process that
|
||||
contains the JIT session object and jit-linker, or may be another process
|
||||
(even one running on a different machine or architecture) that communicates
|
||||
with the JIT via RPC.
|
||||
@ -97,7 +97,7 @@ JIT API.
|
||||
|
||||
LLJIT and LLLazyJIT instances can be created using their respective builder
|
||||
classes: LLJITBuilder and LLazyJITBuilder. For example, assuming you have a
|
||||
module ``M`` loaded on an ThreadSafeContext ``Ctx``:
|
||||
module ``M`` loaded on a ThreadSafeContext ``Ctx``:
|
||||
|
||||
.. code-block:: c++
|
||||
|
||||
|
@ -329,7 +329,7 @@ table.
|
||||
|
||||
The ``RegionInfo`` pass detects single entry single exit regions in a function,
|
||||
where a region is defined as any subgraph that is connected to the remaining
|
||||
graph at only two spots. Furthermore, an hierarchical region tree is built.
|
||||
graph at only two spots. Furthermore, a hierarchical region tree is built.
|
||||
|
||||
``-scalar-evolution``: Scalar Evolution Analysis
|
||||
------------------------------------------------
|
||||
|
@ -471,7 +471,7 @@ perhaps, be optimized into the following code:
|
||||
}
|
||||
|
||||
What ``llvm.dbg.value`` intrinsics should be placed to represent the original variable
|
||||
locations in this code? Unfortunately the the second, third and fourth
|
||||
locations in this code? Unfortunately the second, third and fourth
|
||||
dbg.values for ``!1`` in the source function have had their operands
|
||||
(%tval, %fval, %merge) optimized out. Assuming we cannot recover them, we
|
||||
might consider this placement of dbg.values:
|
||||
|
Loading…
Reference in New Issue
Block a user