[docs] NFC: Fix typos in documents

[kiszk]

Summary

"the the" -> "the"
"an" -> "a"

[hans]

Thanks! I just added a few comments.
Do you have commit access, or will you need someone to commit this for you?

llvm/docs/LangRef.rst

10304

I think it should be "to the" here.

llvm/docs/ORCv2.rst

43

I think it should be "at runtime".

[kiszk]

• address review comments
• rebase with master

[kiszk]

Thank you for your comments. I have just addressed them.

Since I do not have commit rights to the repository yet, could someone commit this change if it is OK?
Kazuaki Ishizaki <[e-mail]>

[hans]

Looks good to me. I'll commit it for you.

llvm/docs/AMDGPUUsage.rst

 The metadata is represented as Message Pack formatted binary data (see
 [MsgPack]_). The top level is a Message Pack map that includes the
 keys defined in table
 :ref:`amdgpu-amdhsa-code-object-metadata-map-table-v3` and referenced
 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*.
 
   .. table:: AMDHSA Code Object V3 Metadata Map
      :name: amdgpu-amdhsa-code-object-metadata-map-table-v3
 
      ================= ============== ========= =======================================

llvm/docs/Atomics.rst

 Notes for frontends
   If you are writing a frontend which uses this directly, use with caution.
   Release only provides a semantic guarantee when paired with a Acquire
   operation.
 
 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
   See the section on Acquire; a fence before the relevant operation is usually
   sufficient for Release. Note that a store-store fence is not sufficient to
   implement Release semantics; store-store fences are generally not exposed to
   IR because they are extremely difficult to use correctly.
 

llvm/docs/Frontend/PerformanceTips.rst

 #. A useful sanity check to run is to run your optimized IR back through the
    -O2 pipeline again.  If you see noticeable improvement in the resulting IR,
    you likely need to adjust your pass order.
 
 
 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
 others if you wish to contribute it upstream.
 
 You should also consider describing the problem you're facing on `llvm-dev
 <http://lists.llvm.org/mailman/listinfo/llvm-dev>`_ and asking for advice.
 It's entirely possible someone has encountered your problem before and can

llvm/docs/GlobalISel/GenericOpcode.rst

 
 .. code-block:: none
 
   %1:_(p0) = G_INTTOPTR %0:_(s32)
 
 G_PTRTOINT
 ^^^^^^^^^^
 
-Convert an pointer to an integer.
+Convert a pointer to an integer.
 
 .. code-block:: none
 
   %1:_(s32) = G_PTRTOINT %0:_(p0)
 
 G_BITCAST
 ^^^^^^^^^
 

llvm/docs/HowToBuildWithPGO.rst

 to other subprojects, such as LLD.
 
 
 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
 a specific large piece of software), please do read the section below on
 'benchmark' selection.
 
 Please note that this script is only tested on a few Linux distros. Patches to
 add support for other platforms, as always, are highly appreciated. :)

llvm/docs/LangRef.rst

#. The optional ``tail`` and ``musttail`` markers indicate that the optimizers
 
    #. The call will not cause unbounded stack growth if it is part of a
       recursive cycle in the call graph.
    #. Arguments with the :ref:`inalloca <attr_inalloca>` attribute are
       forwarded in place.
    #. 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 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.
    The ``tail`` marker additionally implies that the callee does not access
    varargs from the caller. Calls marked ``musttail`` must obey the following
    additional  rules:
 
    - The call must immediately precede a :ref:`ret <i_ret>` instruction,

llvm/docs/ORCv2.rst

 of these contexts as possible.
 
 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 a 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.
 
 - *LLVM IR compilation*, which is provided by off the shelf components
   (IRCompileLayer, SimpleCompiler, ConcurrentIRCompiler) that make it easy to
   add LLVM IR to a JIT'd process.
 

 The LLLazyJIT extends LLJIT and adds a CompileOnDemandLayer to enable lazy
 compilation of LLVM IR. When an LLVM IR module is added via the addLazyIRModule
 method, function bodies in that module will not be compiled until they are first
 called. LLLazyJIT aims to provide a replacement of LLVM's original (pre-MCJIT)
 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++
 
   // Try to detect the host arch and construct an LLJIT instance.
   auto JIT = LLJITBuilder().create();
 
   // If we could not construct an instance, return an error.
   if (!JIT)

llvm/docs/Passes.rst

 that this analysis explicitly does not include types only used by the symbol
 table.
 
 ``-regions``: Detect single entry single exit regions
 -----------------------------------------------------
 
 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
 ------------------------------------------------
 
 The ``ScalarEvolution`` analysis can be used to analyze and catagorize scalar
 expressions in loops.  It specializes in recognizing general induction
 variables, representing them with the abstract and opaque ``SCEV`` class.
 Given this analysis, trip counts of loops and other important properties can be

llvm/docs/SourceLevelDebugging.rst

entry:
     %g = call i32 @gazonk()
     %addoper = select i1 %cond, i32 11, i32 12
     %plusten = add i32 %bar, %addoper
     %toret = add i32 %plusten, %g
     ret i32 %toret
   }
 
 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:
 
 .. code-block:: llvm
 
   define i32 @foo(i32 %bar, i1 %cond) {
   entry: