This patch extends the control-flow cost-model for detensoring by
implementing a forward-looking pass on block arguments that should be
detensored. This makes sure that if a (to-be-detensored) block argument
"escapes" its block through the terminator, then the successor arguments
are also detensored.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Dialect/Linalg/Transforms/Detensorize.cpp | ||
---|---|---|
495 | For now, I ignored this part since it might complicate the algorithm by quite a bit. I prefer to integrate detensoring in IREE after patch first and derive further changes to the cost-model on a need-by-need basis. WDYT? |
mlir/lib/Dialect/Linalg/Transforms/Detensorize.cpp | ||
---|---|---|
474 | You should be able to fold this into the worklist traversal above. |
mlir/lib/Dialect/Linalg/Transforms/Detensorize.cpp | ||
---|---|---|
474 | To elaborate on that, think of this as finding connected components on the undirected graph where Value's are nodes, and an *undirected edge* exists between Value's (v1, v2) when:
You only need one worklist traversal (which is a DFS) to discover this. The only thing that is slightly custom is that when you traverse enumerate the edges incident to a node, you need to check both situations 1. and 2. Note that the edge is undirected, but the IR data structures have a directedness (mathematically, the above definition is the same if we omit "or vice versa", but I kept it for clarity). |
mlir/lib/Dialect/Linalg/Transforms/Detensorize.cpp | ||
---|---|---|
495 | I would prioritize integrating this into IREE. If you structure the code as a DFS over the graph I described above, none of these additions should be much code or very complicated. |
mlir/lib/Dialect/Linalg/Transforms/Detensorize.cpp | ||
---|---|---|
474 | That's awesome. Thanks a lot! Folded the 2 phases into 1. |
could you elaborate a bit more on 2.1 and 2.2? I liked the level of detail you had for 1.1 and 1.2