This is an archive of the discontinued LLVM Phabricator instance.

[mlir][Linalg] NFC - Refactor and simplify Promotion
ClosedPublic

Authored by nicolasvasilache on May 6 2020, 6:29 AM.

Details

Summary

This revision introduces LinalgPromotionOptions to more easily control the application of promotion patterns. It also simplifies the different entry points into Promotion in preparation for some behavior change in subsequent revisions.

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptMay 6 2020, 6:29 AM

Initial update
Update.

mravishankar requested changes to this revision.May 6 2020, 9:52 AM

Some initial comments.

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

Should this be a a per operand specification? Suggestion is to have a separate struct that captures per operand specification for this, alignment (and memory space as well. See below).

107

Could we add an option to set memory space here as well? I was touching the same file in a WIP change of mine to add memory space. But you are touching these anyway

267

This seems to diverge from the way patterns are exposed in other places. The convention is AFAIK to use "populate.....Pattern" which takes a OwningRewritePatternList as an argument (by reference) and inserts the pattern. With that you dont need to have the pattern itself exposed just an API to insert the pattern. You could then add as many patterns as you want into that.

mlir/lib/Dialect/Linalg/Transforms/Promotion.cpp
55

Same here. Maybe allow specification of dynamicBuffers, alignment and memory space per subview that is being promoted?

103

Thanks for the comment. Makes it clear what dynamicBuffers are for.

107

Please add extra option to set memory space as well.

288–292

Please add braces around multi-line statements (disclaimer : I dont know if thats the coding standard for LLVM, but dropping trivial braces for single line body seems fine, but this is not a single line body)

318

Why not just use the pattern above here instead of doing a walk explicitly?

This revision now requires changes to proceed.May 6 2020, 9:52 AM
mravishankar added inline comments.May 6 2020, 3:28 PM
mlir/include/mlir/Dialect/Linalg/Transforms/Transforms.h
267

Actually I see now how this is supposed to work. Disregard.

mlir/lib/Dialect/Linalg/Transforms/Promotion.cpp
213

I think these fill needs to have the marker added to it too. If not they can be intercepted by the pattern rewriter which would try to apply transformations on them (AFAIK the marker is supposed to prevent that).
Same is true for the linalg_copy below.

ftynse added inline comments.May 7 2020, 2:33 AM
mlir/lib/Dialect/Linalg/Transforms/Promotion.cpp
49

Could we have some documentation?

262

If you want to call this function from a pattern, you are not allowed to do this (unless it's the root operation of the pattern and you surround it with a proper transaction start/stop)

nicolasvasilache marked 20 inline comments as done.

Address reviews.

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

yes but in a future revision please, this wants to remain NFC.

107

yes but in a future revision please, this wants to remain NFC.
Feel free to rebase a memory space change on top of this.
I expect a few followup revisions will add a few more per operand options.

267

Ack

mlir/lib/Dialect/Linalg/Transforms/Promotion.cpp
55

yes but in a future revision please, this wants to remain NFC.

107

yes but in a future revision please, this wants to remain NFC.

213

I am envisioning is an analysis would place markers that will trigger patterns.
Anything unmarked would not be rewritten in the first place.

I think we can experiment with different scenarios in the future.
In any case, changing this now would make the revision non-NFC.

262

This is indeed called from under

rewriter.updateRootInPlace(op, [&]() {

and the prereq checks that it will succeed.

I can revert to the old behavior if you prefer but it seems like a legitimate use to me?

318

Because it is unfortunately not strictly equivalent ..
The folder that is passed here does additional cleanups on the fly that cannot be applied as a pattern.
This is one of the reasons that motivates rewriting transforms as staged pattern applications (a few revisions down the line).

Once those are in we can drop the folder and use the patterns.

mravishankar accepted this revision.May 8 2020, 8:57 AM

Could you let me know when you are done with most refactoring so that I can pick up some other things that intersected with this refactoring work. I dont want to be touching the same code will its being modified.

mlir/lib/Dialect/Linalg/Transforms/Promotion.cpp
213

Ok, lets sync about this offline. Maybe the way I was thinking about this is reverse from what you mentioned. By reading the code, I was thinking that you do a transformation and set a marker, preventing it from being transformed again. But what is being done is that it is setting the maker for the next stage of transformation to kick in. I need to account for this in IREE codegen. Will take a look after all the refactoring is done.

This revision is now accepted and ready to land.May 8 2020, 8:57 AM
This revision was automatically updated to reflect the committed changes.
rriddle added inline comments.May 27 2020, 12:16 PM
mlir/include/mlir/Dialect/Linalg/Transforms/Transforms.h
96

operandsToPromote = DenseSet<unsigned>(operands.begin(), operands.end())?

mlir/lib/Dialect/Linalg/Transforms/Promotion.cpp
75

nit: Can we early exit here?

mehdi_amini added inline comments.Jun 5 2020, 1:25 AM
mlir/include/mlir/Dialect/Linalg/Transforms/Transforms.h
96
Herald added a project: Restricted Project. · View Herald TranscriptJun 5 2020, 1:25 AM
Herald added a subscriber: msifontes. · View Herald Transcript