This is an archive of the discontinued LLVM Phabricator instance.

[mlir][Linalg] Mostly NFC - Refactor Linalg patterns and transformations.
ClosedPublic

Authored by nicolasvasilache on May 1 2020, 3:34 PM.

Details

Summary

Linalg transformations are currently exposed as DRRs.
Unfortunately RewriterGen does not play well with the line of work on named linalg ops which require variadic operands and results.
Additionally, DRR is arguably not the right abstraction to expose compositions of such patterns that don't rely on SSA use-def semantics.

This revision abandons DRRs and exposes manually written C++ patterns.

Refactorings and cleanups are performed to uniformize APIs.
This refactoring will allow replacing the currently manually specified Linalg named ops.

A collateral victim of this refactoring is the tileAndFuse DRR, and the one associated test, which will be revived at a later time.

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald Transcript
rriddle added inline comments.May 1 2020, 3:47 PM
mlir/include/mlir/Dialect/Linalg/Transforms/Transforms.h
52

Please use the same header blocks as the rest of the infra.

88

Drop the extraneous llvm::

128

This should really be using PatternBenefit instead of int

mlir/lib/Dialect/Linalg/Transforms/Transforms.cpp
41

same here.

216

This looks duplicated

mlir/lib/Dialect/Linalg/Transforms/Vectorization.cpp
44

Replace these two with llvm::hasSingleElement

47

llvm::hasNItems(r.front().begin(), r.front().end(), 3);

97

nit: return success(llvm::all_of(...));

rriddle added inline comments.May 1 2020, 3:49 PM
mlir/include/mlir/Dialect/Linalg/Transforms/Transforms.h
93

These patterns seem light on documentation, can you add some?

mlir/lib/Dialect/Linalg/Transforms/Vectorization.cpp
140

Extraneous semicolon

nicolasvasilache marked 9 inline comments as done.

Address review comments.

nicolasvasilache marked an inline comment as done.May 1 2020, 7:34 PM
rriddle added inline comments.May 1 2020, 8:55 PM
mlir/include/mlir/Dialect/Linalg/Transforms/Transforms.h
15

I don't think all of these are necessary, can you trim this list?

141
//===---...---===//
346

nit: merge this with the else.

mlir/lib/Dialect/Linalg/Transforms/Transforms.cpp
74

Remove the ::mlir::. There are more instances of this throughout the revision.

119

This looks weird. This always resolves to tileLinalgOp.

150

nit: Remove user name from TODOs.

nicolasvasilache marked 8 inline comments as done.May 1 2020, 10:02 PM
nicolasvasilache added inline comments.
mlir/include/mlir/Dialect/Linalg/Transforms/Transforms.h
141

ugh sorry .. thanks!

mlir/lib/Dialect/Linalg/Transforms/Transforms.cpp
119

Thanks for spotting, fixed and added a test.

nicolasvasilache marked 2 inline comments as done.May 1 2020, 10:02 PM

Address review.

Delete spurious file.

bondhugula added a subscriber: bondhugula.EditedMay 2 2020, 12:50 AM

I'm happy to see this revision. I had exactly the same impression on DRR when it was being proposed for scheduling purposes - it's really not a fit, and in many ways goes backward from scheduling constructs written in C++ or other approaches. On a note related to this revision, the affine dialect has a number of standalone utilities to perform composable transformations - these can't be used from inside a pattern rewriter because some of them erase and insert ops and these are disallowed in/break the pattern rewriting framework. How do you propose to deal with that issue in the linalg world? It's common to any approach that's making "more than local" transformations and "local" SSA transformations which is what rewrite rules are designed for and excel in the LLVM world.

ftynse accepted this revision.May 4 2020, 7:29 AM
This revision is now accepted and ready to land.May 4 2020, 7:29 AM
ftynse added a comment.May 4 2020, 8:13 AM

I'm happy to see this revision. I had exactly the same impression on DRR when it was being proposed for scheduling purposes - it's really not a fit, and in many ways goes backward from scheduling constructs written in C++ or other approaches.

+1.

On a note related to this revision, the affine dialect has a number of standalone utilities to perform composable transformations - these can't be used from inside a pattern rewriter because some of them erase and insert ops and these are disallowed in/break the pattern rewriting framework. How do you propose to deal with that issue in the linalg world? It's common to any approach that's making "more than local" transformations and "local" SSA transformations which is what rewrite rules are designed for and excel in the LLVM world.

FWIW, I think many of the affine utilities can be written using the pattern rewriting framework (possibly by extending the framework a bit, but we've made progress): inserting and erasing ops is fine as long as you do so using a rewriter instance. However, they may compose poorly within a single call to the rewrite engine and need to be more staged.

+1 to all these patterns. This is mostly how IREEs code-generation is structured. I can pretty much replace the patterns in IREE to use these instead.

mlir/include/mlir/Dialect/Linalg/Transforms/Transforms.h
203

Is there a similar pattern for TileAndFuse?

267

+1 to this and most patterns below. This is mostly how IREEs code-generation is structured. I can pretty much replace the patterns in IREE to use these instead.

mlir/lib/Dialect/Linalg/Transforms/Loops.cpp
562

I am not sure making this a method is that ergonomic. You cant partially specialize functions like you can do structs. With multiple template parameters having a struct and ability to partially specialize is better?

nicolasvasilache marked 6 inline comments as done.May 4 2020, 2:44 PM
nicolasvasilache added inline comments.
mlir/include/mlir/Dialect/Linalg/Transforms/Transforms.h
203

Not yet (see the commit message).

267

Cool, I need to refactor a bit more on a use case basis.
I'll send a few changes to promotion and arguments soon.

mlir/lib/Dialect/Linalg/Transforms/Loops.cpp
562

There is no type deduction here, it is just called explicitly so it should be equivalent.

nicolasvasilache marked 3 inline comments as done.May 4 2020, 3:01 PM
mlir/test/Dialect/Linalg/transform-patterns.mlir