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

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

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.

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

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

mlir/docs/LangRef.md

@@ -439,7 +439,7 @@ For example, in a function body, block terminators must either branch to a
 different 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
 

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 different 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

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

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 different traveral strategies may reduce the input better.
-*   Produce the optimial result when interruped. The reduction process may take
+with different 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.