From a2bce652af5ed78ff2463cfe927f880e8bb54b49 Mon Sep 17 00:00:00 2001 From: Kazuaki Ishizaki Date: Wed, 25 Sep 2019 11:57:13 -0700 Subject: [PATCH] Minor spelling tweaks Closes tensorflow/mlir#145 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/145 from kiszk:spelling_tweaks_g3doc ae9140aab5b797441e880d43e557903585815e40 PiperOrigin-RevId: 271173907 --- mlir/g3doc/Canonicalization.md | 2 +- mlir/g3doc/DeclarativeRewrites.md | 24 +++++++++---------- mlir/g3doc/DefiningAttributesAndTypes.md | 4 ++-- mlir/g3doc/DeveloperGuide.md | 2 +- mlir/g3doc/Dialects/Affine.md | 4 ++-- mlir/g3doc/Dialects/LLVM.md | 2 +- mlir/g3doc/Dialects/SPIR-V.md | 10 ++++---- mlir/g3doc/Dialects/Vector.md | 2 +- mlir/g3doc/GenericDAGRewriter.md | 2 +- mlir/g3doc/LangRef.md | 14 ++++++----- mlir/g3doc/MLIRForGraphAlgorithms.md | 10 ++++---- mlir/g3doc/OpDefinitions.md | 16 ++++++------- mlir/g3doc/Quantization.md | 4 ++-- mlir/g3doc/QuickstartRewrites.md | 4 ++-- mlir/g3doc/Rationale.md | 14 +++++------ .../RationaleSimplifiedPolyhedralForm.md | 4 ++-- mlir/g3doc/TestingGuide.md | 4 ++-- mlir/g3doc/Tutorials/Linalg/Ch-1.md | 4 ++-- mlir/g3doc/Tutorials/Linalg/LLVMConversion.md | 6 ++--- mlir/g3doc/Tutorials/Toy/Ch-1.md | 2 +- 20 files changed, 68 insertions(+), 66 deletions(-) diff --git a/mlir/g3doc/Canonicalization.md b/mlir/g3doc/Canonicalization.md index d3691cf14b16..197328cb0d22 100644 --- a/mlir/g3doc/Canonicalization.md +++ b/mlir/g3doc/Canonicalization.md @@ -38,7 +38,7 @@ Some important things to think about w.r.t. canonicalization patterns: ## Globally Applied Rules -These transformation are applied to all levels of IR: +These transformations are applied to all levels of IR: * Elimination of operations that have no side effects and have no uses. diff --git a/mlir/g3doc/DeclarativeRewrites.md b/mlir/g3doc/DeclarativeRewrites.md index b7664a0b21a6..4c767136a8fa 100644 --- a/mlir/g3doc/DeclarativeRewrites.md +++ b/mlir/g3doc/DeclarativeRewrites.md @@ -25,14 +25,14 @@ benefits, including but not limited to: * **Being declarative**: The pattern creator just needs to state the rewrite pattern declaratively, without worrying about the concrete C++ methods to call. -* **Removing boilerplate and showing the very essense the the rewrite**: +* **Removing boilerplate and showing the very essence of the rewrite**: `mlir::RewritePattern` is already good at hiding boilerplate for defining a rewrite rule. But we still need to write the class and function structures required by the C++ programming language, inspect ops for matching, and call op `build()` methods for constructing. These statements are typically quite simple and similar, so they can be further condensed with auto-generation. Because we reduce the boilerplate to the bare minimum, the declarative - rewrite rule will just contain the very essense of the rewrite. This makes + rewrite rule will just contain the very essence of the rewrite. This makes it very easy to understand the pattern. ## Strengths and Limitations @@ -239,7 +239,7 @@ to replace the matched `AOp`. #### Binding op results -In the result pattern, we can bind to the result(s) of an newly built op by +In the result pattern, we can bind to the result(s) of a newly built op by attaching symbols to the op. (But we **cannot** bind to op arguments given that they are referencing previously bound symbols.) This is useful for reusing newly created results where suitable. For example, @@ -270,7 +270,7 @@ directly fed in as arguments to build the new op. For such cases, we can apply transformations on the arguments by calling into C++ helper functions. This is achieved by `NativeCodeCall`. -For example, if we want to catpure some op's attributes and group them as an +For example, if we want to capture some op's attributes and group them as an array attribute to construct a new op: ```tblgen @@ -361,7 +361,7 @@ $in2)`, then this will be translated into C++ call `someFn($in1, $in2, $in0)`. ##### Customizing entire op building `NativeCodeCall` is not only limited to transforming arguments for building an -op; it can also used to specify how to build an op entirely. An example: +op; it can be also used to specify how to build an op entirely. An example: If we have a C++ function for building an op: @@ -379,10 +379,10 @@ def : Pat<(... $input, $attr), (createMyOp $input, $attr)>; ### Supporting auxiliary ops -A declarative rewrite rule supports multiple result patterns. One of the purpose -is to allow generating _auxiliary ops_. Auxiliary ops are operations used for -building the replacement ops; but they are not directly used for replacement -themselves. +A declarative rewrite rule supports multiple result patterns. One of the +purposes is to allow generating _auxiliary ops_. Auxiliary ops are operations +used for building the replacement ops; but they are not directly used for +replacement themselves. For the case of uni-result ops, if there are multiple result patterns, only the value generated from the last result pattern will be used to replace the matched @@ -556,7 +556,7 @@ correspond to multiple actual values. Constraints can be placed on op arguments when matching. But sometimes we need to also place constraints on the matched op's results or sometimes need to limit -the matching with some constraints that cover both the arugments and the +the matching with some constraints that cover both the arguments and the results. The third parameter to `Pattern` (and `Pat`) is for this purpose. For example, we can write @@ -587,7 +587,7 @@ You can ### Adjusting benefits -The benefit of a `Pattern` is an integer value indicating the benfit of matching +The benefit of a `Pattern` is an integer value indicating the benefit of matching the pattern. It determines the priorities of patterns inside the pattern rewrite driver. A pattern with a higher benefit is applied before one with a lower benefit. @@ -599,7 +599,7 @@ pattern. This is based on the heuristics and assumptions that: * If a smaller one is applied first the larger one may not apply anymore. -The forth parameter to `Pattern` (and `Pat`) allows to manually tweak a +The fourth parameter to `Pattern` (and `Pat`) allows to manually tweak a pattern's benefit. Just supply `(addBenefit N)` to add `N` to the benefit value. ## Special directives diff --git a/mlir/g3doc/DefiningAttributesAndTypes.md b/mlir/g3doc/DefiningAttributesAndTypes.md index 82399e3566fa..60243e5fd57f 100644 --- a/mlir/g3doc/DefiningAttributesAndTypes.md +++ b/mlir/g3doc/DefiningAttributesAndTypes.md @@ -55,7 +55,7 @@ enum Kinds { ### Defining the type class As described above, `Type` objects in MLIR are value-typed and rely on having an -implicity internal storage object that holds the actual data for the type. When +implicitly internal storage object that holds the actual data for the type. When defining a new `Type` it isn't always necessary to define a new storage class. So before defining the derived `Type`, it's important to know which of the two classes of `Type` we are defining. Some types are `primitives` meaning they do @@ -256,7 +256,7 @@ Once the dialect types have been defined, they must then be registered with a ```c++ struct MyDialect : public Dialect { MyDialect(MLIRContext *context) : Dialect(/*name=*/"mydialect", context) { - /// Add these types to the dialcet. + /// Add these types to the dialect. addTypes(); } }; diff --git a/mlir/g3doc/DeveloperGuide.md b/mlir/g3doc/DeveloperGuide.md index 97c4dd8166a7..cddc5ae95556 100644 --- a/mlir/g3doc/DeveloperGuide.md +++ b/mlir/g3doc/DeveloperGuide.md @@ -12,7 +12,7 @@ LLVM style guide: * Adopts [camelBack](https://llvm.org/docs/Proposals/VariableNames.html); * Except for IR units (Region, Block, and Operation), non-nullable output - argument are passed by non-const reference in general. + arguments are passed by non-const reference in general. * IR constructs are not designed for [const correctness](UsageOfConst.md). * Do *not* use recursive algorithms if the recursion can't be bounded statically: that is avoid recursion if there is a possible IR input that can diff --git a/mlir/g3doc/Dialects/Affine.md b/mlir/g3doc/Dialects/Affine.md index 6b1b84b108d7..98e451f58836 100644 --- a/mlir/g3doc/Dialects/Affine.md +++ b/mlir/g3doc/Dialects/Affine.md @@ -105,7 +105,7 @@ parenthesization, (2) negation, (3) modulo, multiplication, floordiv, and ceildiv, and (4) addition and subtraction. All of these operators associate from left to right. -A _multi-dimensional affine expression_ is a comma separated list of +A _multidimensional affine expression_ is a comma separated list of one-dimensional affine expressions, with the entire list enclosed in parentheses. @@ -119,7 +119,7 @@ affine function. MLIR further extends the definition of an affine function to allow 'floordiv', 'ceildiv', and 'mod' with respect to positive integer constants. Such extensions to affine functions have often been referred to as quasi-affine functions by the polyhedral compiler community. MLIR uses the term -'affine map' to refer to these multi-dimensional quasi-affine functions. As +'affine map' to refer to these multidimensional quasi-affine functions. As examples, $$(i+j+1, j)$$, $$(i \mod 2, j+i)$$, $$(j, i/4, i \mod 4)$$, $$(2i+1, j)$$ are two-dimensional affine functions of $$(i, j)$$, but $$(i \cdot j, i^2)$$, $$(i \mod j, i/j)$$ are not affine functions of $$(i, j)$$. diff --git a/mlir/g3doc/Dialects/LLVM.md b/mlir/g3doc/Dialects/LLVM.md index 460229d20555..f1422a8164e4 100644 --- a/mlir/g3doc/Dialects/LLVM.md +++ b/mlir/g3doc/Dialects/LLVM.md @@ -109,7 +109,7 @@ Examples: In these operations, `` must be a value of wrapped LLVM IR integer type, `
` must be a value of wrapped LLVM IR pointer type, and `` must -be a value of wrapped LLVM IR type that corresponds to the pointee type of +be a value of wrapped LLVM IR type that corresponds to the pointer type of `
`. The `index` operands are integer values whose semantics is identical to the diff --git a/mlir/g3doc/Dialects/SPIR-V.md b/mlir/g3doc/Dialects/SPIR-V.md index b1d83b16231f..e954b6716e07 100644 --- a/mlir/g3doc/Dialects/SPIR-V.md +++ b/mlir/g3doc/Dialects/SPIR-V.md @@ -20,7 +20,7 @@ format and to facilitate transformations. Therefore, it should * Stay as the same semantic level and try to be a mechanical 1:1 mapping; * But deviate representationally if possible with MLIR mechanisms. -* Be straightforward to serialize into and deserialize drom the SPIR-V binary +* Be straightforward to serialize into and deserialize from the SPIR-V binary format. ## Conventions @@ -55,10 +55,10 @@ instructions are represented in the SPIR-V dialect. Notably, * Requirements for capabilities, extensions, extended instruction sets, addressing model, and memory model is conveyed using `spv.module` attributes. This is considered better because these information are for the - exexcution environment. It's eaiser to probe them if on the module op + execution environment. It's easier to probe them if on the module op itself. -* Annotations/decoration instrutions are "folded" into the instructions they - decorate and represented as attributes on those ops. This elimiates +* Annotations/decoration instructions are "folded" into the instructions they + decorate and represented as attributes on those ops. This eliminates potential forward references of SSA values, improves IR readability, and makes querying the annotations more direct. * Types are represented using MLIR standard types and SPIR-V dialect specific @@ -252,7 +252,7 @@ block, one loop continue block, one merge block. ... \ | / v - +-------------+ (may have mulitple incoming branches) + +-------------+ (may have multiple incoming branches) | merge block | +-------------+ ``` diff --git a/mlir/g3doc/Dialects/Vector.md b/mlir/g3doc/Dialects/Vector.md index 30a79d720f8a..ea916bbb2d3d 100644 --- a/mlir/g3doc/Dialects/Vector.md +++ b/mlir/g3doc/Dialects/Vector.md @@ -92,7 +92,7 @@ for %i = 0 to 3 { On a GPU one could then map `i`, `j`, `k` to blocks and threads. Notice that the temporary storage footprint is `3 * 5` values but `3 * 4 * 5` values are -actually transferred betwen `%A` and `%tmp`. +actually transferred between `%A` and `%tmp`. Alternatively, if a notional vector broadcast operation were available, the lowered code would resemble: diff --git a/mlir/g3doc/GenericDAGRewriter.md b/mlir/g3doc/GenericDAGRewriter.md index c814a27b12c1..3b26c22eb378 100644 --- a/mlir/g3doc/GenericDAGRewriter.md +++ b/mlir/g3doc/GenericDAGRewriter.md @@ -349,7 +349,7 @@ that match predicates eliminate the need for dynamically computed costs in almost all cases: you can simply instantiate the same pattern one time for each possible cost and use the predicate to guard the match. -The two phase nature of this API (match separate from rewrite) is important for +The two-phase nature of this API (match separate from rewrite) is important for two reasons: 1) some clients may want to explore different ways to tile the graph, and only rewrite after committing to one tiling. 2) We want to support runtime extensibility of the pattern sets, but want to be able to statically diff --git a/mlir/g3doc/LangRef.md b/mlir/g3doc/LangRef.md index a87022729963..e80cf061f536 100644 --- a/mlir/g3doc/LangRef.md +++ b/mlir/g3doc/LangRef.md @@ -312,8 +312,8 @@ it. An MLIR Function is an operation with a name containing one [region](#regions). The region of a function is not allowed to implicitly capture values defined -outside of the function, and all external references must use Function arguments -or attributes that establish a symbolic connection(e.g. symbols referenced by +outside of the function, and all external references must use function arguments +or attributes that establish a symbolic connection (e.g. symbols referenced by name via a string attribute like [SymbolRefAttr](#symbol-reference-attribute)): ``` {.ebnf} @@ -455,12 +455,14 @@ func @accelerator_compute(i64, i1) -> i64 { ^bb2: "accelerator.launch"() { ^bb0: - // Region of code nested under "accelerator_launch", it can reference %a but + // Region of code nested under "accelerator.launch", it can reference %a but // not %value. %new_value = "accelerator.do_something"(%a) : (i64) -> () } // %new_value cannot be referenced outside of the region -... + +^bb3: + ... } ``` @@ -796,7 +798,7 @@ memref<16x32xf32, #identity, memspace0> // f32 elements. %T = alloc(%M, %N) [%B1, %B2] : memref -// A memref that has a two element padding at either end. The allocation size +// A memref that has a two-element padding at either end. The allocation size // will fit 16 * 68 float elements of data. %P = alloc() : memref<16x64xf32, #padded> @@ -1296,7 +1298,7 @@ Syntax: integer-set-attribute ::= affine-map ``` -An integer-set attribute is an attribute that represents a integer-set object. +An integer-set attribute is an attribute that represents an integer-set object. #### String Attribute diff --git a/mlir/g3doc/MLIRForGraphAlgorithms.md b/mlir/g3doc/MLIRForGraphAlgorithms.md index 2c5619a04313..9130d031b4f1 100644 --- a/mlir/g3doc/MLIRForGraphAlgorithms.md +++ b/mlir/g3doc/MLIRForGraphAlgorithms.md @@ -116,7 +116,7 @@ of the benefits that MLIR provides, in no particular order: The MLIR in-memory data structure has a human readable and writable format, as well as [a specification](LangRef.md) for that format - built just like any -other programming language. Important properties of this format is that it is +other programming language. Important properties of this format are that it is compact, easy to read, and lossless. You can dump an MLIR program out to disk and munge around with it, then send it through a few more passes. @@ -139,7 +139,7 @@ the product more reliable, and making it easier to track down bugs when they appear - because the verifier can be run at any time, either as a compiler pass or with a single function call. -While MLIR provides a well considered infrastructure for IR verification, and +While MLIR provides a well-considered infrastructure for IR verification, and has simple checks for existing TensorFlow operations, there is a lot that should be added here and lots of opportunity to get involved! @@ -166,7 +166,7 @@ turned into zero: The "CHECK" comments are interpreted by the [LLVM FileCheck tool](https://llvm.org/docs/CommandGuide/FileCheck.html), which -is sort of like a really advanced grep. This test is fully self contained: it +is sort of like a really advanced grep. This test is fully self-contained: it feeds the input into the [canonicalize pass](Canonicalization.md), and checks that the output matches the CHECK lines. See the `test/Transforms` directory for more examples. In contrast, standard unit testing exposes the API of the @@ -258,7 +258,7 @@ This is still a work in progress, but we have sightlines towards a tiles into other DAG tiles, using a declarative pattern format. DAG to DAG rewriting is a generalized solution for many common compiler optimizations, lowerings, and other rewrites and having an IR enables us to invest in building -a single high quality implementation. +a single high-quality implementation. Declarative pattern rules are preferable to imperative C++ code for a number of reasons: they are more compact, easier to reason about, can have checkers @@ -313,7 +313,7 @@ transformations) today, and are committed to pushing hard to make it better. MLIR has been designed to be memory and compile-time efficient in its algorithms and data structures, using immutable and uniqued structures, low level -bit-packing, and other well known techniques to avoid unnecessary heap +bit-packing, and other well-known techniques to avoid unnecessary heap allocations, and allow simple and safe multithreaded optimization of MLIR programs. There are other reasons to believe that the MLIR implementations of common transformations will be more efficient than the Python and C++ diff --git a/mlir/g3doc/OpDefinitions.md b/mlir/g3doc/OpDefinitions.md index 20255a508820..28cab5d1f85e 100644 --- a/mlir/g3doc/OpDefinitions.md +++ b/mlir/g3doc/OpDefinitions.md @@ -242,7 +242,7 @@ like `"0.5f"`, and an integer array default value should be specified as like `Confined` is provided as a general mechanism to help modelling further constraints on attributes beyond the ones brought by value types. You can use `Confined` to compose complex constraints out of more primitive ones. For -example, an 32-bit integer attribute whose minimal value must be 10 can be +example, a 32-bit integer attribute whose minimal value must be 10 can be expressed as `Confined]>`. Right now, the following primitive constraints are supported: @@ -373,7 +373,7 @@ def MyInterface : OpInterface<"MyInterface"> { ### Custom builder methods -For each operation, there are two builder automatically generated based on the +For each operation, there are two builders automatically generated based on the arguments and returns types: ```c++ @@ -388,7 +388,7 @@ static void build(Builder *, OperationState &tblgen_state, ArrayRef attributes); ``` -The above cases makes sure basic uniformity so that we can create ops using the +The above cases make sure basic uniformity so that we can create ops using the same form regardless of the exact op. This is particularly useful for implementing declarative pattern rewrites. @@ -572,7 +572,7 @@ a float tensor, and so on. Similarly, a set of `AttrConstraint`s are created for helping modelling constraints of common attribute kinds. They are the `Attr` subclass hierarchy. -It includes `F32Attr` for the constraints of being an float attribute, +It includes `F32Attr` for the constraints of being a float attribute, `F32ArrayAttr` for the constraints of being a float array attribute, and so on. ### Multi-entity constraint @@ -648,7 +648,7 @@ replaced by the current attribute `attr` at expansion time. For more complicated predicates, you can wrap it in a single `CPred`, or you can use predicate combiners to combine them. For example, to write the -constraint that an attribute `attr` is an 32-bit or 64-bit integer, you can +constraint that an attribute `attr` is a 32-bit or 64-bit integer, you can write it as ```tablegen @@ -695,9 +695,9 @@ def MyOp : Op<...> { As to whether we should define the predicate using a single `CPred` wrapping the whole expression, multiple `CPred`s with predicate combiners, or a single `CPred` "invoking" a function, there are no clear-cut criteria. Defining using -`CPred` and predicate combiners is preferrable since it exposes more information +`CPred` and predicate combiners is preferable since it exposes more information (instead hiding all the logic behind a C++ function) into the op definition spec -so that it can pontentially drive more auto-generation cases. But it will +so that it can potentially drive more auto-generation cases. But it will require a nice library of common predicates as the building blocks to avoid the duplication, which is being worked on right now. @@ -928,7 +928,7 @@ the output type (shape) for given input type (shape). But shape functions are determined by attributes and could be arbitrarily complicated with a wide-range of specification possibilities. Equality -relationship are common (e.g., the elemental type of the output matches the +relationships are common (e.g., the elemental type of the output matches the primitive type of the inputs, both inputs have exactly the same type [primitive type and shape]) and so these should be easy to specify. Algebraic relationships would also be common (e.g., a concat of `[n,m]` and `[n,m]` matrix along axis 0 diff --git a/mlir/g3doc/Quantization.md b/mlir/g3doc/Quantization.md index 531f6b984cc0..99e450ca84da 100644 --- a/mlir/g3doc/Quantization.md +++ b/mlir/g3doc/Quantization.md @@ -79,7 +79,7 @@ In order to exactly represent the Real zero with an integral-valued affine value, the zero point must be an integer between the minimum and maximum affine value (inclusive). For example, given an affine value represented by an 8 bit unsigned integer, we have: $$ 0 \leq zero\_point \leq 255$$. This is important, -because in deep neural networks's convolution-like operations, we frequently +because in deep neural networks' convolution-like operations, we frequently need to zero-pad inputs and outputs, so zero must be exactly representable, or the result will be biased. @@ -123,7 +123,7 @@ $$ In the above, we assume that $$real\_value$$ is a Single, $$scale$$ is a Single, $$roundToNearestInteger$$ returns a signed 32 bit integer, and $$zero\_point$$ is an unsigned 8 or 16 bit integer. Note that bit depth and number of fixed -point values is indicative of common types on typical hardware but is not +point values are indicative of common types on typical hardware but is not constrained to particular bit depths or a requirement that the entire range of an N-bit integer is used. diff --git a/mlir/g3doc/QuickstartRewrites.md b/mlir/g3doc/QuickstartRewrites.md index bd7d4d4fac19..2e2192071aee 100644 --- a/mlir/g3doc/QuickstartRewrites.md +++ b/mlir/g3doc/QuickstartRewrites.md @@ -10,7 +10,7 @@ See [MLIR specification](LangRef.md) for more information about MLIR, the structure of the IR, operations, etc. See [Table-driven Operation Definition](OpDefinitions.md) and [Declarative Rewrite Rule](DeclarativeRewrites.md) for the detailed explanation -of all available mechansims for defining operations and rewrites in a +of all available mechanisms for defining operations and rewrites in a table-driven manner. ## Adding operation @@ -90,7 +90,7 @@ OpFoldResult SpecificOp::fold(ArrayRef constOperands) { There are multiple forms of graph rewrite that can be performed in MLIR. One of the most common is DAG tile to DAG tile rewrite. Patterns provide a concise way to express this transformation as a pair of source pattern to match and -resultant pattern. There is both the C++ classes to represent this +resultant pattern. There are both the C++ classes to represent this transformation, as well as the patterns in TableGen from which these can be generated. diff --git a/mlir/g3doc/Rationale.md b/mlir/g3doc/Rationale.md index 9ecd7fb6124f..3122e3cb24de 100644 --- a/mlir/g3doc/Rationale.md +++ b/mlir/g3doc/Rationale.md @@ -39,7 +39,7 @@ neural network accelerators. MLIR uses ideas drawn from IRs of LLVM and Swift for lower level constructs while combining them with ideas from the polyhedral abstraction to represent -loop nests, multi-dimensional data (tensors), and transformations on these +loop nests, multidimensional data (tensors), and transformations on these entities as first class concepts in the IR. MLIR is a multi-level IR, i.e., it represents code at a domain-specific @@ -58,7 +58,7 @@ polyhedral abstraction. Maps, sets, and relations with affine constraints are the core structures underlying a polyhedral representation of high-dimensional loop nests and -multi-dimensional arrays. These structures are represented as textual +multidimensional arrays. These structures are represented as textual 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 @@ -513,7 +513,7 @@ parsing/printing, will be available. Dialect extended types are represented as string literals wrapped inside of the dialect namespace. This means that the parser delegates to the dialect for parsing specific type instances. This differs from the representation of dialect -defined operations, of which have a identifier name that the parser uses to +defined operations, of which have an identifier name that the parser uses to identify and parse them. This representation was chosen for several reasons: @@ -773,7 +773,7 @@ our current design in practice. The current MLIR uses a representation of polyhedral schedules using a tree of if/for loops. We extensively debated the tradeoffs involved in the typical unordered polyhedral instruction representation (where each instruction has -multi-dimensional schedule information), discussed the benefits of schedule tree +multidimensional schedule information), discussed the benefits of schedule tree forms, and eventually decided to go with a syntactic tree of affine if/else conditionals and affine for loops. Discussion of the tradeoff was captured in this document: @@ -806,7 +806,7 @@ At a high level, we have two alternatives here: This representation is based on a simplified form of the domain/schedule representation used by the polyhedral compiler community. Domains represent what has to be executed while schedules represent the order in which domain elements -are interleaved. We model domains as non piece-wise convex integer sets, and +are interleaved. We model domains as non-piece-wise convex integer sets, and schedules as affine functions; however, the former can be disjunctive, and the latter can be piece-wise affine relations. In the schedule tree representation, domain and schedules for instructions are represented in a tree-like structure @@ -1110,7 +1110,7 @@ The problem is that LLVM has several objects in its IR that are globally uniqued and also mutable: notably constants like `i32 0`. In LLVM, these constants are `Value*r`'s, which allow them to be used as operands to instructions, and that they also have SSA use lists. Because these things are uniqued, every `i32 0` in -any function share a use list. This means that optimizing multiple functions in +any function shares a use list. This means that optimizing multiple functions in parallel won't work (at least without some sort of synchronization on the use lists, which would be unbearably inefficient). @@ -1122,7 +1122,7 @@ expressions, types, etc are all immutable, uniqued, and immortal). 2) constants are defined in per-function pools, instead of being globally uniqued. 3) functions themselves are not SSA values either, so they don't have the same problem as constants. 4) FunctionPasses are copied (through their copy ctor) -into one instances per thread, avoiding sharing of local state across threads. +into one instance per thread, avoiding sharing of local state across threads. This allows MLIR function passes to support efficient multithreaded compilation and code generation. diff --git a/mlir/g3doc/RationaleSimplifiedPolyhedralForm.md b/mlir/g3doc/RationaleSimplifiedPolyhedralForm.md index eb8e28b000e1..ec2ecc9fe502 100644 --- a/mlir/g3doc/RationaleSimplifiedPolyhedralForm.md +++ b/mlir/g3doc/RationaleSimplifiedPolyhedralForm.md @@ -10,7 +10,7 @@ This document is a very early design proposal (which has since been accepted) that explored the tradeoffs of using this simplified form vs the traditional polyhedral schedule list form. At some point, this document could be dusted off and written as a proper academic paper, but until now, it is better to included -it in this crufty form than not to. Beware that this document uses archaic +it in this crafty form than not to. Beware that this document uses archaic syntax and should not be considered a canonical reference to modern MLIR. ## Introduction @@ -282,7 +282,7 @@ transformations want to be explicit about what they are doing. ### Simplicity of code generation -A key final stage of an mlfunc is its conversion to a cfg function, which is +A key final stage of an mlfunc is its conversion to a CFG function, which is required as part of lowering to the target machine. The simplified form has a clear advantage here: the IR has a direct correspondence to the structure of the generated code. diff --git a/mlir/g3doc/TestingGuide.md b/mlir/g3doc/TestingGuide.md index e7e3f448dbd4..5a8c039fdd63 100644 --- a/mlir/g3doc/TestingGuide.md +++ b/mlir/g3doc/TestingGuide.md @@ -49,8 +49,8 @@ elimination, only one constant remains in the IR. FileCheck is an extremely useful utility, it allows for easily matching various parts of the output. This ease of use means that it becomes easy to write brittle tests that are essentially `diff` tests. FileCheck tests should be as -self contained as possible and focus on testing the minimal set of functionality -needed. Let's see an example: +self-contained as possible and focus on testing the minimal set of +functionalities needed. Let's see an example: ```mlir {.mlir} // RUN: mlir-opt %s -cse | FileCheck %s diff --git a/mlir/g3doc/Tutorials/Linalg/Ch-1.md b/mlir/g3doc/Tutorials/Linalg/Ch-1.md index 95e9f109f069..1bbeb42965e6 100644 --- a/mlir/g3doc/Tutorials/Linalg/Ch-1.md +++ b/mlir/g3doc/Tutorials/Linalg/Ch-1.md @@ -65,7 +65,7 @@ public: ``` Unlike more complex types, RangeType does not require a hashing key for -unique'ing in the `MLIRContext`. Note that all MLIR types derive from +uniquing in the `MLIRContext`. Note that all MLIR types derive from `mlir::Type::TypeBase` and expose `using Base::Base` to enable generic hooks to work properly (in this instance for llvm-style casts. RangeType does not even require an implementation file as the above represents the whole code for the @@ -187,7 +187,7 @@ view it slices and pretty-prints as: %2 = linalg.slice %1[*, *, %0, *] : !linalg.view ``` -In this particular case, %2 slices dimension `2` of the four dimensional view +In this particular case, %2 slices dimension `2` of the four-dimensional view %1. The returned `!linalg.view` indicates that the indexing is rank-reducing and that %0 is an `index`. diff --git a/mlir/g3doc/Tutorials/Linalg/LLVMConversion.md b/mlir/g3doc/Tutorials/Linalg/LLVMConversion.md index baeec7b90de9..52c458d3736a 100644 --- a/mlir/g3doc/Tutorials/Linalg/LLVMConversion.md +++ b/mlir/g3doc/Tutorials/Linalg/LLVMConversion.md @@ -227,7 +227,7 @@ public: PatternMatchResult match(Operation *op) const override; // A "rewriting" function that takes an original operation `op`, a list of - // already rewritten opreands, and a function builder `rewriter`. It can use + // already rewritten operands, and a function builder `rewriter`. It can use // the builder to construct new operations and ultimately create new values // that will replace those currently produced by the original operation. It // needs to define as many value as the original operation, but their types @@ -259,7 +259,7 @@ PatternMatchResult ViewOpConversion::match(Operation *op) const override { } ``` -The actual conversion function may become quite involved. First, Let us go over +The actual conversion function may become quite involved. First, let us go over the components of a view descriptor and see how they can be constructed to represent a _complete_ view of a `memref`, e.g. a view that covers all its elements. @@ -412,7 +412,7 @@ struct ViewDescriptor { return builder.getArrayAttr(attrs); } - // Emit instructions obtaining individual values from the decsriptor. + // Emit instructions obtaining individual values from the descriptor. Value *ptr() { return intrinsics::extractvalue(elementPtrType(), d, pos(0)); } Value *offset() { return intrinsics::extractvalue(indexType(), d, pos(1)); } Value *size(unsigned dim) { diff --git a/mlir/g3doc/Tutorials/Toy/Ch-1.md b/mlir/g3doc/Tutorials/Toy/Ch-1.md index 72f1cc3e36a5..0e275d0b458b 100644 --- a/mlir/g3doc/Tutorials/Toy/Ch-1.md +++ b/mlir/g3doc/Tutorials/Toy/Ch-1.md @@ -82,7 +82,7 @@ def main() { # reuse the previously specialized and inferred version and return `<2, 2>` var d = multiply_transpose(b, a); - # A new call with `<2, 2>` for both dimension will trigger another + # A new call with `<2, 2>` for both dimensions will trigger another # specialization of `multiply_transpose`. var e = multiply_transpose(c, d);