- Dec 02, 2020
-
-
Christian Sigg authored
Given that OpState already implicit converts to Operator*, this seems reasonable. The alternative would be to add more functions to OpState which forward to Operation. Reviewed By: rriddle, ftynse Differential Revision: https://reviews.llvm.org/D92266
-
- Nov 26, 2020
-
-
Aart Bik authored
This change gives sparse compiler clients more control over selecting individual types for the pointers and indices in the sparse storage schemes. Narrower width obviously results in smaller memory footprints, but the range should always suffice for the maximum number of entries or index value. Reviewed By: penpornk Differential Revision: https://reviews.llvm.org/D92126
-
Sean Silva authored
It still had the old name from before ElementwiseMappable was added.
-
- Nov 25, 2020
-
-
Aart Bik authored
This CL adds the ability to request different parallelization strategies for the generate code. Every "parallel" loop is a candidate, and converted to a parallel op if it is an actual for-loop (not a while) and the strategy allows dense/sparse outer/inner parallelization. This will connect directly with the work of @ezhulenev on parallel loops. Still TBD: vectorization strategy Reviewed By: penpornk Differential Revision: https://reviews.llvm.org/D91978
-
- Nov 24, 2020
-
-
Aart Bik authored
Generalizes invariant handling to anything defined outside the Linalg op (parameters and SSA computations). Fixes bug that was using parameter number as tensor number. Reviewed By: penpornk Differential Revision: https://reviews.llvm.org/D91985
-
Nicolas Vasilache authored
Print part of an op of the form: ``` <optional-offset-prefix>`[` offset-list `]` <optional-size-prefix>`[` size-list `]` <optional-stride-prefix>[` stride-list `]` ``` Also address some leftover nits. Differential revision: https://reviews.llvm.org/D92031
-
Alexander Belyaev authored
Differential Revision: https://reviews.llvm.org/D92014
-
- Nov 23, 2020
-
-
MaheshRavishankar authored
Exposing some utility functions from Linalg to allow for promotion of fused views outside of the core tile+fuse logic. This is an alternative to patch D91322 which adds the promotion logic to the tileAndFuse method. Downside with that approach is that it is not easily customizable based on needs. Differential Revision: https://reviews.llvm.org/D91503
-
MaheshRavishankar authored
Enhance the tile+fuse logic to allow fusing a sequence of operations. Make sure the value used to obtain tile shape is a SubViewOp/SubTensorOp. Current logic used to get the bounds of loop depends on the use of `getOrCreateRange` method on `SubViewOp` and `SubTensorOp`. Make sure that the value/dim used to compute the range is from such ops. This fix is a reasonable WAR, but a btter fix would be to make `getOrCreateRange` method be a method of `ViewInterface`. Differential Revision: https://reviews.llvm.org/D90991
-
Nicolas Vasilache authored
Differential Revision: https://reviews.llvm.org/D91956
-
Nicolas Vasilache authored
This revision refactors code used in various Linalg transformations and makes it a first class citizen to the LinalgStructureOpInterface. This is in preparation to allowing more advanced Linalg behavior but is otherwise NFC. Differential revision: https://reviews.llvm.org/D91863
-
- Nov 21, 2020
-
-
Aart Bik authored
Adds tests for full sum reduction (tensors summed up into scalars) and the well-known sampled-dense-dense-matrix-product. Refines the optimizations rules slightly to handle the summation better. Reviewed By: penpornk Differential Revision: https://reviews.llvm.org/D91818
-
- Nov 20, 2020
-
-
Thomas Raoux authored
Add transformation to be able to forward transfer_write into transfer_read operation and to be able to remove dead transfer_write when a transfer_write is overwritten before being read. Differential Revision: https://reviews.llvm.org/D91321
-
Mikhail Goncharov authored
This reverts commit f8284d21. Revert "[mlir][Linalg] NFC: Expose some utility functions used for promotion." This reverts commit 0c59f515. Revert "Remove unused isZero function" This reverts commit 0f9f0a40. Change f8284d21 led to multiple failures in IREE compilation.
-
Geoffrey Martin-Noble authored
Unused since https://reviews.llvm.org/D91503 and triggering -Wunused-function Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D91838
-
MaheshRavishankar authored
Exposing some utility functions from Linalg to allow for promotion of fused views outside of the core tile+fuse logic. This is an alternative to patch D91322 which adds the promotion logic to the tileAndFuse method. Downside with that approach is that it is not easily customizable based on needs. Differential Revision: https://reviews.llvm.org/D91503
-
MaheshRavishankar authored
Enhance the tile+fuse logic to allow fusing a sequence of operations. Differential Revision: https://reviews.llvm.org/D90991
-
- Nov 19, 2020
-
-
River Riddle authored
* Move ops to a BuiltinOps.h * Add file comments
-
Lei Zhang authored
This commit starts a new pass and patterns for converting Linalg named ops to generic ops. This enables us to leverage the flexbility from generic ops during transformations. Right now only linalg.conv is supported; others will be added when useful. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D91357
-
Aart Bik authored
Rationale: Make sure preconditions are tested already during verfication. Currently, the only way a sparse rewriting rule can fail is if (1) the linalg op does not have sparse annotations, or (2) a yet to be handled operation is encounted inside the op Reviewed By: penpornk Differential Revision: https://reviews.llvm.org/D91748
-
- Nov 17, 2020
-
-
Aart Bik authored
As discussed in https://llvm.discourse.group/t/mlir-support-for-sparse-tensors/2020 this CL is the start of sparse tensor compiler support in MLIR. Starting with a "dense" kernel expressed in the Linalg dialect together with per-dimension sparsity annotations on the tensors, the compiler automatically lowers the kernel to sparse code using the methods described in Fredrik Kjolstad's thesis. Many details are still TBD. For example, the sparse "bufferization" is purely done locally since we don't have a global solution for propagating sparsity yet. Furthermore, code to input and output the sparse tensors is missing. Nevertheless, with some hand modifications, the generated MLIR can be easily converted into runnable code already. Reviewed By: nicolasvasilache, ftynse Differential Revision: https://reviews.llvm.org/D90994
-
River Riddle authored
These includes have been deprecated in favor of BuiltinDialect.h, which contains the definitions of ModuleOp and FuncOp. Differential Revision: https://reviews.llvm.org/D91572
-
- Nov 14, 2020
-
-
Aart Bik authored
motivated by a refactoring in the new sparse code (yet to be merged), this avoids some lengthy code dup Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D91465
-
Sean Silva authored
That way, it runs in parallel across functions.
-
- Nov 13, 2020
-
-
River Riddle authored
[mlir][Interfaces] Add implicit casts from concrete operation types to the interfaces they implement. This removes the need to have an explicit `cast<>` given that we always know it `isa` instance of the interface. Differential Revision: https://reviews.llvm.org/D91304
-
- Nov 12, 2020
-
-
Sean Silva authored
We lower them to a std.global_memref (uniqued by constant value) + a std.get_global_memref to produce the corresponding memref value. This allows removing Linalg's somewhat hacky lowering of tensor constants, now that std properly supports this. Differential Revision: https://reviews.llvm.org/D91306
-
Sean Silva authored
It was incorrect in the presence of a tensor argument with multiple uses. The bufferization of subtensor_insert was writing into a converted memref operand, but there is no guarantee that the converted memref for that operand is safe to write into. In this case, the same converted memref is written to in-place by the subtensor_insert bufferization, violating the tensor-level semantics. I left some comments in a TODO about ways forward on this. I will be working actively on this problem in the coming days. Differential Revision: https://reviews.llvm.org/D91371
-
MaheshRavishankar authored
This change does two main things 1) An operation might have multiple dependences to the same producer. Not tracking them correctly can result in incorrect code generation with fusion. To rectify this the dependence tracking needs to also have the operand number in the consumer. 2) Improve the logic used to find the fused loops making it easier to follow. The only constraint for fusion is that linalg ops (on buffers) have update semantics for the result. Fusion should be such that only one iteration of the fused loop (which is also a tiled loop) must touch only one (disjoint) tile of the output. This could be relaxed by allowing for recomputation that is the default when oeprands are tensors, or can be made legal with promotion of the fused view (in future). Differential Revision: https://reviews.llvm.org/D90579
-
Aart Bik authored
This CL integrates the new sparse annotations (hereto merely added as fully transparent attributes) more tightly to the generic linalg op in order to add verification of the annotations' consistency as well as to make make other passes more aware of their presence (in the long run, rewriting rules must preserve the integrity of the annotations). Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D91224
-
- Nov 10, 2020
-
-
Sean Silva authored
This patch converts elementwise ops on tensors to linalg.generic ops with the same elementwise op in the payload (except rewritten to operate on scalars, obviously). This is a great form for later fusion to clean up. E.g. ``` // Compute: %arg0 + %arg1 - %arg2 func @f(%arg0: tensor<?xf32>, %arg1: tensor<?xf32>, %arg2: tensor<?xf32>) -> tensor<?xf32> { %0 = addf %arg0, %arg1 : tensor<?xf32> %1 = subf %0, %arg2 : tensor<?xf32> return %1 : tensor<?xf32> } ``` Running this through `mlir-opt -convert-std-to-linalg -linalg-fusion-for-tensor-ops` we get: ``` func @f(%arg0: tensor<?xf32>, %arg1: tensor<?xf32>, %arg2: tensor<?xf32>) -> tensor<?xf32> { %0 = linalg.generic {indexing_maps = [#map0, #map0, #map0, #map0], iterator_types = ["parallel"]} ins(%arg0, %arg1, %arg2 : tensor<?xf32>, tensor<?xf32>, tensor<?xf32>) { ^bb0(%arg3: f32, %arg4: f32, %arg5: f32): // no predecessors %1 = addf %arg3, %arg4 : f32 %2 = subf %1, %arg5 : f32 linalg.yield %2 : f32 } -> tensor<?xf32> return %0 : tensor<?xf32> } ``` So the elementwise ops on tensors have nicely collapsed into a single linalg.generic, which is the form we want for further transformations. Differential Revision: https://reviews.llvm.org/D90354
-
- Nov 09, 2020
-
-
Nicolas Vasilache authored
This revision adds support for bufferization by using a mix of `tensor_load`, `subview`, `linalg.copy` and `tensor_to_memref`.
-
- Nov 04, 2020
-
-
Sean Silva authored
Previously, linalg-bufferize was a "finalizing" bufferization pass (it did a "full" conversion). This wasn't great because it couldn't be used composably with other bufferization passes like std-bufferize and scf-bufferize. This patch makes linalg-bufferize a composable bufferization pass. Notice that the integration tests are switched over to using a pipeline of std-bufferize, linalg-bufferize, and (to finalize the conversion) func-bufferize. It all "just works" together. While doing this transition, I ran into a nasty bug in the 1-use special case logic for forwarding init tensors. That logic, while well-intentioned, was fundamentally flawed, because it assumed that if the original tensor value had one use, then the converted memref could be mutated in place. That assumption is wrong in many cases. For example: ``` %0 = some_tensor : tensor<4xf32> br ^bb0(%0, %0: tensor<4xf32>, tensor<4xf32>) ^bb0(%bbarg0: tensor<4xf32>, %bbarg1: tensor<4xf32>) // %bbarg0 is an alias of %bbarg1. We cannot safely write // to it without analyzing uses of %bbarg1. linalg.generic ... init(%bbarg0) {...} ``` A similar example can happen in many scenarios with function arguments. Even more sinister, if the converted memref is produced by a `std.get_global_memref` of a constant global memref, then we might attempt to write into read-only statically allocated storage! Not all memrefs are writable! Clearly, this 1-use check is not a local transformation that we can do on the fly in this pattern, so I removed it. The test is now drastically shorter and I basically rewrote the CHECK lines from scratch because: - the new composable linalg-bufferize just doesn't do as much, so there is less to test - a lot of the tests were related to the 1-use check, which is now gone, so there is less to test - the `-buffer-hoisting -buffer-deallocation` is no longer mixed in, so the checks related to that had to be rewritten Differential Revision: https://reviews.llvm.org/D90657
-
mikeurbach authored
Previously, they were only defined for `FuncOp`. To support this, `FunctionLike` needs a way to get an updated type from the concrete operation. This adds a new hook for that purpose, called `getTypeWithoutArgsAndResults`. For now, `FunctionLike` continues to assume the type is `FunctionType`, and concrete operations that use another type can hide the `getType`, `setType`, and `getTypeWithoutArgsAndResults` methods. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D90363
-
- Nov 03, 2020
-
-
Thomas Raoux authored
Differential Revision: https://reviews.llvm.org/D90474
-
- Oct 30, 2020
-
-
Sean Silva authored
The bufferization patterns are moved to the .cpp file, which is preferred in the codebase when it makes sense. The LinalgToStandard patterns are kept a header because they are expected to be used individually. However, they are moved to LinalgToStandard.h which is the file corresponding to where they are defined. This also removes TensorCastOpConverter, which is handled by populateStdBufferizePatterns now. Eventually, the constant op lowering will be handled as well, but it there are currently holdups on moving it (see https://reviews.llvm.org/D89916). Differential Revision: https://reviews.llvm.org/D90254
-
- Oct 29, 2020
-
-
Nicolas Vasilache authored
Linalg "tile-and-fuse" is currently exposed as a Linalg pass "-linalg-fusion" but only the mechanics of the transformation are currently relevant. Instead turn it into a "-test-linalg-greedy-fusion" pass which performs canonicalizations to enable more fusions to compose. This allows dropping the OperationFolder which is not meant to be used with the pattern rewrite infrastructure. Differential Revision: https://reviews.llvm.org/D90394
-
- Oct 28, 2020
-
-
Kazuaki Ishizaki authored
fix typos in comments and documents Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D90089
-
MaheshRavishankar authored
This patch adds support for fusing linalg.indexed_generic op with linalg.tensor_reshape op by expansion, i.e. - linalg.indexed_generic op -> linalg.tensor_reshape op when the latter is expanding. - linalg.tensor_reshape op -> linalg.indexed_generic op when the former is folding. Differential Revision: https://reviews.llvm.org/D90082
-
- Oct 27, 2020
-
-
River Riddle authored
This class represents a rewrite pattern list that has been frozen, and thus immutable. This replaces the uses of OwningRewritePatternList in pattern driver related API, such as dialect conversion. When PDL becomes more prevalent, this API will allow for optimizing a set of patterns once without the need to do this per run of a pass. Differential Revision: https://reviews.llvm.org/D89104
-
River Riddle authored
There are several pieces of pattern rewriting infra in IR/ that really shouldn't be there. This revision moves those pieces to a better location such that they are easier to evolve in the future(e.g. with PDL). More concretely this revision does the following: * Create a Transforms/GreedyPatternRewriteDriver.h and move the apply*andFold methods there. The definitions for these methods are already in Transforms/ so it doesn't make sense for the declarations to be in IR. * Create a new lib/Rewrite library and move PatternApplicator there. This new library will be focused on applying rewrites, and will also include compiling rewrites with PDL. Differential Revision: https://reviews.llvm.org/D89103
-