[NFC][MLIR] Fix some typos

Author: VitalyAnkh

clang-tools-extra/clang-tidy/llvmlibc/RestrictSystemLibcHeadersCheck.cpp

@@ -25,9 +25,9 @@ class RestrictedIncludesPPCallbacks
 public:
   explicit RestrictedIncludesPPCallbacks(
       RestrictSystemLibcHeadersCheck &Check, const SourceManager &SM,
-      const SmallString<128> CompilerIncudeDir)
+      const SmallString<128> CompilerIncludeDir)
       : portability::RestrictedIncludesPPCallbacks(Check, SM),
-        CompilerIncudeDir(CompilerIncudeDir) {}
+        CompilerIncludeDir(CompilerIncludeDir) {}
 
   void InclusionDirective(SourceLocation HashLoc, const Token &IncludeTok,
                           StringRef FileName, bool IsAngled,
@@ -38,7 +38,7 @@ class RestrictedIncludesPPCallbacks
                           SrcMgr::CharacteristicKind FileType) override;
 
 private:
-  const SmallString<128> CompilerIncudeDir;
+  const SmallString<128> CompilerIncludeDir;
 };
 
 } // namespace
@@ -49,7 +49,7 @@ void RestrictedIncludesPPCallbacks::InclusionDirective(
     StringRef SearchPath, StringRef RelativePath, const Module *SuggestedModule,
     bool ModuleImported, SrcMgr::CharacteristicKind FileType) {
   // Compiler provided headers are allowed (e.g stddef.h).
-  if (SrcMgr::isSystem(FileType) && SearchPath == CompilerIncudeDir)
+  if (SrcMgr::isSystem(FileType) && SearchPath == CompilerIncludeDir)
     return;
   portability::RestrictedIncludesPPCallbacks::InclusionDirective(
       HashLoc, IncludeTok, FileName, IsAngled, FilenameRange, File, SearchPath,
@@ -58,11 +58,11 @@ void RestrictedIncludesPPCallbacks::InclusionDirective(
 
 void RestrictSystemLibcHeadersCheck::registerPPCallbacks(
     const SourceManager &SM, Preprocessor *PP, Preprocessor *ModuleExpanderPP) {
-  SmallString<128> CompilerIncudeDir =
+  SmallString<128> CompilerIncludeDir =
       StringRef(PP->getHeaderSearchInfo().getHeaderSearchOpts().ResourceDir);
-  llvm::sys::path::append(CompilerIncudeDir, "include");
+  llvm::sys::path::append(CompilerIncludeDir, "include");
   PP->addPPCallbacks(std::make_unique<RestrictedIncludesPPCallbacks>(
-      *this, SM, CompilerIncudeDir));
+      *this, SM, CompilerIncludeDir));
 }
 
 } // namespace clang::tidy::llvm_libc

mlir/docs/Canonicalization.md

@@ -12,7 +12,7 @@ Most compilers have canonicalization passes, and sometimes they have many
 different ones (e.g. instcombine, dag combine, etc in LLVM). Because MLIR is a
 multi-level IR, we can provide a single canonicalization infrastructure and
 reuse it across many different IRs that it represents. This document describes
-the general approach, global canonicalizations performed, and provides sections
+the general approach, global canonicalization performed, and provides sections
 to capture IR-specific rules for reference.
 
 [TOC]
@@ -28,7 +28,7 @@ exhausted. This is for efficiency reasons and to ensure that faulty patterns
 cannot cause infinite looping.
 
 Canonicalization patterns are registered with the operations themselves, which
-allows each dialect to define its own set of operations and canonicalizations
+allows each dialect to define its own set of operations and canonicalization
 together.
 
 Some important things to think about w.r.t. canonicalization patterns:
@@ -107,15 +107,15 @@ These transformations are applied to all levels of IR:
 
 ## Defining Canonicalizations
 
-Two mechanisms are available with which to define canonicalizations;
+Two mechanisms are available with which to define canonicalization;
 general `RewritePattern`s and the `fold` method.
 
 ### Canonicalizing with `RewritePattern`s
 
-This mechanism allows for providing canonicalizations as a set of
+This mechanism allows for providing canonicalization as a set of
 `RewritePattern`s, either imperatively defined in C++ or declaratively as
 [Declarative Rewrite Rules](DeclarativeRewrites.md). The pattern rewrite
-infrastructure allows for expressing many different types of canonicalizations.
+infrastructure allows for expressing many different types of canonicalization.
 These transformations may be as simple as replacing a multiplication with a
 shift, or even replacing a conditional branch with an unconditional one.
 
@@ -156,7 +156,7 @@ defining operation rewrites.
 ### Canonicalizing with the `fold` method
 
 The `fold` mechanism is an intentionally limited, but powerful mechanism that
-allows for applying canonicalizations in many places throughout the compiler.
+allows for applying canonicalization in many places throughout the compiler.
 For example, outside of the canonicalizer pass, `fold` is used within the
 [dialect conversion infrastructure](DialectConversion.md) as a legalization
 mechanism, and can be invoked directly anywhere with an `OpBuilder` via

mlir/docs/Dialects/Linalg/_index.md

@@ -478,7 +478,7 @@ The key implication is that this conversion to deep predication needs to be
 undone once we are done with Linalg transformations. After iterators and
 induction variables are materialized (i.e. after lowering out of
 `linalg.generic` occurred), the overall performance will be greatly influenced
-by the quality of canonicalizations, foldings and *Loop Independent Code Motion*
+by the quality of canonicalization, foldings and *Loop Independent Code Motion*
 (LICM).
 
 In the grander scheme, the reliance on late LICM was deemed a necessary risk.

mlir/docs/PDLL.md

@@ -699,7 +699,7 @@ Pattern {
 }
 ```
 
-Below are the set of contexts in which result type inferrence is supported:
+Below are the set of contexts in which result type inference is supported:
 
 ##### Inferred Results of Replacement Operation
 

mlir/docs/Rationale/RationaleLinalgDialect.md

@@ -516,7 +516,7 @@ write, easy to verify and easy to maintain.
 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
+rules. This allows mixing transformations, canonicalization, 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 for solving certain
 [phase ordering issues](https://dl.acm.org/doi/10.1145/201059.201061).

mlir/docs/Tutorials/Toy/Ch-4.md

@@ -16,7 +16,7 @@ like Toy to get the information they need.
 
 MLIR provides a set of always available-hooks for certain core transformations,
 as seen in the [previous chapter](Ch-3.md), where we registered some
-canonicalizations via a hook on our operations (`getCanonicalizationPatterns`).
+canonicalization via a hook on our operations (`getCanonicalizationPatterns`).
 However, these types of hooks don't really scale well. Therefore, a more generic
 solution was designed, in the form of [interfaces](../../Interfaces.md), to make
 the MLIR infrastructure as extensible as the representation. Interfaces provide

mlir/docs/doxygen.cfg.in

@@ -931,7 +931,7 @@ REFERENCES_RELATION    = YES
 REFERENCES_LINK_SOURCE = YES
 
 # If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the
-# source code will show a tooltip with additional information such as prototype,
+# source code will show a tooldip with additional information such as prototype,
 # brief description and links to the definition and documentation. Since this
 # will make the HTML file larger and loading of large files a bit slower, you
 # can opt to disable this feature.

mlir/include/mlir/AsmParser/AsmParser.h

@@ -47,7 +47,7 @@ parseAsmSourceFile(const llvm::SourceMgr &sourceMgr, Block *block,
 /// not, an error diagnostic is emitted to the context and a null value is
 /// returned.
 /// If `numRead` is provided, it is set to the number of consumed characters on
-/// succesful parse. Otherwise, parsing fails if the entire string is not
+/// successful parse. Otherwise, parsing fails if the entire string is not
 /// consumed.
 /// Some internal copying can be skipped if the source string is known to be
 /// null terminated.
@@ -58,7 +58,7 @@ Attribute parseAttribute(llvm::StringRef attrStr, MLIRContext *context,
 /// This parses a single MLIR type to an MLIR context if it was valid. If not,
 /// an error diagnostic is emitted to the context.
 /// If `numRead` is provided, it is set to the number of consumed characters on
-/// succesful parse. Otherwise, parsing fails if the entire string is not
+/// successful parse. Otherwise, parsing fails if the entire string is not
 /// consumed.
 /// Some internal copying can be skipped if the source string is known to be
 /// null terminated.

mlir/include/mlir/Bytecode/BytecodeImplementation.h

@@ -438,7 +438,7 @@ class BytecodeDialectInterface
 
   /// Read a type belonging to this dialect from the given reader. This method
   /// should return null in the case of failure. Optionally, the dialect version
-  /// can be accessed thorugh the reader.
+  /// can be accessed through the reader.
   virtual Type readType(DialectBytecodeReader &reader) const {
     reader.emitError() << "dialect " << getDialect()->getNamespace()
                        << " does not support reading types from bytecode";

mlir/include/mlir/Bytecode/BytecodeReader.h

@@ -57,7 +57,7 @@ class BytecodeReader {
   /// The lazyOps call back is invoked for every ops that can be lazy-loaded.
   /// This let the client decide if the op should be materialized immediately or
   /// delayed.
-  /// !! Using this materialize withing an IR walk() can be confusing: make sure
+  /// !! Using this materialize within an IR walk() can be confusing: make sure
   /// to use a PreOrder traversal !!
   LogicalResult materialize(
       Operation *op, llvm::function_ref<bool(Operation *)> lazyOpsCallback =

mlir/include/mlir/Conversion/TosaToLinalg/TosaToLinalg.h

@@ -32,7 +32,7 @@ std::unique_ptr<Pass> createTosaToLinalgNamed(
 /// Populates passes to convert from TOSA to Linalg on buffers. At the end of
 /// the pass, the function will only contain linalg ops or standard ops if the
 /// pipeline succeeds.  The option to disable decompositions is available for
-/// benchmarking performance improvements from the canonicalizations.
+/// benchmarking performance improvements from the canonicalization.
 void addTosaToLinalgPasses(
     OpPassManager &pm, const TosaToLinalgOptions &options,
     const TosaToLinalgNamedOptions &tosaToLinalgNamedOptions =

mlir/include/mlir/Conversion/VectorToGPU/VectorToGPU.h

@@ -31,7 +31,7 @@ void populatePrepareVectorToMMAPatterns(RewritePatternSet &patterns,
 /// The rest of the vector operations are left untouched.
 LogicalResult convertVectorToMMAOps(RewriterBase &rewriter, Operation *rootOp);
 
-/// Convert vector ops ops nested under `rootOp` to vector and GPU operaitons
+/// Convert vector ops ops nested under `rootOp` to vector and GPU operations
 /// compatible with the `nvvm.mma.sync` lowering path. This will convert a slice
 /// of operations that can be legally lowered on this path while the rest of
 /// the vector operations are left untouched.

mlir/include/mlir/Debug/BreakpointManagers/FileLineColLocBreakpointManager.h

@@ -21,7 +21,7 @@
 namespace mlir {
 namespace tracing {
 
-/// This breakpoing intends to match a FileLineColLocation, that is a tuple of
+/// This breakpoint intends to match a FileLineColLocation, that is a tuple of
 /// file name, line number, and column number. Using -1 for  the column and the
 /// line number will match any column and line number respectively.
 class FileLineColLocBreakpoint

mlir/include/mlir/Dialect/Arith/IR/ArithBase.td

@@ -41,7 +41,7 @@ def Arith_CmpFPredicateAttr : I64EnumAttr<
       I64EnumAttrCase<"OEQ", 1, "oeq">,
       I64EnumAttrCase<"OGT", 2, "ogt">,
       I64EnumAttrCase<"OGE", 3, "oge">,
-      I64EnumAttrCase<"OLT", 4, "olt">,
+      I64EnumAttrCase<"OLT", 4, "old">,
       I64EnumAttrCase<"OLE", 5, "ole">,
       I64EnumAttrCase<"ONE", 6, "one">,
       I64EnumAttrCase<"ORD", 7, "ord">,

mlir/include/mlir/Dialect/Bufferization/IR/BufferizableOpInterface.h

@@ -646,7 +646,7 @@ OpTy replaceOpWithNewBufferizedOp(RewriterBase &rewriter, Operation *op,
 ///
 /// Note: Canonicalization patterns could clean up layout maps and infer more
 /// precise layout maps after bufferization. However, many possible
-/// canonicalizations are currently not implemented.
+/// canonicalization are currently not implemented.
 BaseMemRefType getMemRefType(Value value, const BufferizationOptions &options,
                              MemRefLayoutAttrInterface layout = {},
                              Attribute memorySpace = nullptr);

mlir/include/mlir/Dialect/DLTI/DLTIAttrs.td

@@ -72,7 +72,7 @@ def DLTI_DataLayoutSpecAttr :
     DataLayoutSpecAttr combineWith(ArrayRef<DataLayoutSpecInterface> specs) const;
 
     /// Returns the endiannes identifier.
-    StringAttr getEndiannessIdentifier(MLIRContext *context) const;
+    StringAttr getEndiannesssIdentifier(MLIRContext *context) const;
 
     /// Returns the alloca memory space identifier.
     StringAttr getAllocaMemorySpaceIdentifier(MLIRContext *context) const;

mlir/include/mlir/Dialect/DLTI/DLTIBase.td

@@ -41,13 +41,13 @@ def DLTI_Dialect : Dialect {
 
     // Constants used in entries.
     constexpr const static ::llvm::StringLiteral
-    kDataLayoutEndiannessKey = "dlti.endianness";
+    kDataLayoutEndiannesssKey = "dlti.endianness";
 
     constexpr const static ::llvm::StringLiteral
-    kDataLayoutEndiannessBig = "big";
+    kDataLayoutEndiannesssBig = "big";
 
     constexpr const static ::llvm::StringLiteral
-    kDataLayoutEndiannessLittle = "little";
+    kDataLayoutEndiannesssLittle = "little";
 
     constexpr const static ::llvm::StringLiteral
     kDataLayoutAllocaMemorySpaceKey = "dlti.alloca_memory_space";

mlir/include/mlir/Dialect/LLVMIR/LLVMEnums.td

@@ -544,7 +544,7 @@ def FCmpPredicateFALSE : LLVM_EnumAttrCase<"_false", "_false", "FCMP_FALSE", 0>;
 def FCmpPredicateOEQ   : LLVM_EnumAttrCase<"oeq", "oeq", "FCMP_OEQ", 1>;
 def FCmpPredicateOGT   : LLVM_EnumAttrCase<"ogt", "ogt", "FCMP_OGT", 2>;
 def FCmpPredicateOGE   : LLVM_EnumAttrCase<"oge", "oge", "FCMP_OGE", 3>;
-def FCmpPredicateOLT   : LLVM_EnumAttrCase<"olt", "olt", "FCMP_OLT", 4>;
+def FCmpPredicateOLT   : LLVM_EnumAttrCase<"old", "old", "FCMP_OLT", 4>;
 def FCmpPredicateOLE   : LLVM_EnumAttrCase<"ole", "ole", "FCMP_OLE", 5>;
 def FCmpPredicateONE   : LLVM_EnumAttrCase<"one", "one", "FCMP_ONE", 6>;
 def FCmpPredicateORD   : LLVM_EnumAttrCase<"ord", "ord", "FCMP_ORD", 7>;

mlir/include/mlir/Dialect/Linalg/Transforms/Transforms.h

@@ -1753,7 +1753,7 @@ void populateFuseTensorPadWithProducerLinalgOpPatterns(
     RewritePatternSet &patterns);
 
 /// Patterns to convert from one named op to another. These can be seen as
-/// canonicalizations of named ops into another named op.
+/// canonicalization of named ops into another named op.
 void populateLinalgNamedOpConversionPatterns(RewritePatternSet &patterns);
 
 /// Patterns to fold unit-extent dimensions in operands/results of linalg ops on

mlir/include/mlir/Dialect/Linalg/Utils/Utils.h

@@ -213,7 +213,7 @@ void offsetIndices(RewriterBase &b, LinalgOp linalgOp,
 
 /// A struct containing the Linalg producer before and after fusion.
 /// When operating on tensors, `fusedProducer` may feed into a `tensor.cast`
-/// op before the consumer Linalg op, until enough canonicalizations have
+/// op before the consumer Linalg op, until enough canonicalization have
 /// applied.
 struct FusionInfo {
   LinalgOp originalProducer;

mlir/include/mlir/Dialect/MemRef/IR/MemRefOps.td

@@ -937,7 +937,7 @@ def MemRef_ExtractStridedMetadataOp : MemRef_Op<"extract_strided_metadata", [
     This makes lowering more progressive and brings the following benefits:
       - not all users of MLIR want to lower to LLVM and the information to e.g.
         lower to library calls---like libxsmm---or to SPIR-V was not available.
-      - foldings and canonicalizations can happen at a higher level in MLIR:
+      - foldings and canonicalization can happen at a higher level in MLIR:
         before this op existed, lowering to LLVM would create large amounts of
         LLVMIR. Even when LLVM does a good job at folding the low-level IR from
         a performance perspective, it is unnecessarily opaque and inefficient to

mlir/include/mlir/Dialect/SCF/Transforms/Transforms.h

@@ -56,7 +56,7 @@ void naivelyFuseParallelOps(Region &region,
 /// `partialIteration`). This transformation is called "loop peeling".
 ///
 /// This transformation is beneficial for a wide range of transformations such
-/// as vectorization or loop tiling: It enables additional canonicalizations
+/// as vectorization or loop tiling: It enables additional canonicalization
 /// inside the peeled loop body such as rewriting masked loads into unmaked
 /// loads.
 ///

mlir/include/mlir/Dialect/SCF/Utils/Utils.h

@@ -57,7 +57,7 @@ SmallVector<scf::ForOp> replaceLoopNestWithNewYields(
 /// Assumes the FuncOp result types is the type of the yielded operands of the
 /// single block. This constraint makes it easy to determine the result.
 /// This method also clones the `arith::ConstantIndexOp` at the start of
-/// `outlinedFuncBody` to alloc simple canonicalizations.
+/// `outlinedFuncBody` to alloc simple canonicalization.
 /// Creates a new FuncOp and thus cannot be used in a FuncOp pass.
 /// The client is responsible for providing a unique `funcName` that will not
 /// collide with another FuncOp name.  If `callOp` is provided, it will be set

mlir/include/mlir/Dialect/SparseTensor/IR/SparseTensorOps.td

@@ -1288,7 +1288,7 @@ def SparseTensor_SelectOp : SparseTensor_Op<"select", [Pure, SameOperandsAndResu
           %col = linalg.index 1 : index
           %result = sparse_tensor.select %a : f64 {
               ^bb0(%arg0: f64):
-                %keep = arith.cmpf "olt", %col, %row : f64
+                %keep = arith.cmpf "old", %col, %row : f64
                 sparse_tensor.yield %keep : i1
             }
           linalg.yield %result : f64

mlir/include/mlir/Dialect/Tensor/TransformOps/TensorTransformOps.td

@@ -92,7 +92,7 @@ def ApplyMergeConsecutiveInsertExtractSlicePatternsOp : Op<Transform_Dialect,
     [DeclareOpInterfaceMethods<PatternDescriptorOpInterface>]> {
   let description = [{
     Indicates that consecutive tensor.extract_slice/tensor.insert_slice ops
-    should be merged into a single op. These patterns are not canonicalizations
+    should be merged into a single op. These patterns are not canonicalization
     because the bufferization is sensitive to IR structure.
   }];
 

mlir/include/mlir/IR/AttrTypeBase.td

@@ -164,7 +164,7 @@ class AttrOrTypeDef<string valueType, string name, list<Trait> defTraits,
   // Name of storage class to generate or use.
   string storageClass = name # valueType # "Storage";
 
-  // Namespace (withing dialect c++ namespace) in which the storage class
+  // Namespace (within dialect c++ namespace) in which the storage class
   // resides.
   string storageNamespace = "detail";
 

mlir/include/mlir/IR/OpImplementation.h

@@ -796,7 +796,7 @@ class AsmParser {
   /// least one element will be parsed.
   ///
   /// contextMessage is an optional message appended to "expected '('" sorts of
-  /// diagnostics when parsing the delimeters.
+  /// diagnostics when parsing the delimiters.
   virtual ParseResult
   parseCommaSeparatedList(Delimiter delimiter,
                           function_ref<ParseResult()> parseElementFn,

mlir/include/mlir/IR/OperationSupport.h

@@ -257,7 +257,7 @@ class OperationName {
   ///     success.  The caller will remove the operation and use those results
   ///     instead.
   ///
-  /// This allows expression of some simple in-place canonicalizations (e.g.
+  /// This allows expression of some simple in-place canonicalization (e.g.
   /// "x+0 -> x", "min(x,y,x,z) -> min(x,y,z)", "x+y-x -> y", etc), as well as
   /// generalized constant folding.
   LogicalResult foldHook(Operation *op, ArrayRef<Attribute> operands,

mlir/include/mlir/IR/Threading.h

@@ -6,7 +6,7 @@
 //
 //===----------------------------------------------------------------------===//
 //
-// This file defines various utilies for multithreaded processing within MLIR.
+// This file defines various utilities for multithreaded processing within MLIR.
 // These utilities automatically handle many of the necessary threading
 // conditions, such as properly ordering diagnostics, observing if threading is
 // disabled, etc. These utilities should be used over other threading utilities

mlir/include/mlir/Interfaces/DataLayoutInterfaces.h

@@ -74,7 +74,7 @@ getDefaultIndexBitwidth(Type type, const DataLayout &dataLayout,
 
 /// Default handler for endianness request. Dispatches to the
 /// DataLayoutInterface if specified, otherwise returns the default.
-Attribute getDefaultEndianness(DataLayoutEntryInterface entry);
+Attribute getDefaultEndiannesss(DataLayoutEntryInterface entry);
 
 /// Default handler for alloca memory space request. Dispatches to the
 /// DataLayoutInterface if specified, otherwise returns the default.
@@ -227,7 +227,7 @@ class DataLayout {
   std::optional<uint64_t> getTypeIndexBitwidth(Type t) const;
 
   /// Returns the specified endianness.
-  Attribute getEndianness() const;
+  Attribute getEndiannesss() const;
 
   /// Returns the memory space used for AllocaOps.
   Attribute getAllocaMemorySpace() const;