With the recent changes to linalg on tensor semantics, the tiling
operations works out-of-the-box for generic operations. Add a test to
verify that and some minor refactoring.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
110 ms | x64 windows > LLVM.CodeGen/XCore::threads.ll |
Event Timeline
It's nice that we actually don't need to change op semantics to support "init_tensor form" and that all semantics can be dealt with just in tiling.
However we need a better abstraction and documentation to avoid leaking the op + init or result tensor implementation detail into the tiling implementation.
A simple
struct { LinalgOp op; Value result; // only if op has no init_tensor };
with a proper API and assertions should be enough to separate these concerns.
The harder part will prob. be finding good names for this :)
mlir/include/mlir/Dialect/Linalg/IR/LinalgOps.td | ||
---|---|---|
47 | initialization | |
48 | Now that I see you don't need to specify dims because the op must fold away before bufferization, | |
mlir/lib/Dialect/Linalg/IR/LinalgOps.cpp | ||
68 | This seems fishy to me because it changes the semantics of all ops. Shouldn't we instead drop the extra dimensions from the getShapesToLoopsMap as discussed in https://reviews.llvm.org/D93076 ? | |
mlir/lib/Dialect/Linalg/Transforms/Tiling.cpp | ||
382 | Please isolate in a helper function and document it: | |
428 | This doc assumed we would evolve the op semantics to allow all ops to convert to an "init_tensor form". | |
436 | this would benefit from a helper function + documentation that mentions the 2 cases:
| |
447 | This is now harder to follow and we will trip over in the future. I suggest a helper struct that captures the op and potentially the result tensor. |
mlir/include/mlir/Dialect/Linalg/IR/LinalgOps.td | ||
---|---|---|
48 | There are still issues with this op definition I am not entirely clear about. I sent this out for review to start conversion about this. Here are issues that i think need to be solved
My preference right now is to
| |
mlir/lib/Dialect/Linalg/IR/LinalgOps.cpp | ||
68 | Agreed. WIll send out a different patch for that. |
mlir/lib/Dialect/Linalg/IR/LinalgOps.cpp | ||
---|---|---|
68 | Moved the code to https://reviews.llvm.org/D93180 . | |
mlir/lib/Dialect/Linalg/Transforms/Tiling.cpp | ||
382 | Good Idea. Made a helper struct TiledOp that encompasses all the logic. It does make things cleaner. |
mlir/lib/Dialect/Linalg/IR/LinalgOps.cpp | ||
---|---|---|
1731–1735 | nit: drop braces. E.g., // This should also omit braces. The `for` loop contains only a single statement, // so it shouldn't have braces. The `if` also only contains a single simple // statement (the for loop), so it also should omit braces. if (isa<FunctionDecl>(D)) for (auto *A : D.attrs()) | |
mlir/lib/Dialect/Linalg/Transforms/Tiling.cpp | ||
318 | s/a/an | |
321 | s/a/an | |
324–346 | I would add braces between methods and vars because it helps readability. E.g., struct TiledOp { TiledOp(OpBuilder &b, LinalgOp op) : op(op) { ... } SmallVector<Value, 4> getTiledOperands() { ... } LinalgOp op; SmallVector<Value, 1> initTensors; }; | |
mlir/test/Dialect/Linalg/roundtrip.mlir | ||
722–727 | We typically put this to invalid.mlir, lets move to there and remove adding -verify-diagnostics to this file. | |
mlir/test/Dialect/Linalg/tile-tensors.mlir | ||
46 | remove the blank line? |
Updating this to use init_tensor operation, but this doesnt work. It
creates a use-after-def issue. This should be resolved when
https://llvm.discourse.group/t/linalg-and-shapes/2421 is addressed.
mlir/lib/Dialect/Linalg/Transforms/Tiling.cpp | ||
---|---|---|
613 | Since you also add IndexedGenericOp, could we add a test for it? |
initialization