[llvm] Fix typos in documentation (NFC)

kazutakahirata · kazutakahirata · commit e8fa9014cce4 · 2021-02-27T10:09:23.000-08:00
diff --git a/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst b/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst
@@ -500,7 +500,7 @@ If a DWARF expression is ill-formed, then the result is undefined.
 The following sections detail the rules for when a DWARF expression is
 ill-formed or results in an evaluation error.
 
-A DWARF expression can either be encoded as a operation expression (see
+A DWARF expression can either be encoded as an operation expression (see
 :ref:`amdgpu-dwarf-operation-expressions`), or as a location list expression
 (see :ref:`amdgpu-dwarf-location-list-expressions`).
 
diff --git a/llvm/docs/AMDGPUModifierSyntax.rst b/llvm/docs/AMDGPUModifierSyntax.rst
@@ -422,7 +422,7 @@ GFX7, GFX8 and GFX10 only.
     r128                Specifies 128 bits texture resource size.
     =================== ================================================
 
-.. WARNING:: Using this modifier should descrease *rsrc* operand size from 8 to 4 dwords, but assembler does not currently support this feature.
+.. WARNING:: Using this modifier should decrease *rsrc* operand size from 8 to 4 dwords, but assembler does not currently support this feature.
 
 tfe
 ~~~
@@ -831,7 +831,7 @@ GFX10 only.
 
 Unified format is a replacement for :ref:`data<amdgpu_synid_format_data>`
 and :ref:`numeric<amdgpu_synid_format_num>` formats. For compatibility with older ISA,
-:ref:`syntax with data and numeric formats<amdgpu_synid_fmt>` is still accepthed
+:ref:`syntax with data and numeric formats<amdgpu_synid_fmt>` is still accepted
 provided that the combination of formats can be mapped to a unified format.
 
 Supported unified formats and equivalent combinations of data and numeric formats
diff --git a/llvm/docs/AMDGPUUsage.rst b/llvm/docs/AMDGPUUsage.rst
@@ -528,7 +528,7 @@ AMDGPU supports target IDs. See `Clang Offload Bundler
 description. The AMDGPU target specific information is:
 
 **processor**
-  Is a AMDGPU processor or alternative processor name specified in
+  Is an AMDGPU processor or alternative processor name specified in
   :ref:`amdgpu-processor-table`. The non-canonical form target ID allows both
   the primary processor and alternative processor names. The canonical form
   target ID only allow the primary processor name.
@@ -4580,7 +4580,7 @@ There are different methods used for initializing flat scratch:
 Private Segment Buffer
 ++++++++++++++++++++++
 
-Private Segment Buffer SGPR register is used to initilize 4 SGPRs
+Private Segment Buffer SGPR register is used to initialize 4 SGPRs
 that are used as a V# to access scratch. CP uses the value provided by the
 runtime. It is used, together with Scratch Wavefront Offset as an offset, to
 access the private memory space using a segment address. See
@@ -6042,7 +6042,7 @@ For GFX90A:
     wavefront.
 
   * No special action is required for coherence between wavefronts in the same
-    work-group since they exeute on the same CU. The exception is when in
+    work-group since they execute on the same CU. The exception is when in
     tgsplit execution mode as wavefronts of the same work-group can be in
     different CUs and so a ``buffer_wbinvl1_vol`` is required as described in
     the following item.
diff --git a/llvm/docs/BitCodeFormat.rst b/llvm/docs/BitCodeFormat.rst
@@ -264,7 +264,7 @@ Abbreviated Record Encoding
 
 ``[<abbrevid>, fields...]``
 
-An abbreviated record is a abbreviation id followed by a set of fields that are
+An abbreviated record is an abbreviation id followed by a set of fields that are
 encoded according to the `abbreviation definition`_.  This allows records to be
 encoded significantly more densely than records encoded with the
 `UNABBREV_RECORD`_ type, and allows the abbreviation types to be specified in
diff --git a/llvm/docs/CommandGuide/llvm-install-name-tool.rst b/llvm/docs/CommandGuide/llvm-install-name-tool.rst
@@ -35,7 +35,7 @@ the same `<rpath>` value.
  Change an install name ``<old_install_name>`` to ``<new_install_name>`` in the
  specified binary. Can be specified multiple times to change multiple dependent shared
  library install names. Option is ignored if ``<old_install_name>`` is not listed
- in the specfied binary.
+ in the specified binary.
 
 .. option:: -delete_rpath <rpath>
 
@@ -54,7 +54,7 @@ the same `<rpath>` value.
 .. option:: -id <name>
 
  Change shared library's identification name under LC_ID_DYLIB to ``<name>`` in the
- specfied binary. If specified multiple times, only the last :option:`-id` option is
+ specified binary. If specified multiple times, only the last :option:`-id` option is
  selected. Option is ignored if the specified Mach-O binary is not a dynamic shared library.
 
 .. option:: -rpath <old_rpath> <new_rpath>
diff --git a/llvm/docs/CommandGuide/tblgen.rst b/llvm/docs/CommandGuide/tblgen.rst
@@ -126,7 +126,7 @@ llvm-tblgen Options
 
 .. option:: -gen-attrs
 
-  Geneerate attributes.
+  Generate attributes.
 
 .. option:: -gen-automata
 
@@ -218,7 +218,7 @@ llvm-tblgen Options
 
 .. option:: -gicombiner-show-expansions
 
-  Make -gen-global-isel-combiner use C++ comments to indicate occurences
+  Make -gen-global-isel-combiner use C++ comments to indicate occurrences
   of code expansion.
 
 .. option:: -gicombiner-stop-after-build
diff --git a/llvm/docs/CommandLine.rst b/llvm/docs/CommandLine.rst
@@ -387,7 +387,7 @@ now is:
     -quiet        - Don't print informational messages
 
 In this case, it is sort of awkward that flag names correspond directly to enum
-names, because we probably don't want a enum definition named "``g``" in our
+names, because we probably don't want an enum definition named "``g``" in our
 program.  Because of this, we can alternatively write this example like this:
 
 .. code-block:: c++
diff --git a/llvm/docs/Coroutines.rst b/llvm/docs/Coroutines.rst
@@ -190,7 +190,7 @@ coroutine. Therefore an async coroutine returns `void`.
   define swiftcc void @async_coroutine(i8* %async.ctxt, i8*, i8*) {
   }
 
-Values live accross a suspend point need to be stored in the coroutine frame to
+Values live across a suspend point need to be stored in the coroutine frame to
 be available in the continuation function. This frame is stored as a tail to the
 `async context`.
 
@@ -1206,7 +1206,7 @@ The third argument is the `async context` argument in the current coroutine.
 The fourth argument is the address of the `async function pointer` struct.
 Lowering will update the context size requirement in this struct by adding the
 coroutine frame size requirement to the initial size requirement as specified by
-the first argument of this intrinisc.
+the first argument of this intrinsic.
 
 
 Semantics:
@@ -1572,7 +1572,7 @@ The second argument is the `context projection function`. It should describe
 how-to restore the `async context` in the continuation function from the first
 argument of the continuation function. Its type is `i8* (i8*)`.
 
-The third argument is the function that models tranfer to the callee at the
+The third argument is the function that models transfer to the callee at the
 suspend point. It should take 3 arguments. Lowering will `musttail` call this
 function.
 
diff --git a/llvm/docs/Frontend/PerformanceTips.rst b/llvm/docs/Frontend/PerformanceTips.rst
@@ -81,7 +81,7 @@ Prefer zext over sext when legal
 On some architectures (X86_64 is one), sign extension can involve an extra
 instruction whereas zero extension can be folded into a load.  LLVM will try to
 replace a sext with a zext when it can be proven safe, but if you have
-information in your source language about the range of a integer value, it can
+information in your source language about the range of an integer value, it can
 be profitable to use a zext rather than a sext.
 
 Alternatively, you can :ref:`specify the range of the value using metadata
diff --git a/llvm/docs/JITLink.rst b/llvm/docs/JITLink.rst
@@ -16,7 +16,7 @@ accessible. If it is not, please submit a patch (:doc:`Contributing`) or file a
 bug (:doc:`HowToSubmitABug`).
 
 JITLink is a library for :ref:`jit_linking`. It was built to support the ORC JIT
-APIs and is most commonly accesed via ORC's ObjectLinkingLayer API. JITLink was
+APIs and is most commonly accessed via ORC's ObjectLinkingLayer API. JITLink was
 developed with the aim of supporting the full set of features provided by each
 object format; including static initializers, exception handling, thread local
 variables, and language runtime registration. Supporting these features enables
@@ -520,7 +520,7 @@ certain points by the introduction of JITLink :ref:`passes`:
       working memory and fixed up. Passes run at this stage can make late
       optimizations to the graph and content based on address layout.
 
-      Notable use cases: GOT and PLT relaxation, where GOT and PLT acceses are
+      Notable use cases: GOT and PLT relaxation, where GOT and PLT accesses are
       bypassed for fixup targets that are directly accessible under the assigned
       memory layout.
 
@@ -787,7 +787,7 @@ for them by an ``ObjectLinkingLayer`` instance, but they can be created manually
    ``ObjectLinkingLayer`` usually creates ``LinkGraphs``.
 
   #. ``createLinkGraph_<Object-Format>_<Architecture>`` can be used when
-      both the object format and achitecture are known ahead of time.
+      both the object format and architecture are known ahead of time.
 
   #. ``createLinkGraph_<Object-Format>`` can be used when the object format is
      known ahead of time, but the architecture is not. In this case the
@@ -894,7 +894,7 @@ main function using the -args option:
       printf("arg %i is \"%s\"\n", i, argv[i]);
   }
 
-  % cat pring-args-main.c
+  % cat print-args-main.c
   void print_args(int argc, char *argv[]);
 
   int main(int argc, char *argv[]) {
@@ -1093,7 +1093,7 @@ Major outstanding projects include:
 JITLink Availability and Feature Status
 ---------------------------------------
 
-.. list-table:: Avalability and Status
+.. list-table:: Availability and Status
    :widths: 10 30 30 30
    :header-rows: 1
 
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
@@ -4329,7 +4329,7 @@ ARM and ARM's Thumb2 mode:
 - ``L``: An immediate integer whose negation is valid for a data-processing
   instruction. (Can be used with template modifier "``n``" to print the negated
   value).
-- ``M``: A power of two or a integer between 0 and 32.
+- ``M``: A power of two or an integer between 0 and 32.
 - ``N``: Invalid immediate constraint.
 - ``O``: Invalid immediate constraint.
 - ``r``: A general-purpose 32-bit integer register (``r0-r15``).
@@ -4723,7 +4723,7 @@ debug information. There are two metadata primitives: strings and nodes.
 Metadata does not have a type, and is not a value. If referenced from a
 ``call`` instruction, it uses the ``metadata`` type.
 
-All metadata are identified in syntax by a exclamation point ('``!``').
+All metadata are identified in syntax by an exclamation point ('``!``').
 
 .. _metadata-string:
 
@@ -12000,7 +12000,7 @@ arrays in C99.
 Semantics:
 """"""""""
 
-This intrinsic returns a opaque pointer value that can be passed to
+This intrinsic returns an opaque pointer value that can be passed to
 :ref:`llvm.stackrestore <int_stackrestore>`. When an
 ``llvm.stackrestore`` intrinsic is executed with a value saved from
 ``llvm.stacksave``, it effectively restores the state of the stack to
@@ -12053,7 +12053,7 @@ Overview:
       The '``llvm.get.dynamic.area.offset.*``' intrinsic family is used to
       get the offset from native stack pointer to the address of the most
       recent dynamic alloca on the caller's stack. These intrinsics are
-      intendend for use in combination with
+      intended for use in combination with
       :ref:`llvm.stacksave <int_stacksave>` to get a
       pointer to the most recent dynamic alloca. This is useful, for example,
       for AddressSanitizer's stack unpoisoning routines.
@@ -12170,7 +12170,7 @@ Semantics:
 """"""""""
 
 When directly supported, reading the cycle counter should not modify any
-memory. Implementations are allowed to either return a application
+memory. Implementations are allowed to either return an application
 specific value or a system wide value. On backends without support, this
 is lowered to a constant 0.
 
diff --git a/llvm/docs/Lexicon.rst b/llvm/docs/Lexicon.rst
@@ -98,7 +98,7 @@ E
 **ento**
     This namespace houses the
     `Clang Static Analyzer <https://clang.llvm.org/docs/ClangStaticAnalyzer.html>`_.
-    It is an abbreviaton of `entomology <https://en.wikipedia.org/wiki/Entomology>`_.
+    It is an abbreviation of `entomology <https://en.wikipedia.org/wiki/Entomology>`_.
 
       *"Entomology is the scientific study of insects."*
 
diff --git a/llvm/docs/MIRLangRef.rst b/llvm/docs/MIRLangRef.rst
@@ -834,7 +834,7 @@ represented by an empty ``DebugLoc`` object in the machine instruction.
 Fixed variable locations
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
-There are several ways of specifying variable locations. The simpliest is
+There are several ways of specifying variable locations. The simplest is
 describing a variable that is permanently located on the stack. In the stack
 or fixedStack attribute of the machine function, the variable, scope, and
 any qualifying location modifier are provided:
diff --git a/llvm/docs/MemorySSA.rst b/llvm/docs/MemorySSA.rst
@@ -176,7 +176,7 @@ Going from the top down:
   this block could either be ``2`` or ``3``.
 - ``MemoryUse(5)`` notes that ``load i8, i8* %p1`` is a use of memory, and that
   it's clobbered by ``5``.
-- ``4 = MemoryDef(5)`` notes that ``store i8 2, i8* %p2`` is a definition; it's
+- ``4 = MemoryDef(5)`` notes that ``store i8 2, i8* %p2`` is a definition; its
   reaching definition is ``5``.
 - ``MemoryUse(1)`` notes that ``load i8, i8* %p3`` is just a user of memory,
   and the last thing that could clobber this use is above ``while.cond`` (e.g.
@@ -233,7 +233,7 @@ queries ``GlobalsAA``, one that always stops at ``MemoryPhi`` nodes, etc).
 Default walker APIs
 ^^^^^^^^^^^^^^^^^^^
 
-There are two main APIs used to retrive the clobbering access using the walker:
+There are two main APIs used to retrieve the clobbering access using the walker:
 
 -  ``MemoryAccess *getClobberingMemoryAccess(MemoryAccess *MA);`` return the
    clobbering memory access for ``MA``, caching all intermediate results
diff --git a/llvm/docs/MergeFunctions.rst b/llvm/docs/MergeFunctions.rst
@@ -134,7 +134,7 @@ How it could this be done? Just convert each function to a number, and gather
 all of them in a special hash-table. Functions with equal hashes are equal.
 Good hashing means, that every function part must be taken into account. That
 means we have to convert every function part into some number, and then add it
-into the hash. The lookup-up time would be small, but such a approach adds some
+into the hash. The lookup-up time would be small, but such an approach adds some
 delay due to the hashing routine.
 
 Logarithmical search
diff --git a/llvm/docs/ORCv2.rst b/llvm/docs/ORCv2.rst
@@ -829,7 +829,7 @@ Further Future Work
    *speculative* JIT compilation: compilation of code that is not needed yet,
    but which we have reason to believe will be needed in the future. This can be
    used to hide compile latency and improve JIT throughput. A proof-of-concept
-   exmaple of speculative compilation with ORC has already been developed (see
+   example of speculative compilation with ORC has already been developed (see
    ``llvm/examples/SpeculativeJIT``). Future work on this is likely to focus on
    re-using and improving existing profiling support (currently used by PGO) to
    feed speculation decisions, as well as built-in tools to simplify use of
diff --git a/llvm/docs/Passes.rst b/llvm/docs/Passes.rst
@@ -336,7 +336,7 @@ 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
+The ``ScalarEvolution`` analysis can be used to analyze and categorize 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
@@ -1114,7 +1114,7 @@ algorithm:
    return returns something else (like constant 0), and can still be TRE'd.  It
    can be TRE'd if *all other* return instructions in the function return the
    exact same value.
-#. If it can prove that callees do not access theier caller stack frame, they
+#. If it can prove that callees do not access their caller stack frame, they
    are marked as eligible for tail call elimination (by the code generator).
 
 Utility Passes
diff --git a/llvm/docs/ProgrammersManual.rst b/llvm/docs/ProgrammersManual.rst
@@ -2468,7 +2468,7 @@ Basic Inspection and Traversal Routines
 The LLVM compiler infrastructure have many different data structures that may be
 traversed.  Following the example of the C++ standard template library, the
 techniques used to traverse these various data structures are all basically the
-same.  For a enumerable sequence of values, the ``XXXbegin()`` function (or
+same.  For an enumerable sequence of values, the ``XXXbegin()`` function (or
 method) returns an iterator to the start of the sequence, the ``XXXend()``
 function returns an iterator pointing to one past the last valid element of the
 sequence, and there is some ``XXXiterator`` data type that is common between the
diff --git a/llvm/docs/StackMaps.rst b/llvm/docs/StackMaps.rst
@@ -24,7 +24,7 @@ containing the stack map.
 LLVM emits stack map data into the object code within a designated
 :ref:`stackmap-section`. This stack map data contains a record for
 each stack map. The record stores the stack map's instruction address
-and contains a entry for each mapped value. Each entry encodes a
+and contains an entry for each mapped value. Each entry encodes a
 value's location as a register, stack offset, or constant.
 
 A patch point is an instruction address at which space is reserved for
diff --git a/llvm/docs/Statepoints.rst b/llvm/docs/Statepoints.rst
@@ -393,7 +393,7 @@ to unmanaged code. The resulting relocation sequence is:
     ret i8 addrspace(1)* %obj.relocated
   }
 
-During lowering, this will result in a instruction selection DAG that looks
+During lowering, this will result in an instruction selection DAG that looks
 something like:
 
 ::
@@ -703,7 +703,7 @@ Safepoint Semantics & Verification
 
 The fundamental correctness property for the compiled code's
 correctness w.r.t. the garbage collector is a dynamic one.  It must be
-the case that there is no dynamic trace such that a operation
+the case that there is no dynamic trace such that an operation
 involving a potentially relocated pointer is observably-after a
 safepoint which could relocate it.  'observably-after' is this usage
 means that an outside observer could observe this sequence of events
diff --git a/llvm/docs/TableGen/ProgRef.rst b/llvm/docs/TableGen/ProgRef.rst
@@ -509,7 +509,7 @@ primary value. Here are the possible suffixes for some primary *value*.
 The paste operator
 ------------------
 
-The paste operator (``#``) is the only infix operator availabe in TableGen
+The paste operator (``#``) is the only infix operator available in TableGen
 expressions. It allows you to concatenate strings or lists, but has a few
 unusual features.
 
diff --git a/llvm/docs/XRay.rst b/llvm/docs/XRay.rst
@@ -316,7 +316,7 @@ Minimizing Binary Size
 
 XRay supports several different instrumentation points including ``function-entry``,
 ``function-exit``, ``custom``, and ``typed`` points. These can be enabled individually
-using the ``-fxray-instrumentaton-bundle=`` flag. For example if you only wanted to
+using the ``-fxray-instrumentation-bundle=`` flag. For example if you only wanted to
 instrument function entry and custom points you could specify:
 
 ::
diff --git a/llvm/docs/YamlIO.rst b/llvm/docs/YamlIO.rst
@@ -288,7 +288,7 @@ ScalarEnumerationTraits
 -----------------------
 YAML I/O supports translating between in-memory enumerations and a set of string
 values in YAML documents. This is done by specializing ScalarEnumerationTraits<>
-on your enumeration type and define a enumeration() method. 
+on your enumeration type and define an enumeration() method.
 For instance, suppose you had an enumeration of CPUs and a struct with it as 
 a field:
 
@@ -391,7 +391,7 @@ on MyFlags and provide the bit values and their names.
 With the above, YAML I/O (when writing) will test mask each value in the 
 bitset trait against the flags field, and each that matches will
 cause the corresponding string to be added to the flow sequence.  The opposite
-is done when reading and any unknown string values will result in a error. With 
+is done when reading and any unknown string values will result in an error. With
 the above schema, a same valid YAML document is:
 
 .. code-block:: yaml
@@ -439,7 +439,7 @@ to the flow sequence.
 Custom Scalar
 -------------
 Sometimes for readability a scalar needs to be formatted in a custom way. For
-instance your internal data structure may use a integer for time (seconds since
+instance your internal data structure may use an integer for time (seconds since
 some epoch), but in YAML it would be much nicer to express that integer in 
 some time format (e.g. 4-May-2012 10:30pm).  YAML I/O has a way to support  
 custom formatting and parsing of scalar types by specializing ScalarTraits<> on
diff --git a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst
