forked from OSchip/llvm-project
[mlir] NFC: fix trivial typos in documents
Reviewed By: mravishankar Differential Revision: https://reviews.llvm.org/D86563
This commit is contained in:
parent
ea7b1c79f7
commit
603a8a60ba
|
@ -45,8 +45,8 @@ for creation functions). For example, `mlirOperationGetNumOperands` inspects an
|
||||||
|
|
||||||
The *ownership* model is encoded in the naming convention as follows.
|
The *ownership* model is encoded in the naming convention as follows.
|
||||||
|
|
||||||
- By default, the ownership is not transerred.
|
- By default, the ownership is not transferred.
|
||||||
- Functions that tranfer the ownership of the result to the caller can be in
|
- Functions that transfer the ownership of the result to the caller can be in
|
||||||
one of two forms:
|
one of two forms:
|
||||||
* functions that create a new object have the name `mlirXCreate<...>`, for
|
* functions that create a new object have the name `mlirXCreate<...>`, for
|
||||||
example, `mlirOperationCreate`;
|
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
|
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
|
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
|
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
|
*Rationale*: this approach allows the caller to have full control of the
|
||||||
allocation and avoid unnecessary allocation and copying inside the printer.
|
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
|
An object has an _indexed component_ if it has fields accessible using a
|
||||||
zero-based contiguous integer index, typically arrays. For example, an
|
zero-based contiguous integer index, typically arrays. For example, an
|
||||||
`MlirBlock` has its arguments as a indexed component. An object may have several
|
`MlirBlock` has its arguments as an indexed component. An object may have
|
||||||
such components. For example, an `MlirOperation` has attributes, operands,
|
several such components. For example, an `MlirOperation` has attributes,
|
||||||
regions, results and successors.
|
operands, regions, results and successors.
|
||||||
|
|
||||||
For indexed components, the following pair of functions is provided.
|
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.
|
- `MlirY mlirXGet<Y>(MlirX, intptr_t pos)` returns 'pos'-th subobject.
|
||||||
|
|
||||||
The sizes are accepted and returned as signed pointer-sized integers, i.e.
|
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
|
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`.
|
`MlirValue`.
|
||||||
|
|
||||||
### Iterable Components
|
### Iterable Components
|
||||||
|
@ -190,12 +190,12 @@ for (iter = mlirXGetFirst<Y>(x); !mlirYIsNull(iter);
|
||||||
|
|
||||||
### Extensions for Dialect Attributes and Types
|
### 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.
|
types, provided that implementations live in separate directories, i.e.
|
||||||
`include/mlir-c/<...>Dialect/` and `lib/CAPI/<...>Dialect/`. The core APIs
|
`include/mlir-c/<...>Dialect/` and `lib/CAPI/<...>Dialect/`. The core APIs
|
||||||
provide implementation-private headers in `include/mlir/CAPI/IR` that allow one
|
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++
|
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
|
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
|
implementation should rely on `isa` to implement `mlirXIsAY` and is expected to
|
||||||
use `cast` inside other API calls.
|
use `cast` inside other API calls.
|
||||||
|
|
|
@ -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
|
buffers arbitrarily and write into them. If this conflicts with some parallel
|
||||||
iterator requirement, this is undefined behavior.
|
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
|
// File name: example3.mlir
|
||||||
#indexing_maps = [
|
#indexing_maps = [
|
||||||
|
|
|
@ -1078,7 +1078,7 @@ to convert between the internal storage and the helper method.
|
||||||
|
|
||||||
### Attribute decorators
|
### 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
|
applied to ODS attributes to specify common additional properties like
|
||||||
optionality, default values, etc.:
|
optionality, default values, etc.:
|
||||||
|
|
||||||
|
|
|
@ -214,7 +214,7 @@ operations.
|
||||||
We allow `index` types in tensors and memrefs as a code generation strategy has
|
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
|
to map `index` to an implementation type and hence needs to be able to
|
||||||
materialize corresponding values. However, the target might lack support for
|
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
|
### Bit width of a non-primitive type and `index` is undefined
|
||||||
|
|
||||||
|
|
|
@ -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,
|
size of the previous struct elements) are **not** supported. In this case,
|
||||||
offsets can be emulated with padding fields (*e.g.* integers). However, such
|
offsets can be emulated with padding fields (*e.g.* integers). However, such
|
||||||
a design would require index recalculation in the conversion of ops that
|
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:
|
Examples of SPIR-V struct conversion are:
|
||||||
```mlir
|
```mlir
|
||||||
|
@ -204,7 +204,7 @@ to note:
|
||||||
be:
|
be:
|
||||||
|
|
||||||
```mlir
|
```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>
|
%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>
|
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,
|
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
|
a stack overflow may occur. For this case, `stacksave`/`stackrestore` pair can
|
||||||
be used (TODO).
|
be used (TODO).
|
||||||
|
@ -618,7 +618,7 @@ As well as:
|
||||||
|
|
||||||
`spv.Branch` and `spv.BranchConditional` are mapped to `llvm.br` and
|
`spv.Branch` and `spv.BranchConditional` are mapped to `llvm.br` and
|
||||||
`llvm.cond_br`. Branch weigths for `spv.BranchConditional` are mapped to
|
`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
|
proper LLVM, `branch_weights` are converted into LLVM metadata associated with
|
||||||
the conditional branch.
|
the conditional branch.
|
||||||
|
|
||||||
|
@ -744,7 +744,7 @@ to LLVM dialect.
|
||||||
|
|
||||||
### `spv.func`
|
### `spv.func`
|
||||||
This op declares or defines a SPIR-V function and it is converted to `llvm.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).
|
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
|
The following mapping is used to map [SPIR-V function control](SPIRVFunctionAttributes) to
|
||||||
|
|
Loading…
Reference in New Issue