[PATCH] D79502: [mlir] Support partial folding of affine.min/max
Alex Zinenko via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu May 7 03:55:07 PDT 2020
ftynse added inline comments.
================
Comment at: mlir/lib/Dialect/Affine/IR/AffineOps.cpp:2107
+
+ results.reserve(map.getNumResults());
+ for (AffineExpr expr : map.getResults()) {
----------------
nicolasvasilache wrote:
> How about a 2 steps impl?
>
> ```
> if (llvm::any_of(...))
> return failure();
> auto range = llvm::map_range();
> results.assign(range.begin(), range.end());
> ```
>
> I'd say the readability improvements are worth it, you choose.
I tried, and it's actually more verbose because of lambdas.
================
Comment at: mlir/lib/Dialect/Affine/IR/AffineOps.cpp:2162
+ // If some of the map results are not constant, try changing the map in-place.
+ SmallVector<int64_t, 2> results;
+ if (failed(extractIntegerResults(foldedMap, results))) {
----------------
nicolasvasilache wrote:
> andydavis1 wrote:
> > Seems like this block of code could be shared with AffineMin::Fold
> Or have the whole impl factored out and just take either `std::min/max_element` as a parameter?
taking an instantiation of an STL algorithm as a parameter looks very ugly, so I just went for an if(std::is_same)
================
Comment at: mlir/lib/IR/AffineMap.cpp:242
+ // containing those constants.
+ results.reserve(newMap.getNumResults());
+ for (AffineExpr expr : newMap.getResults()) {
----------------
nicolasvasilache wrote:
> Same potential 2-step readability gains as above.
It's even better with the refactoring suggested by Andy below.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D79502/new/
https://reviews.llvm.org/D79502
More information about the llvm-commits
mailing list