[PATCH] D77320: [MLIR] fix/update affine data copy utility for max/min bounds

Diego Caballero via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 2 16:50:20 PDT 2020


dcaballe added inline comments.


================
Comment at: mlir/lib/Dialect/Affine/Transforms/AffineDataCopyGeneration.cpp:276
+  AffineStoreOp::getCanonicalizationPatterns(patterns, &getContext());
+  applyPatternsGreedily(f, std::move(patterns));
 }
----------------
I'm not asking for any changes now but just wondering if it would make sense in the future to do all of these "clean-up" optimizations in a separate pass(es) that we can invoke as needed, maybe after running a bunch of optimizations instead of trying to optimize right after each one if it's not absolutely necessary. I guess that could reduce compile time and avoid duplicating this clean-up per pass. IIRC, loop fusion performed also some optimization around temporary tensors after fusion. Not sure if that optimizations would also fit into this category.  


================
Comment at: mlir/lib/Transforms/Utils/LoopUtils.cpp:1488
+  unsigned rank = memref.getType().cast<MemRefType>().getRank();
+  (void)rank; // unused in opt mode
+  assert(lbMaps.size() == rank && "wrong number of lb maps");
----------------
used in line 1496


================
Comment at: mlir/test/Dialect/Affine/affine-data-copy.mlir:114
 //  FILTER-NOT:   alloc()
-//      FILTER:   affine.for %{{.*}} = 0 to 128 {
+//      FILTER:   affine.for %{{.*}}
 //      FILTER:     affine.for %{{.*}} = 0 to 4096 {
----------------
nit: you can remove the `%{{.*}}`


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D77320/new/

https://reviews.llvm.org/D77320





More information about the llvm-commits mailing list