[Mlir-commits] [mlir] 603a8a6 - [mlir] NFC: fix trivial typos in documents
Kazuaki Ishizaki
llvmlistbot at llvm.org
Wed Aug 26 11:50:46 PDT 2020
Author: Kazuaki Ishizaki
Date: 2020-08-27T03:50:34+09:00
New Revision: 603a8a60ba444eb7fc77f0b31dd063a7583df2c4
URL: https://github.com/llvm/llvm-project/commit/603a8a60ba444eb7fc77f0b31dd063a7583df2c4
DIFF: https://github.com/llvm/llvm-project/commit/603a8a60ba444eb7fc77f0b31dd063a7583df2c4.diff
LOG: [mlir] NFC: fix trivial typos in documents
Reviewed By: mravishankar
Differential Revision: https://reviews.llvm.org/D86563
Added:
Modified:
mlir/docs/CAPI.md
mlir/docs/Dialects/Linalg.md
mlir/docs/OpDefinitions.md
mlir/docs/Rationale/Rationale.md
mlir/docs/SPIRVToLLVMDialectConversion.md
Removed:
################################################################################
diff --git a/mlir/docs/CAPI.md b/mlir/docs/CAPI.md
index 68a28950ebc3..2ec25d15747c 100644
--- a/mlir/docs/CAPI.md
+++ b/mlir/docs/CAPI.md
@@ -45,8 +45,8 @@ for creation functions). For example, `mlirOperationGetNumOperands` inspects an
The *ownership* model is encoded in the naming convention as follows.
-- By default, the ownership is not transerred.
-- Functions that tranfer the ownership of the result to the caller can be in
+- By default, the ownership is not transferred.
+- Functions that transfer the ownership of the result to the caller can be in
one of two forms:
* functions that create a new object have the name `mlirXCreate<...>`, for
example, `mlirOperationCreate`;
@@ -127,7 +127,7 @@ stored and perform the copy. There is no guarantee that the pointer supplied to
the callback points to a null-terminated string, the size argument should be
used to find the end of the string. The callback may be called multiple times
with consecutive chunks of the string representation (the printing itself is
-bufferred).
+buffered).
*Rationale*: this approach allows the caller to have full control of the
allocation and avoid unnecessary allocation and copying inside the printer.
@@ -143,9 +143,9 @@ The API adopts the following patterns for recurrent functionality in MLIR.
An object has an _indexed component_ if it has fields accessible using a
zero-based contiguous integer index, typically arrays. For example, an
-`MlirBlock` has its arguments as a indexed component. An object may have several
-such components. For example, an `MlirOperation` has attributes, operands,
-regions, results and successors.
+`MlirBlock` has its arguments as an indexed component. An object may have
+several such components. For example, an `MlirOperation` has attributes,
+operands, regions, results and successors.
For indexed components, the following pair of functions is provided.
@@ -153,10 +153,10 @@ For indexed components, the following pair of functions is provided.
- `MlirY mlirXGet<Y>(MlirX, intptr_t pos)` returns 'pos'-th subobject.
The sizes are accepted and returned as signed pointer-sized integers, i.e.
-`intptr_t`. This typedef is avalable in C99.
+`intptr_t`. This typedef is available in C99.
Note that the name of subobject in the function does not necessarily match the
-type of the subobject. For example, `mlirOperationGetOperand` returns a
+type of the subobject. For example, `mlirOperationGetOperand` returns an
`MlirValue`.
### Iterable Components
@@ -190,12 +190,12 @@ for (iter = mlirXGetFirst<Y>(x); !mlirYIsNull(iter);
### Extensions for Dialect Attributes and Types
-Dialect attributes and types can follow the example of standard attrbutes and
+Dialect attributes and types can follow the example of standard attributes and
types, provided that implementations live in separate directories, i.e.
`include/mlir-c/<...>Dialect/` and `lib/CAPI/<...>Dialect/`. The core APIs
provide implementation-private headers in `include/mlir/CAPI/IR` that allow one
to convert between opaque C structures for core IR components and their C++
counterparts. `wrap` converts a C++ class into a C structure and `unwrap` does
-the inverse conversion. Once the a C++ object is available, the API
+the inverse conversion. Once the C++ object is available, the API
implementation should rely on `isa` to implement `mlirXIsAY` and is expected to
use `cast` inside other API calls.
diff --git a/mlir/docs/Dialects/Linalg.md b/mlir/docs/Dialects/Linalg.md
index edf5eb217799..7ae1b73f48a7 100644
--- a/mlir/docs/Dialects/Linalg.md
+++ b/mlir/docs/Dialects/Linalg.md
@@ -268,7 +268,7 @@ to correspond to the operations inside the region: the region can capture
buffers arbitrarily and write into them. If this conflicts with some parallel
iterator requirement, this is undefined behavior.
-Previous examples already ellaborate compute payloads with an unregistered function `"some_compute"`. The following code snippet shows what the result will be when using a concrete operation `addf`:
+Previous examples already elaborate compute payloads with an unregistered function `"some_compute"`. The following code snippet shows what the result will be when using a concrete operation `addf`:
```
// File name: example3.mlir
#indexing_maps = [
diff --git a/mlir/docs/OpDefinitions.md b/mlir/docs/OpDefinitions.md
index 0997f2972743..418da6a857dc 100644
--- a/mlir/docs/OpDefinitions.md
+++ b/mlir/docs/OpDefinitions.md
@@ -1078,7 +1078,7 @@ to convert between the internal storage and the helper method.
### Attribute decorators
-There are a few important attribute adapters/decorators/modifers that can be
+There are a few important attribute adapters/decorators/modifiers that can be
applied to ODS attributes to specify common additional properties like
optionality, default values, etc.:
diff --git a/mlir/docs/Rationale/Rationale.md b/mlir/docs/Rationale/Rationale.md
index e67bf9de8684..c7953e685958 100644
--- a/mlir/docs/Rationale/Rationale.md
+++ b/mlir/docs/Rationale/Rationale.md
@@ -214,7 +214,7 @@ operations.
We allow `index` types in tensors and memrefs as a code generation strategy has
to map `index` to an implementation type and hence needs to be able to
materialize corresponding values. However, the target might lack support for
-`vector` values with the target specfic equivalent of the `index` type.
+`vector` values with the target specific equivalent of the `index` type.
### Bit width of a non-primitive type and `index` is undefined
diff --git a/mlir/docs/SPIRVToLLVMDialectConversion.md b/mlir/docs/SPIRVToLLVMDialectConversion.md
index 799107e033a4..c5a157930527 100644
--- a/mlir/docs/SPIRVToLLVMDialectConversion.md
+++ b/mlir/docs/SPIRVToLLVMDialectConversion.md
@@ -84,7 +84,7 @@ at the moment. Hence, we adhere to the following mapping:
size of the previous struct elements) are **not** supported. In this case,
offsets can be emulated with padding fields (*e.g.* integers). However, such
a design would require index recalculation in the conversion of ops that
- involve memmory addressing.
+ involve memory addressing.
Examples of SPIR-V struct conversion are:
```mlir
@@ -204,7 +204,7 @@ to note:
be:
```mlir
- // Zero extending offest after broadcasting
+ // Zero extending offset after broadcasting
%res_offset = llvm.zext %vec_offset: !llvm.vec<2 x i8> to !llvm.vec<2 x i32>
```
@@ -515,7 +515,7 @@ Also, at the moment initialization is only possible via `spv.constant`.
llvm.store %c, %res : !llvm.ptr<i64>
```
-Note that simple conversion to `alloca` may not be sufficent if the code has
+Note that simple conversion to `alloca` may not be sufficient if the code has
some scoping. For example, if converting ops executed in a loop into `alloca`s,
a stack overflow may occur. For this case, `stacksave`/`stackrestore` pair can
be used (TODO).
@@ -618,7 +618,7 @@ As well as:
`spv.Branch` and `spv.BranchConditional` are mapped to `llvm.br` and
`llvm.cond_br`. Branch weigths for `spv.BranchConditional` are mapped to
-coresponding `branch_weights` attribute of `llvm.cond_br`. When translated to
+corresponding `branch_weights` attribute of `llvm.cond_br`. When translated to
proper LLVM, `branch_weights` are converted into LLVM metadata associated with
the conditional branch.
@@ -744,7 +744,7 @@ to LLVM dialect.
### `spv.func`
This op declares or defines a SPIR-V function and it is converted to `llvm.func`.
-This conversion handles signarture conversion, and function control attributes
+This conversion handles signature conversion, and function control attributes
remapping to LLVM dialect function [`passthrough` attribute](Dialects/LLVM.md#Attribute-pass-through).
The following mapping is used to map [SPIR-V function control](SPIRVFunctionAttributes) to
More information about the Mlir-commits
mailing list