[Mlir-commits] [mlir] 3dceb6d - Allow IndexType inside tensors.

[Sean Silva]

Author: Sean Silva
Date: 2020-03-26T10:52:48-07:00
New Revision: 3dceb6d2460550ef8c2e53df2181c8a11a7e6730

URL: https://github.com/llvm/llvm-project/commit/3dceb6d2460550ef8c2e53df2181c8a11a7e6730
DIFF: https://github.com/llvm/llvm-project/commit/3dceb6d2460550ef8c2e53df2181c8a11a7e6730.diff

LOG: Allow IndexType inside tensors.

It's common in many dialects to use tensors to themselves hold tensor shapes (for example, the shape is itself the result of some non-trivial calculation). Currently, such dialects have to use `tensor<?xi64>` or worse (like allowing either i32 or i64 tensors to represent shapes). `tensor<?xindex>` is the natural type to represent this, but is currently disallowed. This patch allows it.

Differential Revision: https://reviews.llvm.org/D76726

Added: 
    

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

Removed: 
    


################################################################################
diff  --git a/mlir/docs/Rationale.md b/mlir/docs/Rationale.md
index ff475fd849e2..e76bae7bb645 100644
--- a/mlir/docs/Rationale.md
+++ b/mlir/docs/Rationale.md
@@ -202,21 +202,21 @@ and described in
 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<?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 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<?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 @@ fixed-width integer types, at the SSA value level. It has an additional benefit
 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
index 1c18e21006dc..b9774eb22de1 100644
--- a/mlir/include/mlir/IR/StandardTypes.h
+++ b/mlir/include/mlir/IR/StandardTypes.h
@@ -330,7 +330,7 @@ class TensorType : public ShapedType {
     // 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);
   }
 

diff  --git a/mlir/test/IR/invalid.mlir b/mlir/test/IR/invalid.mlir
index bf4a5fff386a..478888434c5e 100644
--- a/mlir/test/IR/invalid.mlir
+++ b/mlir/test/IR/invalid.mlir
@@ -23,10 +23,6 @@ func @indexvector(vector<4 x index>) -> () // expected-error {{vector elements m
 
 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}}