[PATCH] D75837: Introduce std.execute_region op

[Uday Bondhugula via Phabricator via llvm-commits]

bondhugula added a comment.

> Since river is working on making dataflow be able to transparently look through non-explicit captures for ops like this, how important is it to not have explicit args?
> 
> That is, we can canonicalize the args away, but having the args shouldn't hurt? I

I think there is some communication gap here and perhaps different things being mixed. If you've explicitly captured something, you've already created a barrier: for eg. consider a dynamically shaped memref explicitly captured that prevents a static shape from flowing in via a memref cast used from above; unless you replace the memref with the statically shaped one, you won't see the static shape for whatever analysis/transform. For the affine graybox, I had done a detailed analysis of the costs of just explicitly capturing memrefs (see for eg. how it complicates dead dealloc removal):
https://github.com/polymage-labs/mlirx/blob/master/mlir/rfc/rfc-graybox.md#maintaining-memref-operandsarguments
There is no way around registering and implementing canonicalizations for what would have otherwise worked. The advantage of explicitly capturing memrefs in the context of the graybox was that you don't have to look inside the op to see which memory is being accessed and you don't want to because it's part of a different polyhedral scope with its own symbols; so the downsides of explicit capture IMO are outweighed by how they simplify polyhedral passes. For execute_region, there is no such argument in favor of explicit captures. You just have to do a simple replaceAllUsesWith to propagate what you thought of as explicit captures (this is what I already do when I convert an affine.graybox to an execute_region in D72223 <https://reviews.llvm.org/D72223>.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75837