You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[mlir][linalg] Fix to Elementwise Fusion when preserving results (llvm#149843)
In the linalg ElementwiseOpFusion transform, a pre-requisite for the
fusion between a producer and consumer op is that the producer's output
indexing map associated to the result to be fused must be invertible
(e.g. a simple permutation).
Before this patch, only the first output indexing map was being checked;
this bug produced issues when the operand to fuse was not the 1st result
of the producer op. For example, this situation arises when the producer
op has multiple results because it's the result of previous fusions
where the original result had been preserved: in these cases, the pass
ought to check the indexing map of the result being fused, which is not
necessarily the 1st one.
Signed-off-by: Fabrizio Indirli <[email protected]>
// In this test we expect the first two linalg.generic operations to be fused into one, but the third one (the matmul) to remain separate.
1021
+
// The reason is that when the pattern is applied the 1st time, the fusion of the first two operations produces a fused operation with
1022
+
// an additional result and ana dditional output indexing map that is not a permutation / not invertible.
1023
+
// The fused op will still produce also the original result (and its output indexing map), which is preserved because the new indexing map
1024
+
// is not invertible. Thus the fused op will have 2 results, but only the 2nd one will be used by the following matmul op as an input argument.
1025
+
// When trying to apply the fusion pattern again, the matmul op won't be fused because the operand to fuse was not produced with an invertible indexing map.
0 commit comments