forked from OSchip/llvm-project
[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
3c7f740f28
commit
e334a3a60f
|
@ -1708,7 +1708,7 @@ tables.
|
||||||
|
|
||||||
Additional information can be added to the maps. To avoid conflicts,
|
Additional information can be added to the maps. To avoid conflicts,
|
||||||
any key names should be prefixed by "*vendor-name*." where
|
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
|
tool that generates the information. The prefix is abbreviated to
|
||||||
simply "." when it appears within a map that has been added by the
|
simply "." when it appears within a map that has been added by the
|
||||||
same *vendor-name*.
|
same *vendor-name*.
|
||||||
|
|
|
@ -292,7 +292,7 @@ Notes for frontends
|
||||||
Notes for optimizers
|
Notes for optimizers
|
||||||
Optimizers not aware of atomics can treat this like a nothrow call. It is
|
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
|
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.
|
operation to before it.
|
||||||
|
|
||||||
Notes for code generation
|
Notes for code generation
|
||||||
|
|
|
@ -270,7 +270,7 @@ couple specific suggestions:
|
||||||
I Still Can't Find What I'm Looking For
|
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
|
of metadata which provides the optimization hint you need. Such extensions are
|
||||||
relatively common and are generally well received by the community. You will
|
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
|
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
|
G_PTRTOINT
|
||||||
^^^^^^^^^^
|
^^^^^^^^^^
|
||||||
|
|
||||||
Convert an pointer to an integer.
|
Convert a pointer to an integer.
|
||||||
|
|
||||||
.. code-block:: none
|
.. 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
|
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
|
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
|
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.
|
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
|
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
|
#. If the musttail call appears in a function with the ``"thunk"`` attribute
|
||||||
and the caller and callee both have varargs, than any unprototyped
|
and the caller and callee both have varargs, than any unprototyped
|
||||||
arguments in register or memory are forwarded to the callee. Similarly,
|
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.
|
if a void return type is in use.
|
||||||
|
|
||||||
Both markers imply that the callee does not access allocas from the caller.
|
Both markers imply that the callee does not access allocas from the caller.
|
||||||
|
|
|
@ -40,7 +40,7 @@ Features
|
||||||
ORC provides the following features:
|
ORC provides the following features:
|
||||||
|
|
||||||
- *JIT-linking* links relocatable object files (COFF, ELF, MachO) [1]_ into a
|
- *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
|
contains the JIT session object and jit-linker, or may be another process
|
||||||
(even one running on a different machine or architecture) that communicates
|
(even one running on a different machine or architecture) that communicates
|
||||||
with the JIT via RPC.
|
with the JIT via RPC.
|
||||||
|
@ -97,7 +97,7 @@ JIT API.
|
||||||
|
|
||||||
LLJIT and LLLazyJIT instances can be created using their respective builder
|
LLJIT and LLLazyJIT instances can be created using their respective builder
|
||||||
classes: LLJITBuilder and LLazyJITBuilder. For example, assuming you have a
|
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++
|
.. code-block:: c++
|
||||||
|
|
||||||
|
|
|
@ -329,7 +329,7 @@ table.
|
||||||
|
|
||||||
The ``RegionInfo`` pass detects single entry single exit regions in a function,
|
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
|
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
|
``-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
|
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
|
dbg.values for ``!1`` in the source function have had their operands
|
||||||
(%tval, %fval, %merge) optimized out. Assuming we cannot recover them, we
|
(%tval, %fval, %merge) optimized out. Assuming we cannot recover them, we
|
||||||
might consider this placement of dbg.values:
|
might consider this placement of dbg.values:
|
||||||
|
|
Loading…
Reference in New Issue