[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 =