This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Move non-generic rewrite patterns out of the canonicalizer into a pass than can be added to the pass pipeline if so required
ClosedPublic

Authored by aardeb on Dec 16 2021, 10:42 AM.

Diff Detail

Event Timeline

aardeb created this revision.Dec 16 2021, 10:42 AM
aardeb requested review of this revision.Dec 16 2021, 10:42 AM
aardeb updated this revision to Diff 394930.Dec 16 2021, 11:11 AM

Update commit message

rsuderman requested changes to this revision.Dec 16 2021, 11:58 AM
rsuderman added inline comments.
mlir/include/mlir/Dialect/Tosa/Transforms/Passes.h
27

Alphabetical ordering.

mlir/include/mlir/Dialect/Tosa/Transforms/Passes.td
61

Please rename to TosaOptimization along with all other uses.

64

Reword content

"Optimization pass to perform simplification on a number of TOSA operations.

mlir/lib/Dialect/Tosa/Transforms/TosaOperationOptimizations.cpp
1 ↗(On Diff #394930)

Update filename

9 ↗(On Diff #394930)

Update filename

38 ↗(On Diff #394930)

Renamed to Conv2DIsFullyConnected

126 ↗(On Diff #394930)

Rename to DepthwiseConv2DIsMul

226 ↗(On Diff #394930)

remove comment.

231 ↗(On Diff #394930)

Remove

240 ↗(On Diff #394930)

Remove comment.

This revision now requires changes to proceed.Dec 16 2021, 11:58 AM
aardeb updated this revision to Diff 394971.Dec 16 2021, 1:04 PM
aardeb marked 10 inline comments as done.

Address comments on Phabricator

You have a typo in the title: "canonicilizer"
Also the description is weird here with: "Change-Id: I1cf5cb82d7736a0252b723807cbf7b2d00ae6756", can you clean this up as well?

mlir/include/mlir/Dialect/Tosa/Transforms/Passes.td
64

"optimization" is a bit generic, can you characterize more what this is about?

aardeb updated this revision to Diff 395039.Dec 16 2021, 6:38 PM

Update Summary

aardeb updated this revision to Diff 395041.Dec 16 2021, 6:42 PM
aardeb retitled this revision from [mlir] Move non-generic rewrite patterns out of the canonicilizer into a pass than can be added to the pass pipeline if so required to [mlir] Move non-generic rewrite patterns out of the canonicalizer into a pass than can be added to the pass pipeline if so required.

Update Title

aardeb edited the summary of this revision. (Show Details)Dec 16 2021, 6:49 PM
rsuderman accepted this revision.Dec 16 2021, 11:24 PM
This revision is now accepted and ready to land.Dec 16 2021, 11:24 PM
mehdi_amini added inline comments.Dec 17 2021, 2:40 PM
mlir/include/mlir/Dialect/Tosa/Transforms/Passes.td
64

Ping: this wasn't addressed.

64

To be clear: I'm objecting to the name of the pass itself, not just the doc.

aardeb added inline comments.Dec 18 2021, 11:29 AM
mlir/include/mlir/Dialect/Tosa/Transforms/Passes.td
64

Apologies we missed this comment.

So the concern is about the name of the file: TosaOptimization.cpp as well as the pass name TosaOptimization it is too generic.

I am struggling to come up with a better name since the file is aimed to put optional rewrites one may use in their pipelines. Would something like TosaOptionalOptimization.cpp be better ?

mehdi_amini added inline comments.Dec 18 2021, 12:46 PM
mlir/include/mlir/Dialect/Tosa/Transforms/Passes.td
64

Not really: the word "Optimizations" in itself is too broad and vague. I'm looking for something more descriptive, adding "Optional" in front of it does not help.

aardeb added inline comments.Dec 20 2021, 10:06 AM
mlir/include/mlir/Dialect/Tosa/Transforms/Passes.td
64

The best I can honestly think of is TosaOptionalCanonicalizations.cpp. This describes what the rewrites are optional canonicalization's that can be included into the pass pipeline or not.

mehdi_amini added inline comments.Dec 20 2021, 11:29 AM
mlir/include/mlir/Dialect/Tosa/Transforms/Passes.td
64

Why are these canonicalization optional and not part of the canonicalizer?

64

I'm asking to probe into finding a better name, because if these are canonicalization then they shouldn't be pulled out of the canonicalizer, so there is likely something more "descriptive" that capture what this is exactly.

aardeb added inline comments.Dec 20 2021, 11:44 AM
mlir/include/mlir/Dialect/Tosa/Transforms/Passes.td
64

The rewrites that where moved out do things like converting a [conv 1x1] to [FullyConnected->Reshape->Rescale].

I would not really call these canonicalization but rather specific transformations/optimizations.

From my point of view these should not be enforced canonicalizations done so early in the stack, where we have no option to enable/disable them, but it should be left to the backend to decide if, where and how we apply such a rewrite. Hence placing then in the canonicalizer seems like the wrong place, and instead should be optional rewrites developers can decide to use.

mehdi_amini added inline comments.Dec 20 2021, 11:50 AM
mlir/include/mlir/Dialect/Tosa/Transforms/Passes.td
64

From my point of view these should not be enforced canonicalizations done so early in the stack, where we have no option to enable/disable them, but it should be left to the backend to decide if, where and how we apply such a rewrite

Why?

I'm asking somehow naively here, I haven't looked into why [FullyConnected->Reshape->Rescale] wouldn't be as convenient as [conv 1x1].
What about the opposite though: Would [FullyConnected->Reshape->Rescale] -> [conv 1x1] be OK as a canonicalization? If not why? If they are strictly equivalent form, then why can't we pick one canonical form for this computation?

(Worst case, we may end-up with a pass named DecomposeConv1x1 or something like that)

aardeb added inline comments.Dec 20 2021, 11:52 AM
mlir/include/mlir/Dialect/Tosa/Transforms/Passes.td
64

What I am thinking is we can split each rewrite (there are only two) into its own file and name it something like TOSAConvtoFullyConnected.cpp etc ..

aardeb added inline comments.Dec 20 2021, 11:56 AM
mlir/include/mlir/Dialect/Tosa/Transforms/Passes.td
64

Because if I loose the information that I had a conv1x1 so early on, I can miss optimisations on hardware which has fixed function units that can run conv1x1 efficiently. Also I want to avoid doing bottom-up pattern matching to go from [FullyConnected->Reshape->Rescale] -> [conv 1x1] if possible as that costs time. Going from conv[1x1] -> [FullyConnected->Reshape->Rescale] -> conv[1x1] seems inefficient.

mehdi_amini added inline comments.Dec 20 2021, 12:06 PM
mlir/include/mlir/Dialect/Tosa/Transforms/Passes.td
64

So you're saying that the canonical form is conv[1x1] and so that [FullyConnected->Reshape->Rescale] -> conv[1x1] would be a valid canonicalization right?

Right now I would:

  • expose a method publicly to get the pattern(s) (and name it populateTosaConvDecompositionPatterns() or something like that)
  • make this pass a test pass only that exercise the pattern(s), such pass lives in the test/ folder and isn't publicly available, the expectation is that instead you can insert the patterns in your dialect conversion as you see fit (or wrap them in a pass if this is really what you want, but canonicalization can undo it).
  • Add the [FullyConnected->Reshape->Rescale] -> conv[1x1] canonicalization.

This matches the general idioms followed in the rest of the compiler I believe.

aardeb added inline comments.Dec 20 2021, 12:56 PM
mlir/include/mlir/Dialect/Tosa/Transforms/Passes.td
64

(1) We can do this approach. This gives flexibility I agree.
(2) We can take this approach also
(3) I am still trying to come to terms if this should be a canonicalization also or an optional rewrite like the others. I will differ this for now as since FC is probably being removed from TOSA we would need to rewrite it anyway.
I can work on a new commit that does (1) and (2).

mehdi_amini added inline comments.Dec 20 2021, 12:59 PM
mlir/include/mlir/Dialect/Tosa/Transforms/Passes.td
64

(3) I am still trying to come to terms if this should be a canonicalization also or an optional rewrite like the others.

In general you need a good reason for it to not be a canonicalization: i.e. if we have to form strictly equivalent in the IR, it is rare that there isn't one that we will choose a more canonical than the other (I'm saying "it is rare" but I can't think of an example right now actually, but I don't want to just claim it does not exist). This is quite fundamental to the concept of canonicalization I believe.

aardeb added inline comments.Dec 21 2021, 1:36 AM
mlir/include/mlir/Dialect/Tosa/Transforms/Passes.td
64

Ok, if we can detect [Reshape->FC->Reshape->Rescale] this could be canonicalized to [conv 1x1->Rescale] assuming the conditions are met and can be reliably detected.

mehdi_amini added a comment.EditedDec 29 2021, 6:26 PM

It seems that like lib/Dialect/Tosa/Transforms/TosaOptimization.cpp is full of Windows-style eol \n\r, is it?

I have a patch ready that does the changes as you suggested above. I can't push it until Monday as I don't have access to the code. Before I upload on Monday I can run a dos2unix on the files to see if they need cleaning. Hope that resolves the issue.