Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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 | Update filename | |
9 | Update filename | |
38 | Renamed to Conv2DIsFullyConnected | |
126 | Rename to DepthwiseConv2DIsMul | |
226 | remove comment. | |
231 | Remove | |
240 | Remove comment. |
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? |
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 ? |
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. |
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. |
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. |
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. |
mlir/include/mlir/Dialect/Tosa/Transforms/Passes.td | ||
---|---|---|
64 |
Why? I'm asking somehow naively here, I haven't looked into why [FullyConnected->Reshape->Rescale] wouldn't be as convenient as [conv 1x1]. (Worst case, we may end-up with a pass named DecomposeConv1x1 or something like that) |
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 .. |
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. |
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:
This matches the general idioms followed in the rest of the compiler I believe. |
mlir/include/mlir/Dialect/Tosa/Transforms/Passes.td | ||
---|---|---|
64 | (1) We can do this approach. This gives flexibility I agree. |
mlir/include/mlir/Dialect/Tosa/Transforms/Passes.td | ||
---|---|---|
64 |
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. |
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. |
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.
Alphabetical ordering.