[mlir] NFC: Fix trivial typos in documents Fix trivial typos

[ftynse]

Thanks!

[kiszk]

Ah, I made a mistake when I pushed. I should have removed the following lines...

Reviewers: mravishankar, antiagainst, ftynse

Reviewed By: ftynse

Subscribers: ftynse, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, Joonsoo, bader, llvm-commits

Tags: #llvm

[ftynse]

We have a script here https://mlir.llvm.org/getting_started/Contributing/#using-arcanist. It should be possible to adapt it in a pre-push git hook :)

[kiszk]

Thank you for letting me know. I added it to ~/.bashrc.

mlir/docs/CreatingADialect.md

 underlying add_llvm_library() call, allowing it to correctly create
 new targets with the same sources.
 
 
 
 # Dialect Conversions
 
 Conversions from “X” to “Y” live in mlir/include/mlir/Conversion/XToY,
-mlir/lib/Convresion/XToY and mlir/test/Conversion/XToY, respectively.
+mlir/lib/Conversion/XToY and mlir/test/Conversion/XToY, respectively.
 
 Default file names for conversion should omit “Convert” from their
 name, e.g. lib/VectorToLLVM/VectorToLLVM.cpp.
 
 Conversion passes should live separately from conversions themselves
 for convenience of users that only care about a pass and not about its
 implementation with patterns or other infrastructure. For example
 include/mlir/VectorToLLVM/VectorToLLVMPass.h.

mlir/docs/Dialects/SPIR-V.md

 
 The `mlir::spirv::SPIRVConversionTarget` class derives from the
 `mlir::ConversionTarget` class and serves as a utility to define a conversion
 target satisfying a given [`spv.target_env`](#target-environment). It registers
 proper hooks to check the dynamic legality of SPIR-V ops. Users can further
 register other legality constraints into the returned `SPIRVConversionTarget`.
 
 `spirv::lookupTargetEnvOrDefault()` is a handy utility function to query an
-`spv.target_env` attached in the input IR or use the feault to construct a
+`spv.target_env` attached in the input IR or use the default to construct a
 `SPIRVConversionTarget`.
 
 ### `SPIRVTypeConverter`
 
 The `mlir::SPIRVTypeConverter` derives from `mlir::TypeConverter` and provides
 type conversion for standard types to SPIR-V types:
 
 *   [Standard Integer][MlirIntegerType] -> Standard Integer

mlir/docs/LangRef.md

 // The memref index space is of size %M x %N, while %B1 and %B2 bind to the
 // symbols s0, s1 respectively of the layout map #tiled_dynamic. Data tiles of
 // size %B1 x %B2 in the logical space will be stored contiguously in memory.
 // The allocation size will be (%M ceildiv %B1) * %B1 * (%N ceildiv %B2) * %B2
 // f32 elements.
 %T = alloc(%M, %N) [%B1, %B2] : memref<?x?xf32, #tiled_dynamic>
 
 // A memref that has a two-element padding at either end. The allocation size
-// will fit 16 * 68 float elements of data.
+// will fit 16 * 64 float elements of data.
 %P = alloc() : memref<16x64xf32, #padded>
 
 // Affine map with symbol 's0' used as offset for the first dimension.
 #imapS = affine_map<(d0, d1) [s0] -> (d0 + s0, d1)>
 // Allocate memref and bind the following symbols:
 // '%n' is bound to the dynamic second dimension of the memref type.
 // '%o' is bound to the symbol 's0' in the affine map of the memref type.
 %n = ...

mlir/docs/OpDefinitions.md

 example above, the variables would be `$callee` and `$args`.
 
 Attribute variables are printed with their respective value type, unless that
 value type is buildable. In those cases, the type of the attribute is elided.
 
 #### Optional Groups
 
 In certain situations operations may have "optional" information, e.g.
-attributes or an empty set of variadic operands. In these situtations a section
+attributes or an empty set of variadic operands. In these situations a section
 of the assembly format can be marked as `optional` based on the presence of this
 information. An optional group is defined by wrapping a set of elements within
 `()` followed by a `?` and has the following requirements:
 
 *   The first element of the group must either be a literal or an operand.
     -   This is because the first element must be optionally parsable.
 *   Exactly one argument variable within the group must be marked as the anchor
     of the group.

mlir/docs/RationaleLinalgDialect.md

 derived from [ISL](https://en.wikipedia.org/wiki/Integer_set_library)
 and uses both HalideIR and the ISL *schedule-tree* IR.
 The compiler provides a collection of polyhedral compilation
 algorithms to perform fusion and favor multi-level parallelism and
 promotion to deeper levels of the memory hierarchy.
 Tensor Comprehensions showed that, fixing a few predefined strategies
 with parametric transformations and tuning knobs, can already provide
 great results. In that previous work, simple
-genetic search combined with an autotining framework was sufficient
+genetic search combined with an autotuning framework was sufficient
 to find good implementations in the ***non-compute bound regime***.
 This requires code versions obtainable by the
 various transformations to encompass versions that get close to the
 roofline limit.
 The ultimate goal of Tensor Comprehensions was to concretely mix
 Halide high-level transformations with polyhedral mid-level
 transformations and build a pragmatic system that could take advantage
 of both styles of compilation.
 
 Linalg hopes to additionally address the following:
 - Halide was never properly used in Tensor Comprehensions beyond shape
 inference. Most of the investment went into simplifying polyhedral
 transformations and building a usable end-to-end system. MLIR was
 deemed a better infrastructure to mix these types of compilation.
 - The early gains provided by reusing established infrastructures
 (HalideIR and ISL schedule trees) turned into more impedance mismatch
 problems than could be solved with a small tactical investment.
 - Tensor Comprehensions emitted CUDA code which was then JIT compiled
 with NVCC from a textual representation. While this was a pragmatic
 short-term solution it made it hard to perform low-level rewrites that
-would have helped with register reuse in the ***comput-bound regime***.
+would have helped with register reuse in the ***compute-bound regime***.
 - The same reliance on emitting CUDA code made it difficult to
 create cost models when time came. This made it artifically harder to
 prune out bad solutions than necessary. This resulted in excessive
 runtime evaluation, as reported in the paper [Machine Learning Systems
 are Stuck in a Rut](https://dl.acm.org/doi/10.1145/3317550.3321441).
 
 Many of those issues are naturally addressed by implementing these ideas
 in the MLIR infrastructure.

mlir/include/mlir/Dialect/SPIRV/SPIRVCastOps.td

 //===-- SPIRVCastOps.td - MLIR SPIR-V Cast Ops -------*- tablegen -*-------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 //
 // This file contains cast ops for the SPIR-V dialect. It corresponds
-// to "3.32.11. Convertion Instructions" of the SPIR-V specification.
+// to "3.32.11. Conversion Instructions" of the SPIR-V specification.
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef SPIRV_CAST_OPS
 #define SPIRV_CAST_OPS
 
 include "mlir/Dialect/SPIRV/SPIRVBase.td"
 include "mlir/Interfaces/SideEffects.td"