[PATCH] D72223: [MLIR] Introduce affine.execute_region op

Uday Bondhugula via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 29 03:59:06 PDT 2021


bondhugula added a comment.

In D72223#2845698 <https://reviews.llvm.org/D72223#2845698>, @mehdi_amini wrote:

> Re-read the RFC on "graybox", I am still entirely unconvinced by the current design and the explicit capture of memref used here. I think this is less flexible and not justified all-in-all.  believe the more extensible alternative is to support opaque nested regions in general and treat them conservatively as new scope (basically what I wrote above about reversing the trait).
> But I'm not willing to die on this hill today, if @ftynse agrees with you that `affine` should stay a bit more isolated, and that this explicit capture is really worth it right now, then feel free to move forward.

Actually, if you don't want explicit memref captures, you can just use `scf.execute_region` as is! There would be no difference besides the fact that the latter would be from the `scf` dialect mixed with affine dialect ops and being looked at by affine passes/utilities etc. for transformation purposes, which is fine. I have felt that having a list of memrefs on the operand list of an affine.execute_region simplifies everything (passes/utilities) doing a walk from the top - they deal with that op transparently just like any other non-region holding op that has memref operands. But I'm willing to hold on to this revision until the use case beyond what can already be served by scf.execute_region arrives. We need to perhaps first think about extending affine passes properly in the presence of `scf.execute_region` ops and reevaluate this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72223



More information about the llvm-commits mailing list