TTobias Gysi[mlir] Add a builtin distinct attribute
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir] Add a builtin distinct attribute A distinct attribute associates a referenced attribute with a unique identifier. Every call to its create function allocates a new distinct attribute instance. The address of the attribute instance temporarily serves as its unique identifier. Similar to the names of SSA values, the final unique identifiers are generated during pretty printing. Examples: #distinct = distinct[0]<42.0 : f32> #distinct1 = distinct[1]<42.0 : f32> #distinct2 = distinct[2]<array<i32: 10, 42>> This mechanism is meant to generate attributes with a unique identifier, which can be used to mark groups of operations that share a common properties such as if they are aliasing. The design of the distinct attribute ensures minimal memory footprint per distinct attribute since it only contains a reference to another attribute. All distinct attributes are stored outside of the storage uniquer in a thread local store that is part of the context. It uses one bump pointer allocator per thread to ensure distinct attributes can be created in-parallel. Reviewed By: rriddle, Dinistro, zero9178 Differential Revision: https://reviews.llvm.org/D153360 | 3 年前 | |
[mlir] Add test-convergence option to Canonicalizer tests This new option is set to false by default. It should be set only in Canonicalizer tests to detect faulty canonicalization patterns. I.e., patterns that prevent the canonicalizer from converging. The canonicalizer should always convergence on such small unit tests that we have in canonicalize.mlir. Two faulty canonicalization patterns were detected and fixed with this change. Differential Revision: https://reviews.llvm.org/D140873 | 3 年前 | |
[mlir][VectorType] Allow arbitrary dimensions to be scalable At the moment, only the trailing dimensions in the vector type can be scalable, i.e. this is supported: vector<2x[4]xf32> and this is not allowed: vector<[2]x4xf32> This patch extends the vector type so that arbitrary dimensions can be scalable. To this end, an array of bool values is added to every vector type to denote whether the corresponding dimensions are scalable or not. For example, for this vector: vector<[2]x[3]x4xf32> the following array would be created: {true, true, false}. Additionally, the current syntax: vector<[2x3]x4xf32> is replaced with: vector<[2]x[3]x4xf32> This is primarily to simplify parsing (this way, the parser can easily process one dimension at a time rather than e.g. tracking whether "scalable block" has been entered/left). NOTE: The isScalableDim parameter of VectorType (introduced in this patch) makes numScalableDims redundant. For the time being, numScalableDims is preserved to facilitate the transition between the two parameters. numScalableDims will be removed in one of the subsequent patches. This change is a part of a larger effort to enable scalable vectorisation in Linalg. See this RFC for more context: * https://discourse.llvm.org/t/rfc-scalable-vectorisation-in-linalg/ Differential Revision: https://reviews.llvm.org/D153372 | 3 年前 | |
[mlir][VectorType] Allow arbitrary dimensions to be scalable At the moment, only the trailing dimensions in the vector type can be scalable, i.e. this is supported: vector<2x[4]xf32> and this is not allowed: vector<[2]x4xf32> This patch extends the vector type so that arbitrary dimensions can be scalable. To this end, an array of bool values is added to every vector type to denote whether the corresponding dimensions are scalable or not. For example, for this vector: vector<[2]x[3]x4xf32> the following array would be created: {true, true, false}. Additionally, the current syntax: vector<[2x3]x4xf32> is replaced with: vector<[2]x[3]x4xf32> This is primarily to simplify parsing (this way, the parser can easily process one dimension at a time rather than e.g. tracking whether "scalable block" has been entered/left). NOTE: The isScalableDim parameter of VectorType (introduced in this patch) makes numScalableDims redundant. For the time being, numScalableDims is preserved to facilitate the transition between the two parameters. numScalableDims will be removed in one of the subsequent patches. This change is a part of a larger effort to enable scalable vectorisation in Linalg. See this RFC for more context: * https://discourse.llvm.org/t/rfc-scalable-vectorisation-in-linalg/ Differential Revision: https://reviews.llvm.org/D153372 | 3 年前 | |
[mlir] Allow negative strides and offset in StridedLayoutAttr Negative strides are useful for creating reverse-view of array. We don't have specific example for negative offset yet but will add it for consistency. Differential Revision: https://reviews.llvm.org/D134147 | 3 年前 |