[PATCH] D75837: Introduce std.execute_region op

Nicolas Vasilache via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 19 07:32:02 PDT 2020


nicolasvasilache added a comment.

Responding in bulk below:

> @nicolasvasilache is that ok with you?

I am not opposed to moving forward and iterating on code as we learn more.
But I still haven't seen a compelling reason to disallow arguments.
I would like some concrete example that illustrates why allowing arguments is a bad idea.

> We can loosen it later if there's a compelling need.

This seems at odds with this other statement:

> Keeping arguments around will necessitate all kinds of tracking/bookkeeping in moving code across, reimplementing existing canonicalizations on this op and largely defeating the purpose of this op - which is to let SSA dominance and dataflow work freely from above and through it.

In other words, either:

1. there are fundamental difficulties involved in which case, refusing arguments pushes concerns to all consumers. Shouldn't difficulty be factored out in one place
2. or it's a simple extension, in which case why not just allow arguments?

I am unclear if we are in case 1., 2. or something else. Which is it?

> @mehdi_amini Can you provide an example of what you?

See `linalg.generic` and `linalg.indexed_generic`, both have region arguments that are derived from the op operands, but are not necessarily the same SSA value 
(e.g there is an interleaved load/store or even loop IV creation).

Now I can see how to use this op in its current form for my particular purpose: I can just move the content of my region inside a new execute_region op as I lower.

But I don't think my questions have been answered so I'll ask again:

  Lambdas often allow both captures and arguments.
  ...
  Is there a fundamental reason to disallow arguments in your op?
  Assuming there exists such a reason, isn't it trivial to check preconditions such as "empty arguments" in verifiers that need it?




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75837





More information about the llvm-commits mailing list