diff --git a/llvm/docs/AMDGPUUsage.rst b/llvm/docs/AMDGPUUsage.rst --- a/llvm/docs/AMDGPUUsage.rst +++ b/llvm/docs/AMDGPUUsage.rst @@ -1708,7 +1708,7 @@ 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*. diff --git a/llvm/docs/Atomics.rst b/llvm/docs/Atomics.rst --- a/llvm/docs/Atomics.rst +++ b/llvm/docs/Atomics.rst @@ -292,7 +292,7 @@ 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 diff --git a/llvm/docs/Frontend/PerformanceTips.rst b/llvm/docs/Frontend/PerformanceTips.rst --- a/llvm/docs/Frontend/PerformanceTips.rst +++ b/llvm/docs/Frontend/PerformanceTips.rst @@ -270,7 +270,7 @@ 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 diff --git a/llvm/docs/GlobalISel/GenericOpcode.rst b/llvm/docs/GlobalISel/GenericOpcode.rst --- a/llvm/docs/GlobalISel/GenericOpcode.rst +++ b/llvm/docs/GlobalISel/GenericOpcode.rst @@ -143,7 +143,7 @@ G_PTRTOINT ^^^^^^^^^^ -Convert an pointer to an integer. +Convert a pointer to an integer. .. code-block:: none diff --git a/llvm/docs/HowToBuildWithPGO.rst b/llvm/docs/HowToBuildWithPGO.rst --- a/llvm/docs/HowToBuildWithPGO.rst +++ b/llvm/docs/HowToBuildWithPGO.rst @@ -18,7 +18,7 @@ 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 diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst --- a/llvm/docs/LangRef.rst +++ b/llvm/docs/LangRef.rst @@ -10308,7 +10308,7 @@ #. 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. diff --git a/llvm/docs/ORCv2.rst b/llvm/docs/ORCv2.rst --- a/llvm/docs/ORCv2.rst +++ b/llvm/docs/ORCv2.rst @@ -40,7 +40,7 @@ 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 @@ 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++ diff --git a/llvm/docs/Passes.rst b/llvm/docs/Passes.rst --- a/llvm/docs/Passes.rst +++ b/llvm/docs/Passes.rst @@ -329,7 +329,7 @@ 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 ------------------------------------------------ diff --git a/llvm/docs/SourceLevelDebugging.rst b/llvm/docs/SourceLevelDebugging.rst --- a/llvm/docs/SourceLevelDebugging.rst +++ b/llvm/docs/SourceLevelDebugging.rst @@ -471,7 +471,7 @@ } 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: