Failure in EliminateEmptyTensors pass fails #11273
Comments
|
The error message is confusing, here is a cleanup to make it more descriptive: https://reviews.llvm.org/D138902 This a limitation that we currently have in One-Shot Bufferize: When you yield a new buffer allocation (both Can we write a pass to move the I.e., after moving the %generated = tensor.generate {
^bb0(%arg1: index):
tensor.yield %c0_i32 : i32
} : tensor<1xi32>
flow.dispatch.tensor.store %generated, %1, offsets = [%arg0], sizes = [1], strides = [1] : tensor<1xi32> -> !flow.dispatch.tensor<writeonly:tensor<7xi32>>At this point, we still have an alloc inside of the Then the follow-up rewrite. This is essentially what %loaded = flow.dispatch.tensor.load %1, offsets = [%arg0], sizes = [1], strides = [1] : tensor<1xi32> -> !flow.dispatch.tensor<writeonly:tensor<7xi32>>
%generated = linalg.generic outs(%loaded : tensor<1xi32>) {
^bb0(%out: f32):
%arg1 = linalg.index()
tensor.yield %c0_i32 : i32
}
flow.dispatch.tensor.store %generated, %1, offsets = [%arg0], sizes = [1], strides = [1] : tensor<1xi32> -> !flow.dispatch.tensor<writeonly:tensor<7xi32>>Now the alloc is completely gone. We basically turned the We have to do the same for the "else" branch. Note: You are currently this error message during |
|
Actually I just realized that I am not using pad vectorization, so Ill circle back to this if it is still an issue then. Sorry for the noise. |
|
@matthias-springer thanks for the response earlier. I finally got around to parsing what you had. Couple of things
I would expect that
|
|
That could work. There's three things that we have to do: Step 1: Decompose Step 2: Minor update to Now we bufferize. Step 3: Add an Now the RE |
|
@matthias-springer any updates on this. If this is going to take longer, I can add an IREE specific WAR for now |
|
I'm working on this but there's one detail that I overlooked. We need to extend BufferizableOpInterface for keeping track of equivalent OpOperands properly. This is a pretty big change. I think I should be able to finish this by the end of this week. If you have free cycles, we also still need lowering patterns for |
How about changing the lowering itself to not use |
|
I finished the implementation for Step 2: https://reviews.llvm.org/D142130. It turned out to be a larger change and the entire stack is needed. Working on Step 1 now. |
Which lowering are you referring to? Do you mean not producing the |
The |
This is a WIP PR that shows first attempt for data tiling for GPUs. It implementes materialization for the encoding. Note that, PR cannot compile any program. Because it generates `tensor.pad` and we don't know how to tile it yet. iree-org#10184 can be enabled to tile `tensor.pad`, but then it results bufferization problem iree-org#11273
|
Step 1 is also done: stack of https://reviews.llvm.org/D142207. Now it should bufferize but there is still a self-copy. E.g., Unfortunately, the I could write a hoisting transformation that looks for identical ops in an |
Are you waiting for me to review? Maybe someone with more context can. I can take a look if you want me to.
Easier might be to just write a hoisting of ops from either the if or the else branch. Then CSE should be able to take care of the rest and get you to the form you want. |
Is that safe in general? The |
|
subview is supposed to be just pointer arithmetic. So it should be hoistable.... I think you can label it speculatable.... I think you can always compute an out-of-bounds pointer. If you use it is when the error is.... So I would say marking it speculatable and hoisting it should be fine. |
|
Step 3: https://reviews.llvm.org/D142480. This is a general CSE for |
|
@matthias-springer while you land upstream, are there patches I can import locally to fix this issue, so that I can look into other issues that might be happening. |
|
If you patch in this stack of changes (https://reviews.llvm.org/D142130), it should work. Optionally also this change (https://reviews.llvm.org/D142480) to CSE the |
|
@matthias-springer thanks for all the great work. I patched all your changes (I pushed them to https://github.com/iree-org/iree/tree/pad_fusion , you should be able to check those out and build it locally). I still see errors in bufferization After running the To help repro you can also start with and run |
|
The tensor.generate is still there, can you run these patterns before bufferization (in particular before EmptyTensorElimination): test-linalg-transform-patterns=test-convert-to-destination-style-patterns |
|
Do we have to do this with transform dialect? Is there a populateMethod I can use? |
|
Found it. Still a failure in This is the error |
It seems like handling the code generated by the tiling of pad operations needs more work in bufferization. To unblock the work of handling pad operations natively in IREE, iree-org#11273 (comment) is implemented here as a workaround. To ensure bufferization without allocation, yields of the then and else branch and the result of the `scf.if` are all tied together. If the `then` and `else` come from different bindings, then this would be illegal (because a copy is needed). This example led to adding more constraints on what sets can be merged during the `BufferizationAnalysis` to avoid merging sets that have constants or have two different `interface_bindings`.
It seems like handling the code generated by the tiling of pad operations needs more work in bufferization. To unblock the work of handling pad operations natively in IREE, #11273 (comment) is implemented here as a workaround. To ensure bufferization without allocation, yields of the then and else branch and the result of the scf.if are all tied together. If the then and else come from different bindings, then this would be illegal (because a copy is needed). This example led to adding more constraints on what sets can be merged during the BufferizationAnalysis to avoid merging sets that have constants or have two different interface_bindings. benchmarks: x86_64, cuda
It seems like handling the code generated by the tiling of pad operations needs more work in bufferization. To unblock the work of handling pad operations natively in IREE, iree-org#11273 (comment) is implemented here as a workaround. To ensure bufferization without allocation, yields of the then and else branch and the result of the scf.if are all tied together. If the then and else come from different bindings, then this would be illegal (because a copy is needed). This example led to adding more constraints on what sets can be merged during the BufferizationAnalysis to avoid merging sets that have constants or have two different interface_bindings. benchmarks: x86_64, cuda
|
Moved to P2 for now. |
It seems like handling the code generated by the tiling of pad operations needs more work in bufferization. To unblock the work of handling pad operations natively in IREE, #11273 (comment) is implemented here as a workaround. To ensure bufferization without allocation, yields of the then and else branch and the result of the scf.if are all tied together. If the then and else come from different bindings, then this would be illegal (because a copy is needed). This example led to adding more constraints on what sets can be merged during the BufferizationAnalysis to avoid merging sets that have constants or have two different interface_bindings. benchmarks: x86_64, cuda
It seems like handling the code generated by the tiling of pad operations needs more work in bufferization. To unblock the work of handling pad operations natively in IREE, iree-org#11273 (comment) is implemented here as a workaround. To ensure bufferization without allocation, yields of the then and else branch and the result of the scf.if are all tied together. If the then and else come from different bindings, then this would be illegal (because a copy is needed). This example led to adding more constraints on what sets can be merged during the BufferizationAnalysis to avoid merging sets that have constants or have two different interface_bindings. benchmarks: x86_64, cuda
It seems like handling the code generated by the tiling of pad operations needs more work in bufferization. To unblock the work of handling pad operations natively in IREE, iree-org#11273 (comment) is implemented here as a workaround. To ensure bufferization without allocation, yields of the then and else branch and the result of the scf.if are all tied together. If the then and else come from different bindings, then this would be illegal (because a copy is needed). This example led to adding more constraints on what sets can be merged during the BufferizationAnalysis to avoid merging sets that have constants or have two different interface_bindings. benchmarks: x86_64, cuda
With this input
fails with the following error
The text was updated successfully, but these errors were encountered: