[mlir] NFC: fix trivial typos in documents

[kiszk]

I made a mistake that includes old changes

[mravishankar]

Thanks for the edits!

mlir/docs/CAPI.md

 
 Functions primarily operating on an instance of `MlirX` are prefixed with
 `mlirX`. They take the instance being acted upon as their first argument (except
 for creation functions). For example, `mlirOperationGetNumOperands` inspects an
 `MlirOperation`, which it takes as its first operand.
 
 The *ownership* model is encoded in the naming convention as follows.
 
--   By default, the ownership is not transerred.
--   Functions that tranfer the ownership of the result to the caller can be in
+-   By default, the ownership is not transferred.
+-   Functions that transfer the ownership of the result to the caller can be in
     one of two forms:
     *   functions that create a new object have the name `mlirXCreate<...>`, for
         example, `mlirOperationCreate`;
     *   functions that detach an object from a parent object have the name
         `mlirYTake<...>`, for example `mlirOperationStateTakeRegion`.
 -   Functions that take ownership of some of their arguments have the form
     `mlirY<...>OwnedX<...>` where `X` can refer to the type or any other
     sufficiently unique description of the argument, the ownership of which will

 *, intptr_t, void *)` and a pointer to user-defined data. They call the callback
 and supply it with chunks of the string representation, provided as a pointer to
 the first character and a length, and forward the user-defined data unmodified.
 It is up to the caller to allocate memory if the string representation must be
 stored and perform the copy. There is no guarantee that the pointer supplied to
 the callback points to a null-terminated string, the size argument should be
 used to find the end of the string. The callback may be called multiple times
 with consecutive chunks of the string representation (the printing itself is
-bufferred).
+buffered).
 
 *Rationale*: this approach allows the caller to have full control of the
 allocation and avoid unnecessary allocation and copying inside the printer.
 
 For convenience, `mlirXDump(MlirX)` functions are provided to print the given
 object to the standard error stream.
 
 ## Common Patterns
 
 The API adopts the following patterns for recurrent functionality in MLIR.
 
 ### Indexed Components
 
 An object has an _indexed component_ if it has fields accessible using a
 zero-based contiguous integer index, typically arrays. For example, an
-`MlirBlock` has its arguments as a indexed component. An object may have several
-such components. For example, an `MlirOperation` has attributes, operands,
-regions, results and successors.
+`MlirBlock` has its arguments as an indexed component. An object may have
+several such components. For example, an `MlirOperation` has attributes,
+operands, regions, results and successors.
 
 For indexed components, the following pair of functions is provided.
 
 -   `intptr_t mlirXGetNum<Y>s(MlirX)` returns the upper bound on the index.
 -   `MlirY mlirXGet<Y>(MlirX, intptr_t pos)` returns 'pos'-th subobject.
 
 The sizes are accepted and returned as signed pointer-sized integers, i.e.
-`intptr_t`. This typedef is avalable in C99.
+`intptr_t`. This typedef is available in C99.
 
 Note that the name of subobject in the function does not necessarily match the
-type of the subobject. For example, `mlirOperationGetOperand` returns a
+type of the subobject. For example, `mlirOperationGetOperand` returns an
 `MlirValue`.
 
 ### Iterable Components
 
 An object has an _iterable component_ if it has iterators accessing its fields
 in some order other than integer indexing, typically linked lists. For example,
 an `MlirBlock` has an iterable list of operations it contains. An object may
 have several iterable components.
for (iter = mlirXGetFirst<Y>(x); !mlirYIsNull(iter);
   /* User 'iter'. */
 }
 ```
 
 ## Extending the API
 
 ### Extensions for Dialect Attributes and Types
 
-Dialect attributes and types can follow the example of standard attrbutes and
+Dialect attributes and types can follow the example of standard attributes and
 types, provided that implementations live in separate directories, i.e.
 `include/mlir-c/<...>Dialect/` and `lib/CAPI/<...>Dialect/`. The core APIs
 provide implementation-private headers in `include/mlir/CAPI/IR` that allow one
 to convert between opaque C structures for core IR components and their C++
 counterparts. `wrap` converts a C++ class into a C structure and `unwrap` does
-the inverse conversion. Once the a C++ object is available, the API
+the inverse conversion. Once the C++ object is available, the API
 implementation should rely on `isa` to implement `mlirXIsAY` and is expected to
 use `cast` inside other API calls.

mlir/docs/Dialects/Linalg.md

 At this time there are no additional restrictions to the region
 semantics. This is meant to allow the exploration of various design tradeoffs
 at the intersection of regions and iterator types.
 In particular, the frontend is responsible for the semantics of iterator types
 to correspond to the operations inside the region: the region can capture
 buffers arbitrarily and write into them. If this conflicts with some parallel
 iterator requirement, this is undefined behavior.
 
-Previous examples already ellaborate compute payloads with an unregistered function `"some_compute"`. The following code snippet shows what the result will be when using a concrete operation `addf`:
+Previous examples already elaborate compute payloads with an unregistered function `"some_compute"`. The following code snippet shows what the result will be when using a concrete operation `addf`:
 ```
 // File name: example3.mlir
 #indexing_maps = [
   affine_map<(i, j) -> (i, j)>,
   affine_map<(i, j) -> (i, j)>,
   affine_map<(i, j) -> (i, j)>
 ]
 #attrs = {

mlir/docs/OpDefinitions.md

 
 ODS attributes are defined as having a storage type (corresponding to a backing
 `mlir::Attribute` that _stores_ the attribute), a return type (corresponding to
 the C++ _return_ type of the generated of the helper getters) as well as method
 to convert between the internal storage and the helper method.
 
 ### Attribute decorators
 
-There are a few important attribute adapters/decorators/modifers that can be
+There are a few important attribute adapters/decorators/modifiers that can be
 applied to ODS attributes to specify common additional properties like
 optionality, default values, etc.:
 
 *   `DefaultValuedAttr`: specifies the
     [default value](#attributes-with-default-values) for an attribute.
 *   `OptionalAttr`: specifies an attribute as [optional](#optional-attributes).
 *   `Confined`: adapts an attribute with
     [further constraints](#confining-attributes).

mlir/docs/Rationale/Rationale.md

 in subscripts, sizes of aggregate types and affine expressions. They are also
 tightly coupled with `affine.apply` and affine.load/store operations; having
 `index` type is a necessary precondition of a value to be acceptable by these
 operations.
 
 We allow `index` types in tensors and memrefs as a code generation strategy has
 to map `index` to an implementation type and hence needs to be able to
 materialize corresponding values. However, the target might lack support for
-`vector` values with the target specfic equivalent of the `index` type.
+`vector` values with the target specific equivalent of the `index` type.
 
 ### Bit width of a non-primitive type and `index` is undefined
 
 The bit width of a compound type is not defined by MLIR, it may be defined by a
 specific lowering pass. In MLIR, bit width is a property of certain primitive
 _type_, in particular integers and floats. It is equal to the number that
 appears in the type definition, e.g. the bit width of `i32` is `32`, so is the
 bit width of `f32`. The bit width is not _necessarily_ related to the amount of

mlir/docs/SPIRVToLLVMDialectConversion.md

*   Structs with natural offset (*i.e.* offset that equals to cumulative size of
     the previous struct elements or is a natural alignment) are mapped to
     naturally padded structs. Nested structs with offset and structs with offset
     containing arrays are **not** supported.
 
 *   Structs with unnatural offset (*i.e.* offset that is not equal to cumulative
     size of the previous struct elements) are **not** supported. In this case,
     offsets can be emulated with padding fields (*e.g.* integers). However, such
     a design would require index recalculation in the conversion of ops that
-    involve memmory addressing.
+    involve memory addressing.
 
 Examples of SPIR-V struct conversion are:
 ```mlir
 !spv.struct<i8, i32>          =>  !llvm.struct<packed (i8, i32)>
 !spv.struct<i8 [0], i32 [4]>  =>  !llvm.struct<(i8, i32)>
 
 // error
 !spv.struct<i8 [0], i32 [8]>
*   `offset` and `count` are always scalar. This means that we can have the
     ```
 
 *   `offset` and `count` may have different bitwidths from `base`. In this case,
     both of these operands have to be zero extended (since they are treated as
     unsigned by the specification) or truncated. For the above example it would
     be:
 
     ```mlir
-    // Zero extending offest after broadcasting
+    // Zero extending offset after broadcasting
     %res_offset = llvm.zext %vec_offset: !llvm.vec<2 x i8> to !llvm.vec<2 x i32>
     ```
 
     Also, note that if the bitwidth of `offset` or `count` is greater than the
     bitwidth of `base`, truncation is still permitted. This is because the ops have a
     defined behaviour with `offset` and `count` being less than the size of
     `base`. It creates a natural upper bound on what values `offset` and `count`
     can take, which is 64. This can be expressed in less than 8 bits.

 
 // Conversion of VariableOp with initialization
                                                                %c    = llvm.mlir.constant(0 : i64) : !llvm.i64
 %c   = spv.constant 0 : i64                                    %size = llvm.mlir.constant(1 : i32) : !llvm.i32
 %res = spv.Variable init(%c) : !spv.ptr<i64, Function>    =>   %res   = llvm.alloca %[[SIZE]] x !llvm.i64 : (!llvm.i32) -> !llvm.ptr<i64>
                                                                llvm.store %c, %res : !llvm.ptr<i64>
 ```
 
-Note that simple conversion to `alloca` may not be sufficent if the code has
+Note that simple conversion to `alloca` may not be sufficient if the code has
 some scoping. For example, if converting ops executed in a loop into `alloca`s,
 a stack overflow may occur. For this case, `stacksave`/`stackrestore` pair can
 be used (TODO).
 
 ### Miscellaneous ops with direct conversions
 
 There are multiple SPIR-V ops that do not fit in a particular group but can be
 converted directly to LLVM dialect. Their conversion is addressed in this

 *   spv.Unreachable
 
 ## Control flow conversion
 
 ### Branch ops
 
 `spv.Branch` and `spv.BranchConditional` are mapped to `llvm.br` and
 `llvm.cond_br`. Branch weigths for `spv.BranchConditional` are mapped to
-coresponding `branch_weights` attribute of `llvm.cond_br`. When translated to
+corresponding `branch_weights` attribute of `llvm.cond_br`. When translated to
 proper LLVM, `branch_weights` are converted into LLVM metadata associated with
 the conditional branch.
 
 ### `spv.FunctionCall`
 
 `spv.FunctionCall` maps to `llvm.call`. For example:
 
 ```mlir

 
 ## Function conversion and related ops
 
 This section describes the conversion of function-related operations from SPIR-V
 to LLVM dialect.
 
 ### `spv.func`
 This op declares or defines a SPIR-V function and it is converted to `llvm.func`.
-This conversion handles signarture conversion, and function control attributes
+This conversion handles signature conversion, and function control attributes
 remapping to LLVM dialect function [`passthrough` attribute](Dialects/LLVM.md#Attribute-pass-through).
 
 The following mapping is used to map [SPIR-V function control](SPIRVFunctionAttributes) to
 [LLVM function attributes](LLVMFunctionAttributes):
 
 SPIR-V Function Control Attributes    | LLVM Function Attributes
 :-----------------------------------: | :-----------------------------------:
 None                                  | No function attributes passed

mlir/test/Conversion/StandardToLLVM/calling-convention.mlir

func @return_var_memref(%arg0: memref<4x3xf32>) -> memref<*xf32> {
   // CHECK: %[[FALSE:.*]] = llvm.mlir.constant(false)
   // CHECK: %[[ALLOCATED:.*]] = llvm.call @malloc(%[[ALLOC_SIZE]])
   // CHECK: %[[SOURCE:.*]] = llvm.extractvalue %[[DESC_2]][1]
   // CHECK: "llvm.intr.memcpy"(%[[ALLOCATED]], %[[SOURCE]], %[[ALLOC_SIZE]], %[[FALSE]])
   // CHECK: %[[NEW_DESC:.*]] = llvm.mlir.undef : !llvm.struct<(i64, ptr<i8>)>
   // CHECK: %[[RANK:.*]] = llvm.extractvalue %[[DESC_2]][0] : !llvm.struct<(i64, ptr<i8>)>
   // CHECK: %[[NEW_DESC_1:.*]] = llvm.insertvalue %[[RANK]], %[[NEW_DESC]][0]
   // CHECK: %[[NEW_DESC_2:.*]] = llvm.insertvalue %[[ALLOCATED]], %[[NEW_DESC_1]][1]
-  // CHECL: llvm.return %[[NEW_DESC_2]]
+  // CHECK: llvm.return %[[NEW_DESC_2]]
   return %0 : memref<*xf32>
 }
 
 // CHECK-LABEL: llvm.func @return_two_var_memref_caller
 func @return_two_var_memref_caller(%arg0: memref<4x3xf32>) {
   // Only check that we create two different descriptors using different
   // memory, and deallocate both sources. The size computation is same as for
   // the single result.

mlir/test/mlir-tblgen/op-decl.td

 
 // CHECK: class AOpAdaptor {
 // CHECK: public:
 // CHECK:   AOpAdaptor(::mlir::ValueRange values
 // CHECK:   ::mlir::ValueRange getODSOperands(unsigned index);
 // CHECK:   ::mlir::Value a();
 // CHECK:   ::mlir::ValueRange b();
 // CHECK:   ::mlir::IntegerAttr attr1();
-// CHECL:   ::mlir::FloatAttr attr2();
+// CHECK:   ::mlir::FloatAttr attr2();
 // CHECK: private:
 // CHECK:   ::mlir::ValueRange odsOperands;
 // CHECK: };
 
 // CHECK: class AOp : public ::mlir::Op<AOp, OpTrait::AtLeastNRegions<1>::Impl, OpTrait::AtLeastNResults<1>::Impl, OpTrait::ZeroSuccessor, OpTrait::AtLeastNOperands<1>::Impl, OpTrait::IsIsolatedFromAbove
 // CHECK-NOT: OpTrait::IsIsolatedFromAbove
 // CHECK: public:
 // CHECK:   using Op::Op;