[llvm] a31b389 - [docs] Fix typos

Kazu Hirata via llvm-commits llvm-commits at lists.llvm.org
Sun Aug 9 19:45:04 PDT 2020


Author: Kazu Hirata
Date: 2020-08-09T19:31:49-07:00
New Revision: a31b3893c72d7f30b05fc42a26690a331ca7b6ed

URL: https://github.com/llvm/llvm-project/commit/a31b3893c72d7f30b05fc42a26690a331ca7b6ed
DIFF: https://github.com/llvm/llvm-project/commit/a31b3893c72d7f30b05fc42a26690a331ca7b6ed.diff

LOG: [docs] Fix typos

Added: 
    

Modified: 
    llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst
    llvm/docs/AMDGPUUsage.rst
    llvm/docs/AliasAnalysis.rst
    llvm/docs/BugLifeCycle.rst
    llvm/docs/CMake.rst
    llvm/docs/CommandGuide/llvm-extract.rst
    llvm/docs/ExceptionHandling.rst
    llvm/docs/GlobalISel/GMIR.rst
    llvm/docs/GlobalISel/GenericOpcode.rst
    llvm/docs/HowToSetUpLLVMStyleRTTI.rst
    llvm/docs/LangRef.rst
    llvm/docs/MemorySSA.rst
    llvm/docs/Phabricator.rst
    llvm/docs/Security.rst
    llvm/docs/TestSuiteGuide.md

Removed: 
    


################################################################################
diff  --git a/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst b/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst
index b6df0c92201a..9887196d330f 100644
--- a/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst
+++ b/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst
@@ -96,7 +96,7 @@ compiler [:ref:`GCC <amdgpu-dwarf-GCC>`] and the Perforce TotalView HPC debugger
 [:ref:`Perforce-TotalView <amdgpu-dwarf-Perforce-TotalView>`].
 
 However, the extensions are intended to be vendor and architecture neutral. They
-are believed to apply to other heterogenous hardware devices including GPUs,
+are believed to apply to other heterogeneous hardware devices including GPUs,
 DSPs, FPGAs, and other specialized hardware. These collectively include similar
 characteristics and requirements as AMDGPU devices. Some of the extension can
 also apply to traditional CPU hardware that supports large vector registers.
@@ -2068,7 +2068,7 @@ register starting at the specified bit offset.
 
     *An implementation may evaluate the call frame information immediately, or
     may defer evaluation until L is accessed by an operation. If evaluation is
-    defered, R and the current context can be recorded in L. When accessed, the
+    deferred, R and the current context can be recorded in L. When accessed, the
     recorded context is used to evaluate the call frame information, not the
     current context of the access operation.*
 

diff  --git a/llvm/docs/AMDGPUUsage.rst b/llvm/docs/AMDGPUUsage.rst
index 3a0df1fad961..45df35697793 100644
--- a/llvm/docs/AMDGPUUsage.rst
+++ b/llvm/docs/AMDGPUUsage.rst
@@ -1139,7 +1139,7 @@ The loaded code object path URI syntax is defined by the following BNF syntax:
 **file_path**
   Is the file's path specified as a URI encoded UTF-8 string. In URI encoding,
   every character that is not in the regular expression ``[a-zA-Z0-9/_.~-]`` is
-  encoded as two uppercase hexidecimal digits proceeded by "%".  Directories in
+  encoded as two uppercase hexadecimal digits proceeded by "%".  Directories in
   the path are separated by "/".
 
 **offset**
@@ -6568,7 +6568,7 @@ On exit from a function:
       VGPR232-239
       VGPR248-255
 
-        *Except the argument registers, the VGPR cloberred and the preserved
+        *Except the argument registers, the VGPR clobbered and the preserved
         registers are intermixed at regular intervals in order to
         get a better occupancy.*
 

diff  --git a/llvm/docs/AliasAnalysis.rst b/llvm/docs/AliasAnalysis.rst
index 191addca79ec..ac2c0a6fab93 100644
--- a/llvm/docs/AliasAnalysis.rst
+++ b/llvm/docs/AliasAnalysis.rst
@@ -81,7 +81,7 @@ In this case, the ``basic-aa`` pass will disambiguate the stores to ``C[0]`` and
 ``C[1]`` because they are accesses to two distinct locations one byte apart, and
 the accesses are each one byte.  In this case, the Loop Invariant Code Motion
 (LICM) pass can use store motion to remove the stores from the loop.  In
-constrast, the following code:
+contrast, the following code:
 
 .. code-block:: c++
 

diff  --git a/llvm/docs/BugLifeCycle.rst b/llvm/docs/BugLifeCycle.rst
index c74aa1d3a62b..f3ed32a209fa 100644
--- a/llvm/docs/BugLifeCycle.rst
+++ b/llvm/docs/BugLifeCycle.rst
@@ -116,7 +116,7 @@ Examples of reasons for resolving are:
     clearly understand the problem being reported (e.g. not reproducible). It is
     fine to resolve such a bug e.g. with resolution WORKSFORME and leaving a
     comment to encourage the reporter to reopen the bug with more information
-    if it's still reproducable on their end.
+    if it's still reproducible on their end.
 
 If a bug is resolved, please fill in the revision number it was fixed in in the
 "Fixed by Commit(s)" field.

diff  --git a/llvm/docs/CMake.rst b/llvm/docs/CMake.rst
index da13726e8ca0..212a8d1cba7e 100644
--- a/llvm/docs/CMake.rst
+++ b/llvm/docs/CMake.rst
@@ -447,7 +447,7 @@ LLVM-specific variables
 **LLVM_STATIC_LINK_CXX_STDLIB**:BOOL
   Statically link to the C++ standard library if possible. This uses the flag
   "-static-libstdc++", but a Clang host compiler will statically link to libc++
-  if used in conjuction with the **LLVM_ENABLE_LIBCXX** flag. Defaults to OFF.
+  if used in conjunction with the **LLVM_ENABLE_LIBCXX** flag. Defaults to OFF.
 
 **LLVM_ENABLE_LLD**:BOOL
   This option is equivalent to `-DLLVM_USE_LINKER=lld`, except during a 2-stage

diff  --git a/llvm/docs/CommandGuide/llvm-extract.rst b/llvm/docs/CommandGuide/llvm-extract.rst
index 17d2e9df1dda..af5d3511fac1 100644
--- a/llvm/docs/CommandGuide/llvm-extract.rst
+++ b/llvm/docs/CommandGuide/llvm-extract.rst
@@ -39,7 +39,7 @@ OPTIONS
 
 **--bb** *basic-block-specifier*
 
- Extract basic blocks(s) specicified in *basic-block-specifier*. May be
+ Extract basic blocks(s) specified in *basic-block-specifier*. May be
  specified multiple times. Each <function:bb[;bb]> specifier pair will create
  a function. If multiple basic blocks are specified in one pair, the first
  block in the sequence should dominate the rest.

diff  --git a/llvm/docs/ExceptionHandling.rst b/llvm/docs/ExceptionHandling.rst
index 3e4ebb4c2a7a..ebd3cbd3d937 100644
--- a/llvm/docs/ExceptionHandling.rst
+++ b/llvm/docs/ExceptionHandling.rst
@@ -530,7 +530,7 @@ on Itanium C++ ABI platforms. The fundamental 
diff erence between the two models
 is that Itanium EH is designed around the idea of "successive unwinding," while
 Windows EH is not.
 
-Under Itanium, throwing an exception typically involes allocating thread local
+Under Itanium, throwing an exception typically involves allocating thread local
 memory to hold the exception, and calling into the EH runtime. The runtime
 identifies frames with appropriate exception handling actions, and successively
 resets the register context of the current thread to the most recently active

diff  --git a/llvm/docs/GlobalISel/GMIR.rst b/llvm/docs/GlobalISel/GMIR.rst
index ca0d60692224..633dfb87adbc 100644
--- a/llvm/docs/GlobalISel/GMIR.rst
+++ b/llvm/docs/GlobalISel/GMIR.rst
@@ -104,7 +104,7 @@ In practice, register files A and B are rarely equal. They can typically store
 the same data but there's usually some restrictions on what operations you can
 do on each register file. A fairly common pattern is for one of them to be
 accessible to integer operations and the other accessible to floating point
-operations. To accomodate this, let's rename A and B to GPR (general purpose
+operations. To accommodate this, let's rename A and B to GPR (general purpose
 registers) and FPR (floating point registers).
 
 We now have some additional constraints that limit us. An operation like G_FMUL

diff  --git a/llvm/docs/GlobalISel/GenericOpcode.rst b/llvm/docs/GlobalISel/GenericOpcode.rst
index db53285312e9..05d33ae817ea 100644
--- a/llvm/docs/GlobalISel/GenericOpcode.rst
+++ b/llvm/docs/GlobalISel/GenericOpcode.rst
@@ -153,7 +153,7 @@ G_BITCAST
 ^^^^^^^^^
 
 Reinterpret a value as a new type. This is usually done without
-changing any bits but this is not always the case due a sublety in the
+changing any bits but this is not always the case due a subtlety in the
 definition of the :ref:`LLVM-IR Bitcast Instruction <i_bitcast>`. It
 is allowed to bitcast between pointers with the same size, but
 
diff erent address spaces.

diff  --git a/llvm/docs/HowToSetUpLLVMStyleRTTI.rst b/llvm/docs/HowToSetUpLLVMStyleRTTI.rst
index 821b00ab7ec0..a20f38ee6a6e 100644
--- a/llvm/docs/HowToSetUpLLVMStyleRTTI.rst
+++ b/llvm/docs/HowToSetUpLLVMStyleRTTI.rst
@@ -430,7 +430,7 @@ template argument and the parent class as the second argument. Any class that
 uses ``RTTIExtends`` must define a ``static char ID`` member, the address of
 which will be used to identify the type.
 
-This open-hierarchy RTTI support should only be used if your use case requries
+This open-hierarchy RTTI support should only be used if your use case requires
 it. Otherwise the standard LLVM RTTI system should be preferred.
 
 .. _`Curiously Recurring Template Idiom`:

diff  --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 4cc67e457cf8..72d46e57d7b7 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -4882,7 +4882,7 @@ raw data, if they aren't equivalent. This is only supported for array types,
 particularly to describe Fortran arrays, which have an array descriptor in
 addition to the array data. Alternatively it can also be DIVariable which
 has the address of the actual raw data. The Fortran language supports pointer
-arrays which can be attached to actual arrays, this attachement between pointer
+arrays which can be attached to actual arrays, this attachment between pointer
 and pointee is called association.  The optional ``associated`` is a
 DIExpression that describes whether the pointer array is currently associated.
 The optional ``allocated`` is a DIExpression that describes whether the
@@ -6915,7 +6915,7 @@ We can expect the record like this:
 
     params: ((param: 0, offset: [0, 7]),(param: 2, offset: [5, 5], calls: ((callee: ^3, param: 1, offset: [-128, 127]))))
 
-The function may access just 8 bytes of the paramenter %0 . ``calls`` is empty,
+The function may access just 8 bytes of the parameter %0 . ``calls`` is empty,
 so the parameter is either not used for function calls or ``offset`` already
 covers all accesses from nested function calls.
 Parameter %1 escapes, so access is unknown.
@@ -16943,7 +16943,7 @@ Back-edge Taken Count (BTC). Thus, these intrinsics perform an element-wise
 less than or equal comparison of VIV with BTC, producing a mask of true/false
 values representing active/inactive vector lanes, except if the VIV overflows
 in which case they return false in the lanes where the VIV overflows.  The
-arguments are scalar types to accomodate scalable vector types, for which it is
+arguments are scalar types to accommodate scalable vector types, for which it is
 unknown what the type of the step vector needs to be that enumerate its
 lanes without overflow.
 

diff  --git a/llvm/docs/MemorySSA.rst b/llvm/docs/MemorySSA.rst
index b448aa10f6aa..d6ab667613a1 100644
--- a/llvm/docs/MemorySSA.rst
+++ b/llvm/docs/MemorySSA.rst
@@ -55,7 +55,7 @@ always introduces a new version of the entire memory and is linked with a single
 ``MemoryDef/MemoryPhi`` which is the version of memory that the new
 version is based on. This implies that there is a *single*
 ``Def`` chain that connects all the ``Def``\ s, either directly
-or indireclty. For example in:
+or indirectly. For example in:
 
 .. code-block:: llvm
 

diff  --git a/llvm/docs/Phabricator.rst b/llvm/docs/Phabricator.rst
index 2493d4eea17d..e0e406136e62 100644
--- a/llvm/docs/Phabricator.rst
+++ b/llvm/docs/Phabricator.rst
@@ -49,7 +49,7 @@ The tool to create and review patches in Phabricator is called
 *Differential*.
 
 Note that you can upload patches created through git, but using `arc` on the
-command line (see previous section) is prefered: it adds more metadata to
+command line (see previous section) is preferred: it adds more metadata to
 Phabricator which are useful for the pre-merge testing system and for
 propagating attribution on commits when someone else has to push it for you.
 

diff  --git a/llvm/docs/Security.rst b/llvm/docs/Security.rst
index 62085cc1c202..2992091d6969 100644
--- a/llvm/docs/Security.rst
+++ b/llvm/docs/Security.rst
@@ -25,7 +25,7 @@ Security Group Members
 The members of the group represent a wide cross-section of the community, and meet the criteria for inclusion below.
 
 * Akila Srinivasan (Apple)
-* Dimitry Andric (invidual; FreeBSD)
+* Dimitry Andric (individual; FreeBSD)
 * Ed Maste (individual; FreeBSD)
 * JF Bastien (Apple)
 * Josh Eads (Sony)

diff  --git a/llvm/docs/TestSuiteGuide.md b/llvm/docs/TestSuiteGuide.md
index 1392ad003367..5fc877477195 100644
--- a/llvm/docs/TestSuiteGuide.md
+++ b/llvm/docs/TestSuiteGuide.md
@@ -185,7 +185,7 @@ benchmarks. CMake can print a list of them:
 
 - `TEST_SUITE_COLLECT_STATS`
 
-  Collect internal LLVM statistics. Appends `-save-stats=obj` when invocing the
+  Collect internal LLVM statistics. Appends `-save-stats=obj` when invoking the
   compiler and makes the lit runner collect and merge the statistic files.
 
 - `TEST_SUITE_RUN_BENCHMARKS`


        


More information about the llvm-commits mailing list