diff --git a/mlir/docs/Rationale.md b/mlir/docs/Rationale.md --- a/mlir/docs/Rationale.md +++ b/mlir/docs/Rationale.md @@ -202,21 +202,21 @@ interest [starts here](https://www.google.com/url?q=https://youtu.be/Ntj8ab-5cvE?t%3D596&sa=D&ust=1529450150971000&usg=AFQjCNFQHEWL7m8q3eO-1DiKw9zqC2v24Q). -### Index type disallowed in vector/tensor/memref types - -Index types are not allowed as elements of `vector`, `tensor` or `memref` type. -Index types are intended to be used for platform-specific "size" values and may -appear in subscripts, sizes of aggregate types and affine expressions. They are -also tightly coupled with `affine.apply` and affine.load/store operations; -having `index` type is a necessary precondition of a value to be acceptable by -these operations. While it may be useful to have `memref` to express -indirect accesses, e.g. sparse matrix manipulations or lookup tables, it creates -problems MLIR is not ready to address yet. MLIR needs to internally store -constants of aggregate types and emit code operating on values of those types, -which are subject to target-specific size and alignment constraints. Since MLIR -does not have a target description mechanism at the moment, it cannot reliably -emit such code. Moreover, some platforms may not support vectors of type -equivalent to `index`. +### Index type disallowed in vector/memref types + +Index types are not allowed as elements of `vector` and `memref` types. Index +types are intended to be used for platform-specific "size" values and may appear +in subscripts, sizes of aggregate types and affine expressions. They are also +tightly coupled with `affine.apply` and affine.load/store operations; having +`index` type is a necessary precondition of a value to be acceptable by these +operations. While it may be useful to have `memref` to express indirect +accesses, e.g. sparse matrix manipulations or lookup tables, it creates problems +MLIR is not ready to address yet. MLIR needs to internally store constants of +aggregate types and emit code operating on values of those types, which are +subject to target-specific size and alignment constraints. Since MLIR does not +have a target description mechanism at the moment, it cannot reliably emit such +code. Moreover, some platforms may not support vectors of type equivalent to +`index`. Indirect access use cases can be alternatively supported by providing and `index_cast` instruction that allows for conversion between `index` and @@ -224,6 +224,11 @@ of supporting smaller integer types, e.g. `i8` or `i16`, for small indices instead of (presumably larger) `index` type. +Index types are allowed as element types of `tensor` types. The `tensor` type +specifically abstracts the target-specific aspects that intersect with the +code-generation-related/lowering-related concerns explained above. In fact, the +`tensor` type even allows dialect-specific types as element types. + ### Bit width of a non-primitive types and `index` is undefined The bit width of a compound type is not defined by MLIR, it may be defined by a diff --git a/mlir/include/mlir/IR/StandardTypes.h b/mlir/include/mlir/IR/StandardTypes.h --- a/mlir/include/mlir/IR/StandardTypes.h +++ b/mlir/include/mlir/IR/StandardTypes.h @@ -330,7 +330,7 @@ // element type within that dialect. return type.isa() || type.isa() || type.isa() || type.isa() || - type.isa() || + type.isa() || type.isa() || (type.getKind() > Type::Kind::LAST_STANDARD_TYPE); } diff --git a/mlir/test/IR/invalid.mlir b/mlir/test/IR/invalid.mlir --- a/mlir/test/IR/invalid.mlir +++ b/mlir/test/IR/invalid.mlir @@ -24,10 +24,6 @@ func @indexmemref(memref) -> () // expected-error {{invalid memref element type}} // ----- - -func @indextensor(tensor<4 x index>) -> () // expected-error {{invalid tensor element type}} - -// ----- // Test no map in memref type. func @memrefs(memref<2x4xi8, >) // expected-error {{expected list element}}