Allow creation of TCP groups where an op has multiple uses #74
Conversation
test/Dialect/tcp_fusion.mlir
Outdated
| // CHECK: %[[V4:.+]] = tcp.sub %[[V2]], %[[ARG1]] : tensor<?x?xf32>, tensor<?x?xf32> -> tensor<?x?xf32> | ||
| // CHECK: tcp.yield %[[V3]], %[[V4]] : tensor<?x?xf32>, tensor<?x?xf32> | ||
| // CHECK: } : tensor<?x?xf32>, tensor<?x?xf32> | ||
| // CHECK: return %[[V0]]#1, %[[V0]]#0 : tensor<?x?xf32>, tensor<?x?xf32> |
There was a problem hiding this comment.
Any idea why the order is swapped here?
Should it be return %[[V0]]#0, %[[V0]]#1 : tensor<?x?xf32>, tensor<?x?xf32> instead?
There was a problem hiding this comment.
Thanks for the close eyes! This actually uncovered a bug in the algorithm... I fixed it and added a more robust test which was what the intent of the second test was all along.
| // CHECK: } : tensor<?x?xf32> | ||
| // CHECK: return %[[V0]] : tensor<?x?xf32> | ||
| // CHECK: } | ||
| func.func @test_multi_use_fusion(%arg0 : tensor<?x?xf32>, %arg1 : tensor<?x?xf32>) -> tensor<?x?xf32> { |
There was a problem hiding this comment.
nit: call this something different from below (is this single use fusion?)
There was a problem hiding this comment.
I added some comments explaining what the test intent is. These are both for testing fusion with multiple uses. The difference is in whether the multiple uses are already part of a tcp group or whether we are creating a new group from the multiple uses for the first time.
…tomation#74) We previously only allowed an op to have a single use during the creation a group for it. This PR relaxes that to allow multiple uses as long as all the uses belong to the same region. --------- Co-authored-by: Srinath Avadhanula <srinath.avadhanula@getcruise.com>
We previously only allowed an op to have a single use during the creation a group for it. This PR relaxes that to allow multiple uses as long as all the uses belong to the same region.