Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
The tests are affected only because the materialization of extract_slice/subview was postponed.
Can you provide some rationale for this change in the description? I assume this enables reuse of the functionality independent of extract_slice and friends but making this clear in the description would be nice.
This seems NFC and enabling more reuse is a good thing, so LGTM.
Echo-ing that there seems to be a missing rationale here (or at least the rationale here seems to be driven by out-of-tree uses). This is increasing the API surface area of Tiling transformation, when in reality we need to be going the other way, reducing the API surface area.
What this does is reducing coupling between tiling linalg operations and the specific way the tiling is expressed in IR. It is true that this enables out-of-tree uses but MLIR is an infrastructure, so enabling out of tree uses should be a goal. There is no inherent reason why tiling a linalg operation should depend on using tensor operations.
You are right that this needs a bigger discussion and finding the right interface for tiling that is more dialect independent and captures only the essence of tiling (which I believe is the tiled operation and a description of the input/output tiles) would be desirable. However, while we find such solution, it makes sense to me to extend the linalg API to enable more uses. This is a very local API change within linalg after all.
What this does is reducing coupling between tiling linalg operations and the specific way the tiling is expressed in IR. It is true that this enables out-of-tree uses but MLIR is an infrastructure, so enabling out of tree uses should be a goal. There is no inherent reason why tiling a linalg operation should depend on using tensor operations.
I think a usage/API that is driven by a particular use of MLIR out-of-tree would become hard to maintain. I am looking for a more flushed out description of how any out-of-tree user is expected to use it (and thereby concretize the usage that is driving these changes).
Agree with what you are saying that tiling should not depend on using tensor operations. In the TilingInterface there is a method to get the offsets and sizes for result tiles. Maybe you want to add a new method there for getting the offsets and sizes for the operands.... That would make sense to me in terms of decoupling the tiling implementation from using tensor.extract_slice operations. Still though would need some justification as to why tensor.extract_slice does not serve the purpose, cause anyway all of this is still in rectangular domains.
It is essentially a first step to even enable the below tiling interface. If we were to change the interface, we would need to extract the functionality this patch makes available.
Agree with what you are saying that tiling should not depend on using tensor operations. In the TilingInterface there is a method to get the offsets and sizes for result tiles. Maybe you want to add a new method there for getting the offsets and sizes for the operands.... That would make sense to me in terms of decoupling the tiling implementation from using tensor.extract_slice operations. Still though would need some justification as to why tensor.extract_slice does not serve the purpose, cause anyway all of this is still in rectangular domains.
So we seem to agree that we need to expose this functionality. As I said, I am happy to start the discussion on the TilingInterface but adding a method to an interface seems the much bigger change and requires more careful API design than adding a utility function to linalg utils. In particular, I would be opposed to further complicate the interface by a method and much rather would split the creation of the tiled operation and the production of the slice operations into different interfaces/utilities.
Can we land this as a first minor step, gain some experience and then propose what a split interface would look like?
I don't think it is good practice to land a change when there are still outstanding changes requested. IMO that is not following community contribution guidelines. Please revert
@mravishankar What comments do you mean exactly?
Echo-ing that there seems to be a missing rationale here (or at least the rationale here seems to be driven by out-of-tree uses).
I added the description to the commit https://github.com/llvm/llvm-project/commit/56d94b3b902e21ff79b1ce9a6fb606a3f7c1c4db
This is increasing the API surface area of Tiling transformation, when in reality we need to be going the other way, reducing the API surface area.
This one has nothing to do with this PR. This PR just restructured two methods in Utils.h. I am not changing the TilingInterface here nor I intend to write an RFC for every small change.
This one has nothing to do with this PR. This PR just restructured two methods in Utils.h. I am not changing the TilingInterface here nor I intend to write an RFC for every small change.
That is just one of the comments. The main comment is that this is exposing API that is not fully justified, and unclear use case. Having custom API exposed for each use case is going to be hard to maintain. It might be just a couple of methods, but if everyone who is using Linalg keeps exposing entry points to customize for their use case, then it is a death by a thousand cuts. There are other questions in the comments that werent responded to before it was submitted. Would also be good to be sensitive to time zones. Having requested changes, I would expect been given enough time to review the udpates before it lands.
I dont see any changes in this patch that addresses the comments above. At the very least, I would wait for presumptive code owner @nicolasvasilache to break the tie (and I'll go with what he decides ultimately)
Mashesh marked this revision as needed changes, expressing clearly a disagreement with where this is going. I don't understand why this was ignored and landed.
More importantly, the follow up asked for a revert: please do promptly.
Thanks Mehdi and Thanks Alex for the revert.
In terms of path forward, there is not much technical discussion to be had AFAICS, but rather a more about API surface area of Linalg based transformations. I'll go with whatever Nicolas suggests. If he is on-board with it, then I apologize for the inconvenience caused here.
Reading Mahesh's comments I worried that we may indeed increase the surface API of things that are scheduled to be deleted but I do not think this is the case.
I think this is a step in the direction we want to go to collectively to support other extract/insert/parallel_insert than the existing ones; gather comes to mind (teaser: https://reviews.llvm.org/D130348).
This is still super early and the APIs surface will need to change further, but this incremental step does not pose concerns to me as it stands.
mlir/include/mlir/Dialect/Linalg/Utils/Utils.h | ||
---|---|---|
227 | Can we improve the doc here? I would move some of the description from computeAllSliceParameters here and refer to it in the next function. | |
247 | The doc for this function could say: Computes SliceParamaters for all `valuesToTile` ... Calls computeSliceParameters. Some of the `valuesToTile` won't be affected by tiling. For these values, llvm::None will be returned. | |
mlir/lib/Dialect/Linalg/Utils/Utils.cpp | ||
847–848 | outdated comment. |
mlir/lib/Dialect/Linalg/Utils/Utils.cpp | ||
---|---|---|
805 | Not for this PR obviously but this could become the basis for some SubsetOpInterface/SubsetExtractOpInterface. This still requires discussion, I hope to send an RFC by EoW. |
Looks like this broke the windows mlir buildbot: https://lab.llvm.org/buildbot/#/builders/13/builds/24387/steps/6/logs/stdio
Can we improve the doc here?
I would move some of the description from computeAllSliceParameters here and refer to it in the next function.