Details
- Reviewers
ftynse nicolasvasilache - Commits
- rG5c3b34930c31: [mlir] Add AffineMaxOp
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Unit tests: pass. 62382 tests passed, 0 failed and 839 were skipped.
clang-tidy: pass.
clang-format: fail. Please format your changes with clang-format by running git-clang-format HEAD^ or applying this patch.
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.
Reply
mlir/include/mlir/Dialect/AffineOps/AffineOps.td | ||
---|---|---|
237–250 | Since there are many common code between AffineMax and AffineMIn. I think the same code could be applied to Ops like avg / sum ops Any better way ? If there is no such ReduceOp ? | |
mlir/lib/Dialect/AffineOps/AffineOps.cpp | ||
2024 | I wrote two tests in canonicalize.mlir which follows the tests of AffineMin, do you mean more tests needed there ? |
Unit tests: pass. 62382 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.
Thanks! I have a couple of comments inline. Major comments:
- the lowering looks incorrect;
- please call SomethingOp only the thing that is an actual Op in the IR, use OpBase or Base for common implementation details.
.gitignore | ||
---|---|---|
48 ↗ | (On Diff #241953) | This should be a separate patch if you intend all of LLVM to follow this. Check out https://stackoverflow.com/questions/1753070/how-do-i-configure-git-to-ignore-some-files-locally if you want to make git ignore files without pushing your personal config upstream. |
mlir/include/mlir/Dialect/AffineOps/AffineOps.td | ||
237–250 | This should not be called "Op", it sounds like it is a separate operation but it is not. I would suggest AffineMinMaxOpBase, a bit ugly but crystal clear. | |
237–250 | Like I mentioned above, calling it an Op is misleading. But factoring out common code is the right approach. I don't think we need affine.add, that can be perfectly expressed with affine.apply instead, unlike min and max. | |
238 | I think we should mark both min and max as not having side effects (in a follow-up commit since min was not marked as such and the change may break something) | |
mlir/lib/Conversion/AffineToStandard/AffineToStandard.cpp | ||
319 | This looks suspicious: why are you calling "lowerAffineMap*Min*` in the pattern for max ? | |
mlir/lib/Dialect/AffineOps/AffineOps.cpp | ||
1938 | There's no such thing as AffineReduceOp. | |
1981–1982 | You can avoid this function by using something like return parseAffineReduceOp<$cppClass>(parser, result); in the ODS file. | |
2024 | I'm fine with this change being in the same revision. It's small enough to review. | |
mlir/test/AffineOps/ops.mlir | ||
84 | Please don't use SSA names in CHECK lines, even if the file around does. See https://mlir.llvm.org/getting_started/TestingGuide/ for more details. | |
mlir/test/Transforms/lower-affine.mlir | ||
618–619 | This lowering looks like it computes min, not max. |
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.
Almost there, a couple more comments.
.gitignore | ||
---|---|---|
48 ↗ | (On Diff #242062) | Spurious change, please remove this from the patch. |
mlir/lib/Conversion/AffineToStandard/AffineToStandard.cpp | ||
260–267 | Please call lowerAffineMapMax here, the same way it is done for lowerAffineUpperBound and min below. | |
mlir/lib/Dialect/AffineOps/AffineOps.cpp | ||
1952 | I think it should be possible to do op.map() isntead of op.getAttr(T::getMapAttrName()). | |
1959 | Use T::getMapAttrName() instead of hardcoded "map". | |
2027 | Nit: update the comment to reflect what the code below does. |
Reply with fixes and several questions
mlir/lib/Dialect/AffineOps/AffineOps.cpp | ||
---|---|---|
1952 | It will cause many test breaks such as : /disk2/ouhang.oh/llvm-project/mlir/test/Dialect/Linalg/tile.mlir:257:12: error: TILE-2: expected string not found in input and <stdin>:37:18: note: with "MAP0" equal to "map0" | |
2027 | Thank you, I will be more careful next time | |
mlir/test/AffineOps/ops.mlir | ||
84 |
I mean should I change affine_max here only or both affine_max and affine_min ?
In my current understanding, the test here is correct ? And I just fixed the lower-affine.mlir, due to misuse of the CmpIPredicate |
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.
mlir/lib/Dialect/AffineOps/AffineOps.cpp | ||
---|---|---|
1952 | It would be nice to understand _why_, but I'm fine with the current approach. | |
2027 | It's generally better not to copy-paste ;) | |
mlir/test/AffineOps/ops.mlir | ||
84 |
I don't see why do you need to change affine_min in any way here. It is generally bad practice to change the tests that are not related to the code changes you are making.
Looks okay to me. |
I think we should mark both min and max as not having side effects (in a follow-up commit since min was not marked as such and the change may break something)