[PATCH] D76726: Allow IndexType inside tensors.

[Sean Silva via Phabricator via llvm-commits]

silvas updated this revision to Diff 252442.
silvas added a comment.

update


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76726/new/

https://reviews.llvm.org/D76726

Files:
  mlir/docs/Rationale.md
  mlir/include/mlir/IR/StandardTypes.h
  mlir/test/IR/invalid.mlir


Index: mlir/test/IR/invalid.mlir
===================================================================
--- mlir/test/IR/invalid.mlir
+++ mlir/test/IR/invalid.mlir
@@ -23,10 +23,6 @@
 
 func @indexmemref(memref<? x index>) -> () // 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}}
Index: mlir/include/mlir/IR/StandardTypes.h
===================================================================
--- mlir/include/mlir/IR/StandardTypes.h
+++ mlir/include/mlir/IR/StandardTypes.h
@@ -330,7 +330,7 @@
     // element type within that dialect.
     return type.isa<ComplexType>() || type.isa<FloatType>() ||
            type.isa<IntegerType>() || type.isa<OpaqueType>() ||
-           type.isa<VectorType>() ||
+           type.isa<VectorType>() || type.isa<IndexType>() ||
            (type.getKind() > Type::Kind::LAST_STANDARD_TYPE);
   }
 
Index: mlir/docs/Rationale.md
===================================================================
--- mlir/docs/Rationale.md
+++ 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 type disallowed in vector/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<?xindex>` 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 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<?xindex>` 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D76726.252442.patch
Type: text/x-patch
Size: 4194 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200324/211f4ff4/attachment-0001.bin>