squiid/llvm
1
0
Fork 0
Code Issues Pull requests Activity

Fix grammar and punctuation across several docs; NFC

Browse source
This commit is contained in:
Priyansh Singh 2022-04-07 07:11:11 -04:00 committed by Aaron Ballman
parent 094e80882c
commit d356cdcf31
6 changed files with 35 additions and 34 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
README.md
View file

@ -1,6 +1,6 @@
# The LLVM Compiler Infrastructure # The LLVM Compiler Infrastructure
This directory and its sub-directories contain source code for LLVM, This directory and its sub-directories contain the source code for LLVM,
a toolkit for the construction of highly optimized compilers, a toolkit for the construction of highly optimized compilers,
optimizers, and run-time environments. optimizers, and run-time environments.
@ -33,7 +33,7 @@ the [LLD linker](https://lld.llvm.org), and more.
### Getting the Source Code and Building LLVM ### Getting the Source Code and Building LLVM
The LLVM Getting Started documentation may be out of date. The [Clang The LLVM Getting Started documentation may be out of date. The [Clang
Getting Started](http://clang.llvm.org/get_started.html) page might have more Getting Started](http://clang.llvm.org/get_started.html) page might have more
accurate information. accurate information.
@ -101,7 +101,7 @@ This is an example work-flow and configuration to get and build the LLVM source:
LLVM sub-projects generate their own ``check-<project>`` target. LLVM sub-projects generate their own ``check-<project>`` target.
* Running a serial build will be **slow**. To improve speed, try running a * Running a serial build will be **slow**. To improve speed, try running a
parallel build. That's done by default in Ninja; for ``make``, use the option parallel build. That's done by default in Ninja; for ``make``, use the option
``-j NNN``, where ``NNN`` is the number of parallel jobs to run. ``-j NNN``, where ``NNN`` is the number of parallel jobs to run.
In most cases, you get the best performance if you specify the number of CPU threads you have. In most cases, you get the best performance if you specify the number of CPU threads you have.
On some Unix systems, you can specify this with ``-j$(nproc)``. On some Unix systems, you can specify this with ``-j$(nproc)``.

10
mlir/docs/Interfaces.md
View file

@ -37,7 +37,7 @@ utilities for registering an interface with a dialect so that it can be
referenced later. Once the interface has been defined, dialects can override it referenced later. Once the interface has been defined, dialects can override it
using dialect-specific information. The interfaces defined by a dialect are using dialect-specific information. The interfaces defined by a dialect are
registered via `addInterfaces<>`, a similar mechanism to Attributes, Operations, registered via `addInterfaces<>`, a similar mechanism to Attributes, Operations,
Types, etc Types, etc.
```c++ ```c++
/// Define a base inlining interface class to allow for dialects to opt-in to /// Define a base inlining interface class to allow for dialects to opt-in to
@ -86,7 +86,7 @@ if (DialectInlinerInterface *interface = dyn_cast<DialectInlinerInterface>(diale
#### DialectInterfaceCollection #### DialectInterfaceCollection
An additional utility is provided via `DialectInterfaceCollection`. This class An additional utility is provided via `DialectInterfaceCollection`. This class
allows for collecting all of the dialects that have registered a given interface allows collecting all of the dialects that have registered a given interface
within an instance of the `MLIRContext`. This can be useful to hide and optimize within an instance of the `MLIRContext`. This can be useful to hide and optimize
the lookup of a registered dialect interface. the lookup of a registered dialect interface.
@ -394,8 +394,8 @@ comprised of the following components:
accessed with full name qualification. accessed with full name qualification.
* Extra Shared Class Declarations (Optional: `extraSharedClassDeclaration`) * Extra Shared Class Declarations (Optional: `extraSharedClassDeclaration`)
- Additional C++ code that is injected into the declarations of both the - Additional C++ code that is injected into the declarations of both the
interface and trait class. This allows for defining methods and more interface and the trait class. This allows for defining methods and more
that are exposed on both the interface and trait class, e.g. to inject that are exposed on both the interface and the trait class, e.g. to inject
utilties on both the interface and the derived entity implementing the utilties on both the interface and the derived entity implementing the
interface (e.g. attribute, operation, etc.). interface (e.g. attribute, operation, etc.).
- In non-static methods, `$_attr`/`$_op`/`$_type` - In non-static methods, `$_attr`/`$_op`/`$_type`
@ -617,7 +617,7 @@ def MyInterface : OpInterface<"MyInterface"> {
} }
// Operation interfaces can optionally be wrapped inside // Operation interfaces can optionally be wrapped inside
// DeclareOpInterfaceMethods. This would result in autogenerating declarations // `DeclareOpInterfaceMethods`. This would result in autogenerating declarations
// for members `foo`, `bar` and `fooStatic`. Methods with bodies are not // for members `foo`, `bar` and `fooStatic`. Methods with bodies are not
// declared inside the op declaration but instead handled by the op interface // declared inside the op declaration but instead handled by the op interface
// trait directly. // trait directly.

37
mlir/docs/OpDefinitions.md
View file

@ -23,7 +23,7 @@ operations. This open and extensible ecosystem leads to the "stringly" type IR
problem, e.g., repetitive string comparisons during optimization and analysis problem, e.g., repetitive string comparisons during optimization and analysis
passes, unintuitive accessor methods (e.g., generic/error prone `getOperand(3)` passes, unintuitive accessor methods (e.g., generic/error prone `getOperand(3)`
vs self-documenting `getStride()`) with more generic return types, verbose and vs self-documenting `getStride()`) with more generic return types, verbose and
generic constructors without default arguments, verbose textual IR dump, and so generic constructors without default arguments, verbose textual IR dumps, and so
on. Furthermore, operation verification is: on. Furthermore, operation verification is:
1. best case: a central string-to-verification-function map, 1. best case: a central string-to-verification-function map,
@ -57,7 +57,7 @@ including but not limited to:
We use TableGen as the language for specifying operation information. TableGen We use TableGen as the language for specifying operation information. TableGen
itself just provides syntax for writing records; the syntax and constructs itself just provides syntax for writing records; the syntax and constructs
allowed in a TableGen file (typically with filename suffix `.td`) can be found allowed in a TableGen file (typically with the filename suffix `.td`) can be found
[here][TableGenProgRef]. [here][TableGenProgRef].
* TableGen `class` is similar to C++ class; it can be templated and * TableGen `class` is similar to C++ class; it can be templated and
@ -80,7 +80,7 @@ types and expressions supported by TableGen.
MLIR defines several common constructs to help operation definition and provide MLIR defines several common constructs to help operation definition and provide
their semantics via a special [TableGen backend][TableGenBackend]: their semantics via a special [TableGen backend][TableGenBackend]:
[`OpDefinitionsGen`][OpDefinitionsGen]. These constructs are defined in [`OpDefinitionsGen`][OpDefinitionsGen]. These constructs are defined in
[`OpBase.td`][OpBase]. The main ones are [`OpBase.td`][OpBase]. The main ones are:
* The `Op` class: It is the main construct for defining operations. All facts * The `Op` class: It is the main construct for defining operations. All facts
regarding the operation are specified when specializing this class, with the regarding the operation are specified when specializing this class, with the
@ -91,7 +91,7 @@ their semantics via a special [TableGen backend][TableGenBackend]:
and constraints of the operation, including whether the operation has side and constraints of the operation, including whether the operation has side
effect or whether its output has the same shape as the input. effect or whether its output has the same shape as the input.
* The `ins`/`outs` marker: These are two special markers builtin to the * The `ins`/`outs` marker: These are two special markers builtin to the
`OpDefinitionsGen` backend. They lead the definitions of operands/attributes `OpDefinitionsGen` backend. They lead to the definitions of operands/attributes
and results respectively. and results respectively.
* The `TypeConstraint` class hierarchy: They are used to specify the * The `TypeConstraint` class hierarchy: They are used to specify the
constraints over operands or results. A notable subclass hierarchy is constraints over operands or results. A notable subclass hierarchy is
@ -134,7 +134,7 @@ the `Op` class for the complete list of fields supported.
### Operation name ### Operation name
The operation name is a unique identifier of the operation within MLIR, e.g., The operation name is a unique identifier for the operation within MLIR, e.g.,
`tf.Add` for addition operation in the TensorFlow dialect. This is the `tf.Add` for addition operation in the TensorFlow dialect. This is the
equivalent of the mnemonic in assembly language. It is used for parsing and equivalent of the mnemonic in assembly language. It is used for parsing and
printing in the textual format. It is also used for pattern matching in graph printing in the textual format. It is also used for pattern matching in graph
@ -207,12 +207,13 @@ named argument a named getter will be generated that returns the argument with
the return type (in the case of attributes the return type will be constructed the return type (in the case of attributes the return type will be constructed
from the storage type, while for operands it will be `Value`). Each attribute's from the storage type, while for operands it will be `Value`). Each attribute's
raw value (e.g., as stored) can also be accessed via generated `<name>Attr` raw value (e.g., as stored) can also be accessed via generated `<name>Attr`
getters for use in transformation passes where the more user friendly return getters for use in transformation passes where the more user-friendly return
type is less suitable. type is less suitable.
All the arguments should be named to 1) provide documentation, 2) drive All the arguments should be named to:
auto-generation of getter methods, 3) provide a handle to reference for other - provide documentation,
places like constraints. - drive auto-generation of getter methods, and
- provide a handle to reference for other places like constraints.
#### Variadic operands #### Variadic operands
@ -221,7 +222,7 @@ To declare a variadic operand, wrap the `TypeConstraint` for the operand with
Normally operations have no variadic operands or just one variadic operand. For Normally operations have no variadic operands or just one variadic operand. For
the latter case, it is easy to deduce which dynamic operands are for the static the latter case, it is easy to deduce which dynamic operands are for the static
variadic operand definition. Though, if an operation has more than one variable variadic operand definition. However, if an operation has more than one variable
length operands (either optional or variadic), it would be impossible to length operands (either optional or variadic), it would be impossible to
attribute dynamic operands to the corresponding static variadic operand attribute dynamic operands to the corresponding static variadic operand
definitions without further information from the operation. Therefore, either definitions without further information from the operation. Therefore, either
@ -247,7 +248,7 @@ To declare an optional operand, wrap the `TypeConstraint` for the operand with
Normally operations have no optional operands or just one optional operand. For Normally operations have no optional operands or just one optional operand. For
the latter case, it is easy to deduce which dynamic operands are for the static the latter case, it is easy to deduce which dynamic operands are for the static
operand definition. Though, if an operation has more than one variable length operand definition. However, if an operation has more than one variable length
operands (either optional or variadic), it would be impossible to attribute operands (either optional or variadic), it would be impossible to attribute
dynamic operands to the corresponding static variadic operand definitions dynamic operands to the corresponding static variadic operand definitions
without further information from the operation. Therefore, either the without further information from the operation. Therefore, either the
@ -425,7 +426,7 @@ The first form provides basic uniformity so that we can create ops using the
same form regardless of the exact op. This is particularly useful for same form regardless of the exact op. This is particularly useful for
implementing declarative pattern rewrites. implementing declarative pattern rewrites.
The second and third forms are good for use in manually written code given that The second and third forms are good for use in manually written code, given that
they provide better guarantee via signatures. they provide better guarantee via signatures.
The third form will be generated if any of the op's attribute has different The third form will be generated if any of the op's attribute has different
@ -434,14 +435,14 @@ from an unwrapped value (i.e., `Attr.constBuilderCall` is defined.)
Additionally, for the third form, if an attribute appearing later in the Additionally, for the third form, if an attribute appearing later in the
`arguments` list has a default value, the default value will be supplied in the `arguments` list has a default value, the default value will be supplied in the
declaration. This works for `BoolAttr`, `StrAttr`, `EnumAttr` for now and the declaration. This works for `BoolAttr`, `StrAttr`, `EnumAttr` for now and the
list can grow in the future. So if possible, default valued attribute should be list can grow in the future. So if possible, the default-valued attribute should be
placed at the end of the `arguments` list to leverage this feature. (This placed at the end of the `arguments` list to leverage this feature. (This
behavior is essentially due to C++ function parameter default value placement behavior is essentially due to C++ function parameter default value placement
restrictions.) Otherwise, the builder of the third form will still be generated restrictions.) Otherwise, the builder of the third form will still be generated
but default values for the attributes not at the end of the `arguments` list but default values for the attributes not at the end of the `arguments` list
will not be supplied in the builder's signature. will not be supplied in the builder's signature.
ODS will generate a builder that doesn't require return type specified if ODS will generate a builder that doesn't require the return type specified if
* Op implements InferTypeOpInterface interface; * Op implements InferTypeOpInterface interface;
* All return types are either buildable types or are the same as a given * All return types are either buildable types or are the same as a given
@ -581,18 +582,18 @@ of these verification methods.
The verification of an operation involves several steps, The verification of an operation involves several steps,
1. StructuralOpTrait will be verified first, they can be run independently. 1. StructuralOpTrait will be verified first, they can be run independently.
1. `verifyInvariants` which is constructed by ODS, it verifies the type, 2. `verifyInvariants` which is constructed by ODS, it verifies the type,
attributes, .etc. attributes, .etc.
1. Other Traits/Interfaces that have marked their verifier as `verifyTrait` or 3. Other Traits/Interfaces that have marked their verifier as `verifyTrait` or
`verifyWithRegions=0`. `verifyWithRegions=0`.
1. Custom verifier which is defined in the op and has marked `hasVerifier=1` 4. Custom verifier which is defined in the op and has been marked `hasVerifier=1`
If an operation has regions, then it may have the second phase, If an operation has regions, then it may have the second phase,
1. Traits/Interfaces that have marked their verifier as `verifyRegionTrait` or 1. Traits/Interfaces that have marked their verifier as `verifyRegionTrait` or
`verifyWithRegions=1`. This implies the verifier needs to access the `verifyWithRegions=1`. This implies the verifier needs to access the
operations in its regions. operations in its regions.
1. Custom verifier which is defined in the op and has marked 2. Custom verifier which is defined in the op and has been marked
`hasRegionVerifier=1` `hasRegionVerifier=1`
Note that the second phase will be run after the operations in the region are Note that the second phase will be run after the operations in the region are

2
mlir/docs/PDLL.md
View file

@ -33,7 +33,7 @@ that no longer exist.
### Why build a new language instead of improving TableGen DRR? ### Why build a new language instead of improving TableGen DRR?
Note: The section assumes familiarity with Note: This section assumes familiarity with
[TDRR](https://mlir.llvm.org/docs/DeclarativeRewrites/), please refer the [TDRR](https://mlir.llvm.org/docs/DeclarativeRewrites/), please refer the
relevant documentation before continuing. relevant documentation before continuing.

12
mlir/docs/PassManagement.md
View file

@ -128,7 +128,7 @@ Dialects must be loaded in the MLIRContext before entities from these dialects
(operations, types, attributes, ...) can be created. Dialects must also be (operations, types, attributes, ...) can be created. Dialects must also be
loaded before starting the execution of a multi-threaded pass pipeline. To this loaded before starting the execution of a multi-threaded pass pipeline. To this
end, a pass that may create an entity from a dialect that isn't guaranteed to end, a pass that may create an entity from a dialect that isn't guaranteed to
already ne loaded must express this by overriding the `getDependentDialects()` already be loaded must express this by overriding the `getDependentDialects()`
method and declare this list of Dialects explicitly. method and declare this list of Dialects explicitly.
### Initialization ### Initialization
@ -818,7 +818,7 @@ string corresponding to the operation type that the pass operates on. The class
contains the following fields: contains the following fields:
* `summary` * `summary`
- A short one line summary of the pass, used as the description when - A short one-line summary of the pass, used as the description when
registering the pass. registering the pass.
* `description` * `description`
- A longer, more detailed description of the pass. This is used when - A longer, more detailed description of the pass. This is used when
@ -847,7 +847,7 @@ class takes the following template parameters:
* default value * default value
- The default option value. - The default option value.
* description * description
- A one line description of the option. - A one-line description of the option.
* additional option flags * additional option flags
- A string containing any additional options necessary to construct the - A string containing any additional options necessary to construct the
option. option.
@ -870,7 +870,7 @@ The `ListOption` class takes the following fields:
* element type * element type
- The C++ type of the list element. - The C++ type of the list element.
* description * description
- A one line description of the option. - A one-line description of the option.
* additional option flags * additional option flags
- A string containing any additional options necessary to construct the - A string containing any additional options necessary to construct the
option. option.
@ -894,7 +894,7 @@ template parameters:
* display name * display name
- The name used when displaying the statistic. - The name used when displaying the statistic.
* description * description
- A one line description of the statistic. - A one-line description of the statistic.
```tablegen ```tablegen
def MyPass : Pass<"my-pass"> { def MyPass : Pass<"my-pass"> {
@ -938,7 +938,7 @@ PassInstrumentation instances may be registered directly with a
Instrumentations added to the PassManager are run in a stack like fashion, i.e. Instrumentations added to the PassManager are run in a stack like fashion, i.e.
the last instrumentation to execute a `runBefore*` hook will be the first to the last instrumentation to execute a `runBefore*` hook will be the first to
execute the respective `runAfter*` hook. The hooks of a `PassInstrumentation` execute the respective `runAfter*` hook. The hooks of a `PassInstrumentation`
class are guaranteed to be executed in a thread safe fashion, so additional class are guaranteed to be executed in a thread-safe fashion, so additional
synchronization is not necessary. Below in an example instrumentation that synchronization is not necessary. Below in an example instrumentation that
counts the number of times the `DominanceInfo` analysis is computed: counts the number of times the `DominanceInfo` analysis is computed:

2
mlir/docs/PatternRewriter.md
View file

@ -232,7 +232,7 @@ creation, as well as many useful attribute and type construction methods.
## Pattern Application ## Pattern Application
After a set of patterns have been defined, they are collected and provided to a After a set of patterns have been defined, they are collected and provided to a
specific driver for application. A driver consists of several high levels parts: specific driver for application. A driver consists of several high level parts:
* Input `RewritePatternSet` * Input `RewritePatternSet`