[Mlir-commits] [mlir] 286a7a4 - [mlir][docs] Fix obvious spelling mistakes in documentation

Fri Oct 29 00:19:15 PDT 2021

Author: Markus Böck
Date: 2021-10-29T09:19:11+02:00
New Revision: 286a7a4023361aa63230596e88366c3d86776921

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

LOG: [mlir][docs] Fix obvious spelling mistakes in documentation

Added: 
    

Modified: 
    mlir/docs/Bindings/Python.md
    mlir/docs/DataLayout.md
    mlir/docs/DeclarativeRewrites.md
    mlir/docs/Dialects/LLVM.md
    mlir/docs/LangRef.md
    mlir/docs/ShapeInference.md
    mlir/docs/TargetLLVMIR.md
    mlir/docs/Tools/mlir-reduce.md

Removed: 
    


################################################################################
diff  --git a/mlir/docs/Bindings/Python.md b/mlir/docs/Bindings/Python.md
index 7fdc8402d03e2..3e1d373794889 100644

--- a/mlir/docs/Bindings/Python.md
+++ b/mlir/docs/Bindings/Python.md
@@ -419,7 +419,7 @@ if operation1.results.types == operation2.operand.types:
 ```
 
 `OpView` subclasses for specific operations may provide leaner accessors to
-properties of an opeation. For example, named attributes, operand and results
+properties of an operation. For example, named attributes, operand and results
 are usually accessible as properties of the `OpView` subclass with the same
 name, such as `operation.const_value` instead of
 `operation.attributes["const_value"]`. If this name is a reserved Python
@@ -441,7 +441,7 @@ thus iterable, which provides access to the blocks. One can also use the
 `.blocks` property.
 
 ```python
-# Regions are directly iterable and give acceess to blocks.
+# Regions are directly iterable and give access to blocks.
 for block1, block2 in zip(operation.regions[0], operation.regions[0].blocks)
   assert block1 == block2
 ```
@@ -460,7 +460,7 @@ alive. This operation can be accessed using the `.owner` property.
 Attributes and types are (mostly) immutable context-owned objects. They are
 represented as either:
 
--   an opaque `Attribute` or `Type` object supporting printing and comparsion;
+-   an opaque `Attribute` or `Type` object supporting printing and comparison;
     or
 -   a concrete subclass thereof with access to properties of the attribute or
     type.
@@ -606,7 +606,7 @@ Python bindings also support IR creation and manipulation.
 
 Operations can be created given a `Location` and an optional `InsertionPoint`.
 It is often easier to user context managers to specify locations and insertion
-points for several operations created in a row as decribed above.
+points for several operations created in a row as described above.
 
 Concrete operations can be created by using constructors of the corresponding
 `OpView` subclasses. The generic, default form of the constructor accepts:
@@ -917,7 +917,7 @@ from ._my_dialect_ops_gen import *
 When the python bindings need to locate a wrapper module, they consult the
 `dialect_search_path` and use it to find an appropriately named module. For the
 main repository, this search path is hard-coded to include the `mlir.dialects`
-module, which is where wrappers are emitted by the abobe build rule. Out of tree
+module, which is where wrappers are emitted by the above build rule. Out of tree
 dialects and add their modules to the search path by calling:
 
 ```python

diff  --git a/mlir/docs/DataLayout.md b/mlir/docs/DataLayout.md
index d12091a3b63bd..abf53e25c5e27 100644
--- a/mlir/docs/DataLayout.md
+++ b/mlir/docs/DataLayout.md
@@ -289,4 +289,4 @@ The [DLTI](Dialects/DLTI.md) dialect provides the attributes implementing
 `DataLayoutSpecInterface` and `DataLayoutEntryInterface`, as well as a dialect
 attribute that can be used to attach the specification to a given operation. The
 verifier of this attribute triggers those of the specification and checks the
-compatiblity of nested specifications.
+compatibility of nested specifications.

diff  --git a/mlir/docs/DeclarativeRewrites.md b/mlir/docs/DeclarativeRewrites.md
index e1c6daec302c1..94c0100d41973 100644
--- a/mlir/docs/DeclarativeRewrites.md
+++ b/mlir/docs/DeclarativeRewrites.md
@@ -408,7 +408,7 @@ In the above, `$_self` is substituted by the defining operation of the first
 operand of OneAttrOp. Note that we don't support binding name to
 `NativeCodeCall` in the source pattern. To carry some return values from a
 helper function, put the names (constraint is optional) in the parameter list
-and they will be bound to the variables with correspoding type. Then these names
+and they will be bound to the variables with corresponding type. Then these names
 must be either passed by reference or pointer to the variable used as argument
 so that the matched value can be returned. In the same example, `$val` will be
 bound to a variable with `Attribute` type (as `I32Attr`) and the type of the

diff  --git a/mlir/docs/Dialects/LLVM.md b/mlir/docs/Dialects/LLVM.md
index 03253b35c6f62..376b8b6e1bb68 100644
--- a/mlir/docs/Dialects/LLVM.md
+++ b/mlir/docs/Dialects/LLVM.md
@@ -155,7 +155,7 @@ have an optional _linkage_ attribute derived from LLVM IR
 [linkage types](https://llvm.org/docs/LangRef.html#linkage-types). Linkage is
 specified by the same keyword as in LLVM IR and is located between the operation
 name (`llvm.func` or `llvm.global`) and the symbol name. If no linkage keyword
-is present, `external` linkage is assumed by default. Linakge is _distinct_ from
+is present, `external` linkage is assumed by default. Linkage is _distinct_ from
 MLIR symbol visibility.
 
 ### Attribute Pass-Through

diff  --git a/mlir/docs/LangRef.md b/mlir/docs/LangRef.md
index 5bee47f014df6..c3818d33fff24 100644
--- a/mlir/docs/LangRef.md
+++ b/mlir/docs/LangRef.md
@@ -439,7 +439,7 @@ For example, in a function body, block terminators must either branch to a
 
diff erent block, or return from a function where the types of the `return`
 arguments must match the result types of the function signature. Similarly, the
 function arguments must match the types and count of the region arguments. In
-general, operations with regions can define these correspondances arbitrarily.
+general, operations with regions can define these correspondences arbitrarily.
 
 ### Value Scoping
 

diff  --git a/mlir/docs/ShapeInference.md b/mlir/docs/ShapeInference.md
index 4914b66729522..af2eb3419be04 100644
--- a/mlir/docs/ShapeInference.md
+++ b/mlir/docs/ShapeInference.md
@@ -215,7 +215,7 @@ impose a particular shape inference approach here.
 1.  Flow sensitive shape functions;
     *   To enable scalable/cheap shape inference, the shape functions do not
         intend to provide flow sensitive information. This facility could
-        potentially be built as part of shome higher order analysis that reuse
+        potentially be built as part of some higher order analysis that reuse
         the shape functions/constraints due to the shape functions.
 1.  All static functions are usable for dynamic/unknown shapes;
     *   More involved computations can be performed with statically known shapes
@@ -264,7 +264,7 @@ whatever language is the priority of this proposal.
 None. There are multiple 
diff erent shape inference approaches that we could
 layer on top of these. From the most basic (always return unranked), to more
 useful (return fixed shape for constant inputs/arguments) to the more advanced
-(create logical conjuctions of algebraic statements between symbolic named
+(create logical conjunctions of algebraic statements between symbolic named
 values).
 
 ### Open points

diff  --git a/mlir/docs/TargetLLVMIR.md b/mlir/docs/TargetLLVMIR.md
index 523b04fef6440..f56ada65ea8ab 100644
--- a/mlir/docs/TargetLLVMIR.md
+++ b/mlir/docs/TargetLLVMIR.md
@@ -146,7 +146,7 @@ memref<1x? x vector<4xf32>> -> !llvm.struct<(ptr<vector<4 x f32>>,
 #### Unranked MemRef Types
 
 Unranked memref types are converted to LLVM dialect literal structure type that
-contains the ynamic information associated with the memref object, referred to
+contains the dynamic information associated with the memref object, referred to
 as *unranked descriptor*. It contains:
 
 1.  a converted `index`-typed integer representing the dynamic rank of the

diff  --git a/mlir/docs/Tools/mlir-reduce.md b/mlir/docs/Tools/mlir-reduce.md
index 44d47d9a82bdc..b60cdd799ba0c 100644
--- a/mlir/docs/Tools/mlir-reduce.md
+++ b/mlir/docs/Tools/mlir-reduce.md
@@ -16,7 +16,7 @@ use it, the first thing you need to do is, provide a command which tells if an
 input is interesting, e.g., exhibits the characteristics that you would like to
 focus on. For example, you may want to see if `mlir-opt` invocation fails after
 it runs on the certain MLIR input. Afterwards, select your reduction strategy
-then `mlir-reduce` will do the remining works for you.
+then `mlir-reduce` will do the remaining works for you.
 
 ## How to Use it
 
@@ -120,7 +120,7 @@ int main(int argc, char **argv) {
 `mlir-reduce` is missing several features,
 
 *   `-reduction-tree` now only supports `Single-Path` traversal mode, extends it
-with 
diff erent traveral strategies may reduce the input better.
-*   Produce the optimial result when interruped. The reduction process may take
+with 
diff erent traversal strategies may reduce the input better.
+*   Produce the optimal result when interrupted. The reduction process may take
 a quite long time, it'll be better to get an optimal result so far while an
-interrup is triggered.
+interrupt is triggered.


        
