[mlir] NFC: fix trivial typo

mlir/docs/DeclarativeRewrites.md

 `def : Pat<(AOp $_, $b), ...>` means only `$b` is interesting to capture and
 will be referenced later in result patterns. It's still possible to place
 additional constraints even if the symbol is not to be captured; for such case,
 you can simply use just the `TypeConstraint` or `AttributeConstraint` without a
 bound symbol, for example, `def : Pat<(AOp $a, F32Attr), ...>`.
 
 #### Matching DAG of operations
 
-To match an DAG of ops, use nested `dag` objects:
+To match a DAG of ops, use nested `dag` objects:
 
 ```tablegen
 
 def BOp : Op<"b_op"> {
     let arguments = (ins);
 
     let results = (outs
       AnyType:$b_output

 In the above, we created a `ThreeResultOp` and bind `results` to its results,
 and uses its last result (`$output3`) and first result (`$output1`) to replace
 the `TwoResultOp`'s two results, respectively.
 
 #### Replacing multi-result ops
 
 The above example also shows how to replace a matched multi-result op.
 
-To replace a `N`-result op, the result patterns must generate at least `N`
+To replace an `N`-result op, the result patterns must generate at least `N`
 declared values (see [Declared vs. actual value](#declared-vs-actual-value) for
 definition). If there are more than `N` declared values generated, only the
 last `N` declared values will be used to replace the matched op. Note that
 because of the existence of multi-result op, one result pattern **may** generate
 multiple declared values. So it means we do not necessarily need `N` result
 patterns to replace an `N`-result op. For example, to replace an op with three
 results, you can have
 

 
 By default the C++ pattern expanded from a DRR pattern uses the fused location
 of all source ops as the location for all generated ops. This is not always the
 best location mapping relationship. For such cases, DRR provides the `location`
 directive to provide finer control.
 
 `location` is of the following syntax:
 
-```tablgen
+```tablegen
 (location $symbol0, $symbol1, ...)
 ```
 
 where all `$symbol` should be bound previously in the pattern and one optional
-string may be specified as an attribute. The following locations are creted:
+string may be specified as an attribute. The following locations are created:
 
 *   If only 1 symbol is specified then that symbol's location is used,
 *   If multiple are specified then a fused location is created;
 *   If no symbol is specified then string must be specified and a NamedLoc is
     created instead;
 
 `location` must be used as the last argument to an op creation. For example,
 

mlir/docs/Dialects/Affine.md

 [`constant` operation](Standard.md#constant-operation), or the result of an
 [`affine.apply` operation](#affineapply-operation) that recursively takes as
 arguments any symbolic identifiers, or the result of a [`dim`
 operation](Standard.md#dim-operation) on either a memref that is a function
 argument or a memref where the corresponding dimension is either static or a
 dynamic one in turn bound to a symbolic identifier.  Dimensions may be bound not
 only to anything that a symbol is bound to, but also to induction variables of
 enclosing [`affine.for`](#affinefor-affineforop) and
-[`afffine.parallel`](#affineparallel-affineparallelop) operations, and the
+[`affine.parallel`](#affineparallel-affineparallelop) operations, and the
 result of an
 [`affine.apply` operation](#affineapply-operation) (which recursively may use
 other dimensions and symbols).
 
 ### Affine Expressions
 
 Syntax:
 

mlir/docs/OpDefinitions.md

 rewrites.
 
 The full operation name is composed of the dialect name and the op name, with
 the former provided via the dialect and the latter provided as the second
 template parameter to the `Op` class.
 
 ### Operation documentation
 
-This includes both an one-line `summary` and a longer human-readable
+This includes both a one-line `summary` and a longer human-readable
 `description`. They will be used to drive automatic generation of dialect
 documentation. They need to be provided in the operation's definition body:
 
 ```tablegen
 let summary = "...";
 
 let description = [{
 ...

 Constraint is a core concept in table-driven operation definition: operation
 verification and graph operation matching are all based on satisfying
 constraints. So both the operation definition and rewrite rules specification
 significantly involve writing constraints. We have the `Constraint` class in
 [`OpBase.td`][OpBase] has the common base class for all constraints.
 
 An operation's constraint can cover different range; it may
 
-* Only concern a single attribute (e.g. being an 32-bit integer greater than 5),
+* Only concern a single attribute (e.g. being a 32-bit integer greater than 5),
 * Multiple operands and results (e.g., the 1st result's shape must be the same
   as the 1st operand), or
 * Intrinsic to the operation itself (e.g., having no side effect).
 
 We call them as single-entity constraint, multi-entity constraint, and traits,
 respectively.
 
 ### Single-entity constraint

 ### Attribute decorators
 
 There are a few important attribute adapters/decorators/modifers 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`: specfies an attribute as [optional](#optional-attributes).
+*   `OptionalAttr`: specifies an attribute as [optional](#optional-attributes).
 *   `Confined`: adapts an attribute with
     [further constraints](#confining-attributes).
 
 ### Enum attributes
 
-Some attributes can only take values from an predefined enum, e.g., the
+Some attributes can only take values from a predefined enum, e.g., the
 comparison kind of a comparison op. To define such attributes, ODS provides
 several mechanisms: `StrEnumAttr`, `IntEnumAttr`, and `BitEnumAttr`.
 
 *   `StrEnumAttr`: each enum case is a string, the attribute is stored as a
     [`StringAttr`][StringAttr] in the op.
 *   `IntEnumAttr`: each enum case is an integer, the attribute is stored as a
     [`IntegerAttr`][IntegerAttr] in the op.
 *   `BitEnumAttr`: each enum case is a bit, the attribute is stored as a

mlir/docs/PassManagement.md

 static PassPipelineRegistration<> pipeline(
   "command-line-arg", "description", [](OpPassManager &pm) {
     pm.addPass(std::make_unique<MyPass>());
     pm.addPass(std::make_unique<MyOtherPass>());
   });
 ```
 
 Pipeline registration also allows for simplified registration of
-specifializations for existing passes:
+specializations for existing passes:
 
 ```c++
 static PassPipelineRegistration<> foo10(
     "foo-10", "Foo Pass 10", [] { return std::make_unique<FooPass>(10); } );
 ```
 
 ### Textual Pass Pipeline Specification
 

mlir/docs/Quantization.md

 
 As originally implemented, TensorFlow Lite was the primary user of such
 operations at inference time. When quantized inference was enabled, if every
 eligible tensor passed through an appropriate fake_quant node (the rules of
 which tensors can have fake_quant applied are somewhat involved), then
 TensorFlow Lite would use the attributes of the fake_quant operations to make a
 judgment about how to convert to use kernels from its quantized operations subset.
 
-In MLIR-based quantization, fake_quant_\* operationss are handled by converting them to
+In MLIR-based quantization, fake_quant_\* operations are handled by converting them to
 a sequence of *qcast* (quantize) followed by *dcast* (dequantize) with an
 appropriate *UniformQuantizedType* as the target of the qcast operation.
 
 This allows subsequent compiler passes to preserve the knowledge that
 quantization was simulated in a certain way, while giving the compiler
 flexibility to move the casts as it simplifies the computation and converts it
 to a form based on integral arithmetic.
 
 This scheme also naturally allows computations that are *partially quantized*
-where the parts which could not be reduced to integral operationss are still carried out
+where the parts which could not be reduced to integral operations are still carried out
 in floating point with appropriate conversions at the boundaries.
 
 ## TFLite native quantization
 
 TODO : Flesh this out
 
 ### General algorithm
 

mlir/docs/Rationale/Rationale.md

 expressions in a form close to their mathematical form. These structures are
 used to capture loop nests, tensor data structures, and how they are reordered
 and mapped for a target architecture. All structured or "conforming" loops are
 captured as part of the polyhedral information, and so are tensor variables,
 their layouts, and subscripted accesses to these tensors in memory.
 
 The information captured in the IR allows a compact expression of all loop
 transformations, data remappings, explicit copying necessary for explicitly
-addressed memory in accelerators, mapping to pre-tuned expert written
+addressed memory in accelerators, mapping to pre-tuned expert-written
 primitives, and mapping to specialized vector instructions. Loop transformations
 that can be easily implemented include the body of affine transformations: these
 subsume all traditional loop transformations (unimodular and non-unimodular)
 such as loop tiling, interchange, permutation, skewing, scaling, relative
 shifting, reversal, fusion, and distribution/fission. Transformations on data
 layout such as padding and transforming to blocked layouts are also represented
 well via affine layout maps.
 

 of supporting smaller integer types, e.g. `i8` or `i16`, for small indices
 instead of (presumably larger) `index` type.
 
 Index types are allowed as element types of `tensor` types. The `tensor` type
 specifically abstracts the target-specific aspects that intersect with the
 code-generation-related/lowering-related concerns explained above. In fact, the
 `tensor` type even allows dialect-specific types as element types.
 
-### Bit width of a non-primitive types and `index` is undefined
+### 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
 memory (in bytes) or the size of register (in bits) that is necessary to store
 the value of the given type. These quantities are target and ABI-specific and

 Integers in the builtin MLIR type system have a bitwidth (note that the `index`
 type has a symbolic width equal to the machine word size), and they *may*
 additionally have signedness semantics. The purpose is to satisfy the needs of
 different dialects, which can model different levels of abstractions. Certain
 abstraction, especially closer to source language, might want to differentiate
 signedness with integer types; while others, especially closer to machine
 instruction, might want signless integers. Instead of forcing each abstraction
 to adopt the same integer modelling or develop its own one in house, Integer
-types provides this as an option to help code reuse and consistency.
+type provides this as an option to help code reuse and consistency.
 
 For the standard dialect, the choice is to have signless integer types. An
 integer value does not have an intrinsic sign, and it's up to the specific op
 for interpretation. For example, ops like `addi` and `muli` do two's complement
 arithmetic, but some other operations get a sign, e.g. `divis` vs `diviu`.
 
 LLVM uses the [same design](http://llvm.org/docs/LangRef.html#integer-type),
 which was introduced in a revamp rolled out

mlir/docs/Rationale/RationaleLinalgDialect.md

 one's favorite HPC library or ISA has a `matmul` primitive running at 95% of
 the achievable peak performance, for operands stored in some memory, one should
 be able to **use the primitive** when possible *and* generate code otherwise.
 
 However, as the design of Linalg co-evolved with the design of MLIR, it became
 apparent that it could extend to larger application domains than just machine
 learning on dense tensors.
 
-The design and evolution of Linalg follows a *codegen-friendly* approach where
+The design and evolution of Linalg follow a *codegen-friendly* approach where
 the IR and the transformations evolve hand-in-hand.
 The key idea is that op semantics *declare* and transport information that is
 traditionally obtained by compiler analyses.
 This information captures the legality and applicability of transformations and
 is **not lost by lowering prematurely to loop or CFG form**. The key
 transformations are designed so as to **preserve this information** as long as
 necessary. For example, `linalg.matmul` remains `linalg.matmul` after tiling
 and fusion.

 [ODS](https://mlir.llvm.org/docs/OpDefinitions/) and
 [Declarative Rewrite Rules](https://mlir.llvm.org/docs/DeclarativeRewrites/)
 among others. The approach adopted by Linalg was extended to become
 [StructuredOps abstractions](
 https://drive.google.com/drive/u/0/folders/1sRAsgsd8Bvpm_IxREmZf2agsGU2KvrK-),
 with Linalg becoming its incarnation on tensors and buffers.
 It is complemented by the
 [Vector dialect](https://mlir.llvm.org/docs/Dialects/Vector/),
-which define structured operations on vectors, following the same rationale and
+which defines structured operations on vectors, following the same rationale and
 design principles as Linalg. (Vector dialect includes the higher-level
 operations on multi-dimensional vectors and abstracts away the lowering to
 single-dimensional vectors).
 
 The Linalg dialect itself grew beyond linear algebra-like operations to become
 more expressive, in particular by providing an abstraction of a loop nest
 supporting parallelism, reductions and sliding windows around arbitrary MLIR
 [regions](https://mlir.llvm.org/docs/LangRef/#regions). It also has the

 Linalg builds on, and helps separate concerns in the LIFT approach as follows:
 - transformations are either separated from the representation or expressed as
   composable attributes that are independent of the actual computation,
   avoiding intricate effects on performance;
 - abstractions are split into smaller components (e.g., control flow and data
   structure abstractions) potentially reusable across different dialects in the
   MLIR's open ecosystem.
 
-LIFT is expected to further influence the design of Linalg as it evolve. In
+LIFT is expected to further influence the design of Linalg as it evolves. In
 particular, extending the data structure abstractions to support non-dense
 tensors can use the experience of LIFT abstractions for
 [sparse](https://www.lift-project.org/publications/2016/harries16sparse.pdf)
 and [position-dependent
 arrays](https://www.lift-project.org/publications/2019/pizzuti19positiondependentarrays.pdf).
 
 ### Lessons from XLA<a name="lessonsxla"></a>
 [XLA](https://www.tensorflow.org/xla/architecture) is one of the first

 still only accessible to $\Omega$(1-10) users. Halide makes heavy usage of
 canonicalization rules that are also very prevalent in MLIR.
 
 Linalg hopes to additionally address the following:
 - Halide scheduling is powerful and explores a large swath of possible
 transformations. But it's still too hard for newcomers to use or extend. The
 level of performance you get from Halide is very different depending on
 whether one is a seasoned veteran or a newcomer. This is especially true as
-the number of transformations grow.
+the number of transformations grows.
 - Halide raises rather than lowers in two ways, going counter-current to the
-design goals we set for high-level codegen abstractions in in MLIR. First,
+design goals we set for high-level codegen abstractions in MLIR. First,
 canonical Halide front-end code uses explicit indexing and math on scalar
 values, so to target BLAS/DNN libraries one needs to add pattern matching
 which is similarly brittle as in the affine case. While Halide's performance
 is on par with the libraries on programmable targets (CPU/GPU), that
 approach doesn't work on mobile accelerators or on xPUs, where the framework
 ingests whole-tensor operations.
 Second, reductions and scans are expressed using serial iteration, again
 requiring pattern matching before they can be transformed (e.g. to do a

 generic operation properties that drive applicability, and
 - make them very simple to implement, apply, verify and especially
 maintain.
 
 The problem at hand is fundamentally driven by compilation of domain-specific
 workloads for high-performance and parallel hardware architectures: **this is
 an HPC compilation problem**.
 
-The selection of relevant transformations follows a codesign approach and
+The selection of relevant transformations follows a co-design approach and
 involves considerations related to:
 - concrete current and future needs of the application domain,
 - concrete current and future hardware properties and ISAs,
 - understanding of strengths and limitations of [existing approaches](#prior_art),
 - taking advantage of the coexistence of multiple levels of IR in MLIR,
 
 One needs to be methodical to avoid proliferation and redundancy. A given
 transformation could exist at multiple levels of abstraction but **just

 when it is not irremediably lost.
 
 These remarks, coupled with MLIR's suitability for defining IR at multiple
 levels of abstraction led to the following 2 principles.
 
 #### Declarative Specification: Avoid Raising<a name="declarative_specification"></a>
 
 Compiler transformations need static structural information (e.g. loop-nests,
-graphs of basic blocks, pure functions etc). When that structural information
+graphs of basic blocks, pure functions, etc). When that structural information
 is lost, it needs to be reconstructed.
 
 A good illustration of this phenomenon is the notion of *raising* in polyhedral
 compilers: multiple polyhedral tools start by raising from a simplified C
 form or from SSA IR into a higher-level representation that is more amenable
 to loop transformations.
 
 In advanced polyhedral compilers, a second type of raising

 - Design transformations that are correct by construction, easy to
 write, easy to verify and easy to maintain.
 - Provide a way to specify transformations and the units of IR they manipulate
 declaratively. In turn this allows using local pattern rewrite rules in MLIR
 (i.e. [DRR](../DeclarativeRewrites.md)).
 - Allow creating customizable passes declaratively by simply selecting rewrite
 rules. This allows mixing transformations, canonicalizations, constant folding
 and other enabling rewrites in a single pass. The result is a system where pass
-fusion is very simple to obtain and gives hope to solving certain
+fusion is very simple to obtain and gives hope for solving certain
 [phase ordering issues](https://dl.acm.org/doi/10.1145/201059.201061).
 
 ### Suitability for Search and Machine Learning<a name="ml"></a>
 Compiler heuristics are hand-crafted human-engineered features: it is
 ripe for disruption by machine-learning  techniques.
 To enable search, compiler transformations should be fine-grained,
 [composable](#declarative_transformations) and expose tuning parameters that
 can modify their behavior, guided by lessons from previous experience

 data types. We choose to take advantage of these properties for the
 reasons described above.
 In particular, the `MemRefType` represents dense non-contiguous memory regions.
 This structure should extend beyond simple dense data types and generalize to
 ragged, sparse and mixed dens/sparse tensors as well as to trees, hash tables,
 tables of records and maybe even graphs.
 
 For such more advanced data types, the control-flow required to traverse the
-data structures, termination conditions etc are much less simple to analyze and
+data structures, termination conditions, etc are much less simple to analyze and
 characterize statically. As a consequence we need to also design solutions that
 stand a chance of evolving into runtime-adaptive computations (e.g.
 inspector-executor in which an *inspector* runs a cheap runtime
 analysis on the data to configure how the *executor* should run).
 While there is no concrete solution
 today to solve these problems in MLIR, it is pretty clear that perfect
 static knowledge and analyses will not be serious contenders for these problems.
 

 - as control flow or data structure manipulation,
 - on Linalg ops attributes or on loops after some partial lowering
 occurred,
 - as extensions to the Linalg dialect in terms of new ops or attributes.
 
 ### The Dialect Need not be Closed Under Transformations<a name="dialect_not_closed"></a>
 This is probably the most surprising and counter-intuitive
 observation. When one designs IR for transformations, closed-ness is
-often a nonnegotiable property.
+often a non-negotiable property.
 This is a key design principle of polyhedral IRs such as
 [URUK](http://icps.u-strasbg.fr/~bastoul/research/papers/GVBCPST06-IJPP.pdf)
 and
 [ISL-based IRs](https://en.wikipedia.org/wiki/Integer_set_library):
 they are closed under affine transformations.
 In MLIR, multiple dialects coexist and form a coherent whole. After
 experimenting with different alternatives, it became clear that strict
 dialect closed-ness wasn't necessary and could be relaxed. Previous

mlir/docs/ShapeInference.md

*   Shape functions usable by compiler and runtime.
 
     *   This does not mean the exact same C++ function, but rather the
         description should be consumable by either.
     *   Shape function description should not be constrained by either runtime
         or compiler's type system to handle types only used for analysis. That
         is, these two type systems differ and both should be supported, but the
         intersection of the two should not be required. As a particular example,
         if a compiler only wants to differentiate exact shapes vs dynamic
-        shapes, then it need not consider a more generic shape latice even
+        shapes, then it need not consider a more generic shape lattice even
         though the shape description supports it.
 
 *   Declarative (e.g., analyzable at compile time, possible to generate
     different versions for different use cases)
 
     *   This may not strictly be a requirement, but a way to handle the former:
         a declarative specification could be reused by both while avoiding a
         need to map to or from a 3rd representation given these two systems

mlir/docs/Tutorials/CreatingADialect.md

 dialects (e.g. MLIRStandard).  Typically this dependence is specified
 using target_link_libraries() and the PUBLIC keyword.  For instance:
 
 ```cmake
 
 add_mlir_conversion_library(MLIRBarToFoo
   BarToFoo.cpp
 
         ADDITIONAL_HEADER_DIRS
         ${MLIR_MAIN_INCLUDE_DIR}/mlir/Conversion/BarToFoo
   )
 target_link_libraries(MLIRBarToFoo
   PUBLIC
   BarOps
   FooOps
   )
 
 ```

mlir/docs/doxygen.cfg.in

 PROJECT_NUMBER         = @PACKAGE_VERSION@
 
 # Using the PROJECT_BRIEF tag one can provide an optional one line description
 # for a project that appears at the top of each page and should give viewer a
 # quick idea about the purpose of the project. Keep the description short.
 
 PROJECT_BRIEF          =
 
-# With the PROJECT_LOGO tag one can specify an logo or icon that is included in
+# With the PROJECT_LOGO tag one can specify a logo or icon that is included in
 # the documentation. The maximum height of the logo should not exceed 55 pixels
 # and the maximum width should not exceed 200 pixels. Doxygen will copy the logo
 # to the output directory.
 
 PROJECT_LOGO           =
 
 # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path
 # into which the generated documentation will be written. If a relative path is

mlir/include/mlir/Dialect/Linalg/IR/LinalgStructuredOps.td

def MatmulOp : LinalgStructured_Op<"matmul", [NInputs<2>, NOutputs<1>]> {
   let hasFolder = 1;
 }
 
 /// A base class for pooling operation such as conv. The arguments must contain
 /// optional arguments `strides`, `dilations` and `padding` with following type:
 ///   OptionalAttr<I64ArrayAttr>:$strides
 ///   OptionalAttr<I64ArrayAttr>:$dilations
 ///   OptionalAttr<I64ElementsAttr>:$padding
-/// `stirdes` denotes the step of each window along the dimension.
+/// `strides` denotes the step of each window along the dimension.
 class PoolingBase_Op<string mnemonic, list<OpTrait> props>
   : LinalgStructured_Op<mnemonic, props> {
   let description = [{
     Performs an N-D pooling operation similarly to the description in the TF
     documentation:
     https://www.tensorflow.org/api_docs/python/tf/nn/pool
 
     Different from the description, this operation doesn't perform on batch and

mlir/include/mlir/IR/OpBase.td

 // do not use DerivedAttr for things that could not have been stored as
 // Attribute.
 //
 class DerivedAttr<code ret, code b, code convert = ""> :
     Attr<CPred<"true">, "derived attribute"> {
   let returnType = ret;
   code body = b;
 
-  // Specify how to convert from the derived attribute to an attibute.
+  // Specify how to convert from the derived attribute to an attribute.
   //
   // ## Special placeholders
   //
   // Special placeholders can be used to refer to entities during conversion:
   //
   // * `$_builder` will be replaced by a mlir::Builder instance.
   // * `$_ctx` will be replaced by the MLIRContext* instance.
   // * `$_self` will be replaced with the derived attribute (value produces