This is an archive of the discontinued LLVM Phabricator instance.

[MLIR][Linalg] Allow fusion of more than 2 linalg ops.
ClosedPublic

Authored by pifon2a on Jan 22 2020, 2:28 AM.

Details

Reviewers
nicolasvasilache
Summary
LinalgDependenceGraph was not updated after successful producer-consumer
fusion for linalg ops. In this patch it is fixed by reconstructing
LinalgDependenceGraph on every iteration. This is very ineffective and
should be improved by updating LDGraph only when it is necessary.

Diff Detail

Event Timeline

pifon2a created this revision.Jan 22 2020, 2:28 AM

@nicolasvasilache This is not the best way of doing this update, I just wanted you to check if the idea is correct.

Unit tests: pass. 62094 tests passed, 0 failed and 785 were skipped.

clang-tidy: unknown.

clang-format: pass.

Build artifacts: diff.json, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

rriddle added inline comments.Jan 22 2020, 8:45 AM
mlir/lib/Dialect/Linalg/Transforms/Fusion.cpp
346

llvm::find(linalgOps, originalOp)?

please make the commit message significantly more descriptive: what was the problem, how did you fix it etc

mlir/lib/Dialect/Linalg/Transforms/Fusion.cpp
346

does @rriddle's solution work?

nicolasvasilache requested changes to this revision.Jan 24 2020, 11:50 AM

Please split out the NFC changes in a separate diff.

mlir/lib/Dialect/Linalg/Transforms/Fusion.cpp
341

Well that is a really dirty "fix" :)
It's true however that it is a problem with the current LinalgDependenceGraph impl that does not know how to update itself.
Still that problem already existed because the graph is recreated at each pattern invocation.

Let's let this fly for now but please adda big TODO that the graph needs to support mutation.

mlir/test/Dialect/Linalg/fusion.mlir
27

please avoid mixing in NFC formatting changes in the flow and send a separate CL for that.
I cannot tell what changed without spending too much time on it.

This revision now requires changes to proceed.Jan 24 2020, 11:50 AM
pifon2a updated this revision to Diff 241643.Jan 31 2020, 12:23 AM
pifon2a marked 4 inline comments as done.

Addressed the comments.

pifon2a edited the summary of this revision. (Show Details)Jan 31 2020, 12:24 AM

Unit tests: fail. 62343 tests passed, 1 failed and 839 were skipped.

failed: libc++.std/containers/sequences/array/array_creation/to_array.fail.cpp

clang-tidy: pass.

clang-format: pass.

Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

Pre-merge checks is in beta. Report issue. Please join beta or enable it for your project.

nicolasvasilache accepted this revision.Jan 31 2020, 5:52 AM

Approved conditioned on beefing up the test and having no reordering surprises.

mlir/test/Dialect/Linalg/fusion.mlir
266

Sorry for being annoying but there is a risk of bad ordering here and I cannot tell whether this is correct.
Could we extend the test to capture the subviews into A, B, C, D

In the end we can only have:

linalg.matmul(%A, %B, %C) 
linalg.matmul(%C, %B, %D)
linalg.matmul(%5, %7, %8)

i.e. we need to make sure that there is no bypass.
It should be fine but I'd prefer to check this new behavior.

Thanks!

This revision is now accepted and ready to land.Jan 31 2020, 5:52 AM

Thanks for catching this!

pifon2a updated this revision to Diff 242025.Feb 3 2020, 4:55 AM

Capture the indices.

@nicolasvasilache No problem, I captured the indices. But please, check if the fusion is correct.

Unit tests: pass. 62414 tests passed, 0 failed and 839 were skipped.

clang-tidy: pass.

clang-format: pass.

Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml

Pre-merge checks is in beta. Report issue. Please join beta or enable it for your project.

nicolasvasilache accepted this revision.Feb 3 2020, 6:23 AM

The syntactic order of statements is good.
The fusion rules are too lenient and we end up recomputing things too many times.
This is a know current issue that I need to fix, filing a bug for it.

The TL;DR is do not count on fusion with reductions to compute the correct value atm.

And thanks for improving the test!