[MLIR] Add RegionKindInterface

[stephenneuendorffer]

Summary

Some dialects have semantics which is not well represented by common
SSA structures with dominance constraints. This patch allows
operations to declare the 'kind' of their contained regions.
Currently, two kinds are allowed: "SSACFG" and "Graph". The only
difference between them at the moment is that SSACFG regions are
required to have dominance, while Graph regions are not required to
have dominance. The intention is that this Interface would be
generated by ODS for existing operations, although this has not yet
been implemented. Presumably, if someone were interested in code
generation, we might also have a "CFG" dialect, which defines control
flow, but does not require SSA.

The new behavior is mostly identical to the previous behavior, since
registered operations without a RegionKindInterface are assumed to
contain SSACFG regions. However, the behavior has changed for
unregistered operations. Previously, these were checked for
dominance, however the new behavior allows dominance violations, in
order to allow the processing of unregistered dialects with Graph
regions. One implication of this is that regions in unregistered
operations with more than one op are no longer CSE'd (since it
requires dominance info).

I've also reorganized the LangRef documentation to remove assertions
about "sequential execution", "SSA Values", and "Dominance". Instead,
the core IR is simply "ordered" (i.e. totally ordered) and consists of
"Values". I've also clarified some things about how control flow
passes between blocks in an SSACFG region. Control Flow must enter a
region at the entry block and follow terminator operation successors
or be returned to the containing op. Graph regions do not define a
notion of control flow.

see discussion here:
https://llvm.discourse.group/t/rfc-allowing-dialects-to-relax-the-ssa-dominance-condition/833/53

[rriddle]

mlir/docs/LangRef.md

41 ↗

(On Diff #270250)

I feel the same way as Mehdi. I would rephrase to something like:

Operations can be arbitrarily extended in MLIR, and may represent many different concepts ...
...

I would even consider removing the bit about verification. Feels a bit out of place here.

539 ↗

(On Diff #270250)

I don't agree on the principal here. We only have to be conservative if it "could" be something that has valid semantics when registered. For example, we have to be conservative about unregistered operations that "could" be symbol tables, but that doesn't mean we error out if we see any unregistered region holding operation. Being unregistered IMO is just having the capability of being anything legal. If something isn't legal when registered, why should we guard against it when unregistered?

546 ↗

(On Diff #270250)

Correct. There is no modeling ATM for indirect branches where you have no idea what the potential destination could be.

30 ↗

(On Diff #270965)

nit: I find this definition confusing given that arguments to blocks are also values.

204 ↗

(On Diff #270965)

nit: are only in scope

206 ↗

(On Diff #270965)

This isn't true. This goes into symbol table semantics, which scopes the visibility with its own set of rules. https://mlir.llvm.org/docs/SymbolsAndSymbolTables/

420 ↗

(On Diff #270965)

Can you reword this? It gives off the vibe that the terminator is actually generating the value, but terminator operations don't generally have results. Some terminator operations may produce the PHI value internally, but those are not very common. I would rephrase to "provided" or something similar.

497 ↗

(On Diff #270965)

nit: Can you mention IsolatedFromAbove here and link to the doc on it?

535 ↗

(On Diff #270965)

However, the particular semantics of operations are
unspecified and completely specify the behavior of an operation and
inside the regions of an operation.

Can you rephrase this? I'm having trouble parsing it.

538 ↗

(On Diff #270965)

nit: Link to the documentation for this.

545 ↗

(On Diff #270965)

nit: the potential successor blocks

553 ↗

(On Diff #270965)

nit: are treated as unreachable and may be

577 ↗

(On Diff #270965)

nit: Regions -> regions

mlir/include/mlir/IR/RegionKindInterface.h

1 ↗

(On Diff #270965)

This line looks like it is one character to short.

14 ↗

(On Diff #270965)

Please fix the header guard style.

17 ↗

(On Diff #270965)

Can you trim these?

26 ↗

(On Diff #270965)

Please add documentation here on what these are and what they mean.

29 ↗

(On Diff #270965)

Graph? SSACFG contains acronyms so I see why they are capitalized.

mlir/include/mlir/IR/RegionKindInterface.td

27 ↗

(On Diff #270965)

nit: Can you reflow this and move it to the next line? The doc formatter can handle this automatically.

27 ↗

(On Diff #270965)

Missing period at the end of the summary.

30 ↗

(On Diff #270965)

nit: Remove double space.

39 ↗

(On Diff #270965)

nit: Please use multi line string for this description.

47 ↗

(On Diff #270965)

Leftover debugging?

55 ↗

(On Diff #270965)

Please remove.

60 ↗

(On Diff #270965)

Please fix the header guard style.

mlir/include/mlir/Interfaces/CMakeLists.txt

7 ↗

(On Diff #270965)

Seems unrelated.

mlir/lib/IR/RegionKindInterface.cpp

18 ↗

(On Diff #270965)

I don't think this is necessary.

mlir/lib/IR/Verifier.cpp

31

I don't think this is necessary.

[rriddle]

mlir/test/lib/Dialect/Test/TestDialect.cpp

227

Please remove the mlir:: from each of these.

[stephenneuendorffer]

Update after review changes

mlir/docs/Interfaces.md

232 ↗

(On Diff #270965)

Certainly! I figure writing a few by hand would lead us to that.

mlir/docs/LangRef.md

33 ↗

(On Diff #270250)

Yes, exactly. The point of this is that the order of instructions in the IR does not need to correspond to the execution order of instructions in a sequential machine. Even in a graph, the IR still maintains an order, which enables deterministic round-tripping, for instance.

41 ↗

(On Diff #270250)

What is an "Operation Definition" other than traits, interfaces, and verification constraints? operand and result names? successor names? I've reworded this section.

539 ↗

(On Diff #270250)

@rriddle I don't understand whether you are disagreeing with Mehdi or me.

I think that if ops are unregistered we should be pretty liberal about what should be allowed. Structually, the only requirement I've imposed on regions of unregistered ops is that all value identifiers must be defined. In particular, I have not required that regions of unregistered operations must be either 1) a single block or 2) a valid SSACFG region with dominance. (I think this was suggested in the discussion)

546 ↗

(On Diff #270250)

I was also thinking about something co-routine like where Blocks could yield to another block chosen by the containing operation.

468 ↗

(On Diff #270965)

How so? The point of this is to show the structures that are important and that are the requirements on those structures, so I'm trying to define a region structurally separate from the CFG semantics. What would you add to this, other than "it's a CFG?"

545 ↗

(On Diff #270965)

we don't call them "potential successors' anywhere else. I think the meaning is clear from the following sentence

[rriddle]

mlir/docs/LangRef.md

546 ↗

(On Diff #270250)

You could also implement coroutines with an explicit switch in the entry block that contains each of the potential resume points.

[rriddle]

mlir/lib/IR/Verifier.cpp

238

I don't think this is correct. You are missing checks for how dominance interacts across different regions. Even if there is no intra-region dominance, there are still constraints how values may be used across regions. For example, the operand values have to be defined in this region or an ancestor region. This is also missing checks on how verification happens when the value is defined in a region with dominance and used in a region without. The dominance relationship between the ancestor operation in the region with dominance must still be checked, i.e.,

// region with dominance
func @foo() {
  // region without dominance
  bar.non_dominance_region {
    // Verifier failure: This is a non-dominating use.
    bar.use %foo_value
    bar.return
  }
  %foo_value = constant true

[mehdi_amini]

mlir/docs/LangRef.md

33 ↗

(On Diff #270250)

Yes, exactly

I was pointing out something that seems contradictory, so I'm puzzled by your answer here?

Even in a graph, the IR still maintains an order, which enables deterministic round-tripping, for instance.

Yes but there is still no total order since you have cycles.

The point of this is that the order of instructions in the IR does not need to correspond to the execution order of instructions in a sequential machine.

OK but the way it is written is still confusing to me. You're also using "Region" as if it is a well defined term while it is the first use in the doc.
I'll look for an alternative writing after we settle on the description of multi-blocks region below.

Operations are also organized into [Blocks](#blocks) and are totally ordered
within their containing [Region](#regions)

539 ↗

(On Diff #270250)

In particular, I have not required that regions of unregistered operations must be either 1) a single block or 2) a valid SSACFG region with dominance. (I think this was suggested in the discussion)

This complicates the design, and I don't believe your specification is complete right now with respect to non-CFG multi-blocks region.

The paragraph that follows is a good example, when it says that when control flow enters a region, it always begins in the first block of the region, called the *entry* block we already have a notion of control for the blocks. Then Control flow can only pass to one of the specified successor blocks as in a branch operation, or back to the containing operation as in a return operation. Terminator operations without successors can only pass.
In your example above:

"unregistered_op" () ({
^bb1:
  %2 = %1
  %1 = %2
^bb2:
  %3 = %2
}

The second block is clearly unreachable and can just be deleted.

It also means that:

"unregistered_op" () ({
^bb1:
  %2 = %3
  %1 = %2
^bb2:
  %3 = ...
}

Would be invalid IR.

[stephenneuendorffer]

mlir/docs/LangRef.md

33 ↗

(On Diff #270250)

OK.. I see there being several relationships here. One is the total order of operations in a block and blocks in a region. There is a separate relationship which is the data dependence relationship, which I don't think is actually a partial order on operations in Graph regions or SSACFG regions. Certainly not if terminator edges are included.

539 ↗

(On Diff #270250)

My intention is that the "Control Flow" section here only applies to SSACFG regions. Maybe there needs to be a separate section on Graph regions. Your example illustrates why 'reachability' of basic blocks is probably not a great concept in graph regions.

mlir/lib/IR/Verifier.cpp

238

Right... I think some more test cases are in order here.

[mehdi_amini]

mlir/docs/LangRef.md

468 ↗

(On Diff #270965)

I see the structure as trivial: only the semantics is complex (i.e. reachability, control-flow, etc.).

So I'm not sure what's the point of long description of what could be shown with a few lines of grammar specification (or even 10 lines of C++).

[stephenneuendorffer]

mlir/docs/LangRef.md

468 ↗

(On Diff #270965)

I think the structure is actually harder to grok than you might think for outsiders. Also, I think the syntactic issues of how it is represented as a grammar doesn't necessarily reflect what you need to know to use it from c++. (In fact, I've been considering if these need to be separated further, having a separate page for an abstract description and leave most of what is currently in LangRef.md as a description of the concrete grammar syntax.)

I think one of the things that is missing right now is that the semantics is quite flexible, but not without bounds. Also the syntax is quite flexible, but also not without bounds. I see this as a step towards being explicit about those bounds, at least on the semantic side.

mlir/lib/IR/Dominance.cpp

37–56 ↗

(On Diff #274277)

FYI: This is a significant departure from the previous patch, which attempted to put the 'smarts' in the Verifier. It seems like in order to deal properly with Mehdi's testcase where a graph region encloses an SSACFG region, without duplicating alot of the traversal, that all kinds of regions need a notion of dominance. It seems to me that the right notion of dominance for graph regions is that all values are in-scope in all blocks. so: all blocks dominate all other blocks and all values within a block dominate all other values. This also highlights the fact that CSE needs some different machinery to properly handle Graph Regions, since it currently traverses using DominatorTrees.

mlir/lib/IR/Verifier.cpp

238

I've added some tests for this. The more problematic case is the reverse:

// region without dominance
bar.non_dominance_region() {
  // region with dominance
  bar.dominance_region {
    // Should this be illegal?
    bar.use %foo_value
    bar.return
  }
  %foo_value = constant true

It's not clear to me that there is a useful interpretation for this. At the moment I've made this illegal, but it's something that could conceivably be relaxed.

[stephenneuendorffer]

mlir/lib/IR/Verifier.cpp

238

The code above is actually legal, since "%foo_value" is legal to use as an argument to bar.dominance_region

[rriddle]

mlir/lib/IR/Verifier.cpp

238

The fairly simple rule that I've always applied to dominance is that the parent operations act as dominance synch points. The parent operation of the definition has to dominate the ancestor of the user that is within that region.

[stephenneuendorffer]

mlir/lib/IR/Verifier.cpp

238

Agreed. And I think this lifts immediately to Graph Regions: In a Graph Region, everything dominates everything else.

[mehdi_amini]

mlir/docs/LangRef.md

440 ↗

(On Diff #274283)

This defines block in a way that does not seem to me to be compatible with graph regions.

495 ↗

(On Diff #274283)

You define a notion of successor here, does it generalize to graph region?

539 ↗

(On Diff #274283)

in which case some other operation will execute

That does not read well to me right now.

595 ↗

(On Diff #274283)

It is interesting that this ends up nested under the SSACFG region case

626 ↗

(On Diff #274283)

typo: relatinoships

628 ↗

(On Diff #274283)

I think it should be either with values representing streams of data. or where values represent streams of data.

656 ↗

(On Diff #274283)

The story about block terminators, successors, etc. isn't clear to me with respect to graph region. Even the relationship between blocks isn't entirely clear here actually.

mlir/include/mlir/IR/Dominance.h

63 ↗

(On Diff #274283)

The concept of entry block is no longer a guarantee

[stephenneuendorffer]

mlir/docs/LangRef.md

495 ↗

(On Diff #274283)

Currently we keep around blocks in a graph region after transforming from an SSACFG region. The blocks aren't semantically meaningful (and can be eliminated in our current model without changing the semantics), but are at least useful bookkeeping.

539 ↗

(On Diff #274283)

I agree it's a little vague, but it's trying to bridge into the next section which talks about control flow and terminators. Do you have a suggestion?

595 ↗

(On Diff #274283)

It's all about control flow with multiple regions. Graph regions don't have a notion of control flow.

656 ↗

(On Diff #274283)

Correct, I haven't defined any semantic requirements about blocks in graph regions.

mlir/include/mlir/IR/Dominance.h

63 ↗

(On Diff #274283)

There are some aspects of the interface of this class which are awkward. If regions define their own concept of dominance, then there probably needs to be an abstract interface exposing different implementations of the 'local' concept of dominance. Currently, the two implementations are somewhat awkwardly tangled together along with the hierarchy traversing code. I see that there should be some additional refactoring of this code which might push the local concept of dominance into RegionKindInterface, but I'd like to get the concepts agreed to first.

Another example is that getRootNode() has to be guarded by hasDominanceInfo(). getRootNode() isn't really appropriate for regions without an entry block.

[mehdi_amini]

mlir/docs/LangRef.md

45 ↗

(On Diff #274339)

each transformation on operations to be designed with the semantics in mind

I don't understand what this means here.

211 ↗

(On Diff #274339)

Argument identifiers in mapping functions

Not sure what "mapping function" refers to here? It is in the existing doc, but this is the only place it is used. I wonder if it isn't something remaining from before functions were regular Operations?

Is this about block argument? Can you just write "Block argument" instead?

Edit: I wonder if this is about affine maps?
(we can leave this out of this revision, but we should probably revisit this)

213 ↗

(On Diff #274339)

Particular operations may further limit the valid scope of identifiers

I think this is not specific enough: the scope is only limited by the region kind and I'd rather spell it out this way.
With how you wrote it, one could think that we could have an operation restricting the scope of the value it produces (for example to be block-local).

339 ↗

(On Diff #274339)

It isn't clear to me why a module wouldn't be a graph region?
Do we put any meaning to the order of operations in a module?

428 ↗

(On Diff #274339)

Is "commonly" intended to express that this isn't always the case?
What about spelling out the exact case: "In a SSACFG region, blocks represent ...`

435 ↗

(On Diff #274339)

i.e. Branches

Shouldn't this be e.g. instead?

478 ↗

(On Diff #274339)

I feel the section here isn't entirely complete with respect to non CFG region with multiple blocks: are these still having terminator? What's the contract on block arguments?

An example would be worthwhile as well.

33 ↗

(On Diff #270250)

In the definition of Blocks, we just wrote A *Block* is an ordered list of operations, can we just do the same here and avoid "totally ordered"?
Maybe like the following:

Operations are also organized into [Blocks](#blocks) as ordered list  (the order may or may not have a semantics important, see [Region Kinds](link)).  Blocks are themselves organized as an ordered list within their containing [Region](#regions).

[mehdi_amini]

mlir/docs/LangRef.md

656 ↗

(On Diff #274283)

To me this is like my comment above about terminator, successor, etc.
Even if it isn't requires, let's make it explicit.

[stephenneuendorffer]

mlir/docs/LangRef.md

45 ↗

(On Diff #274339)

I've rewritten this section.

211 ↗

(On Diff #274339)

Yes, I believe this is talking about affine maps.

213 ↗

(On Diff #274339)

You're right, that could be misleading. I've rewritten it.

339 ↗

(On Diff #274339)

I suppose it could be, although it's somewhat of a degenerate kind of region anyway, since modules don't define any values and don't contain blocks. Maybe this should be another kind of region?

478 ↗

(On Diff #274339)

I added an additional note about the Graph Region rationale, but I'm really not sure how to provide an example here of something that I don't have a good example of :). Let's chat offline about this.

[mehdi_amini]

mlir/docs/LangRef.md

677 ↗

(On Diff #275753)

The indentation does not seem right in this example?
The reuse of %2 does not help readability either, just like %4 before %2

[rriddle]

Thanks for all of the work on this! Mostly nits, so I think this looks good enough to land for now after resolving. We can iterate on the other necessary aspects afterwards.

mlir/docs/Interfaces.md

206 ↗

(On Diff #277629)

nit: Drop the newline here.

232 ↗

(On Diff #270965)

ODS can already generate the documentation. I'll take a look at hooking it into here after this lands.

https://github.com/llvm/llvm-project/blob/bf74c3838904b2df2a0f31bc457af1bdb811953f/mlir/tools/mlir-tblgen/OpInterfacesGen.cpp#L414

mlir/docs/LangRef.md

29 ↗

(On Diff #277629)

nit: *Operations* to match the *Values* later.

30 ↗

(On Diff #277629)

nit: I would clarify Argument ->Block Argument here.

33 ↗

(On Diff #277629)

nit: Regions to match the tense of the others.

221 ↗

(On Diff #277629)

nit: You may want to clarify here that nested regions count as being within the parent region.

353 ↗

(On Diff #277629)

Should a module be an SSA CFG region? It could very well be a graph region.

(This is not meant to block anything, but something to consider for the future).

358 ↗

(On Diff #277629)

nit: Could you please you link symbol name to the symbol doc again here?

442 ↗

(On Diff #277629)

typo: represent represents

449 ↗

(On Diff #277629)

Seems like this only applies to non-entry blocks, as the entry block(s) may have values provided the parent operation.

514 ↗

(On Diff #277629)

nit: Can you remove the double space before The.

532 ↗

(On Diff #277629)

nit; Same here, seems to be a few double space sentences in this paragraph.

543 ↗

(On Diff #277629)

nit: Remove the indent of this code snippet.

555 ↗

(On Diff #277629)

nitL Double space here.

569 ↗

(On Diff #277629)

nit: Double space here.

582 ↗

(On Diff #277629)

typo: ot.

662 ↗

(On Diff #277629)

nit: Can you wrap this in a Context or Rationale section? I think there are other examples in this doc.

674 ↗

(On Diff #277629)

nit: I would likely mention that terminator operations cannot be re-ordered.

689 ↗

(On Diff #277629)

Remove this now?

mlir/include/mlir/IR/Dominance.h

71 ↗

(On Diff #277631)

nit: Can you remove the double space sentences in this file?

89 ↗

(On Diff #277631)

nit: B, i.e.

97 ↗

(On Diff #277631)

Same here and below: B, i.e.

mlir/include/mlir/IR/RegionKindInterface.h

18 ↗

(On Diff #277631)

I don't think this one is necessary.

22 ↗

(On Diff #277631)

nit: Please use /// here.

mlir/include/mlir/IR/RegionKindInterface.td

22 ↗

(On Diff #277631)

There is a good doc for this in Interfaces.md, can you paste that here?

24 ↗

(On Diff #277631)

nit: You should be able to set the namespace(via cppNamespace) now.

40 ↗

(On Diff #277631)

nit: the strings are slightly misaligned here.

30 ↗

(On Diff #270965)

Unresolved?

mlir/lib/IR/Dominance.cpp

38 ↗

(On Diff #277631)

nit: Cache the end iterator of this loop.

39 ↗

(On Diff #277631)

nit: Spell out auto here.

231 ↗

(On Diff #277631)

nit: Drop else after return.

255 ↗

(On Diff #277631)

nit: Please drop the uses of mlir:: in this file.

257 ↗

(On Diff #277631)

nit: Can you define a static helper for this in this file?

static bool hasSSADominance(Operation *op, RegionKindInterface interface, unsigned regionNum) {
    return ancestor->isRegistered() &&
          (!kindInterface || kindInterface.hasSSADominance(aRegionNum));
}

303 ↗

(On Diff #277631)

Same here, drop else after return.

mlir/lib/IR/Verifier.cpp

183

nit: Cache the end iterator here.

184

nit: Spell out auto here.

198

nit: expected graph region?

254

nit: Spell out auto here.

271

nit: Cache the end iterator here, and can you inline the region variable below into its use?

mlir/lib/Transforms/CSE.cpp

174 ↗

(On Diff #277631)

Can you reword the second part of this into a TODO:?

175 ↗

(On Diff #277631)

nit: Drop the double space here.

177 ↗

(On Diff #277631)

nit: Drop trivial braces.

mlir/test/IR/parser.mlir

1248 ↗

(On Diff #277631)

Can you move the CHECK lines to non-IR lines to match the other tests? Ends up being much cleaner IMO.

mlir/test/IR/traits.mlir

373

nit: Please remove the CHECK lines that don't relate to what you are checking. This applies to the other tests as well. e.g. You don't really need to check return or the braces here.

382

nit: This comment seems wrong.

395

nit: Can you indent these expected lines? Same below.

409

nit: Please remove the explicit SSA value names, and please remove the unnecessary bits of this test.

472

nit: Indent the graph region.

mlir/test/lib/Dialect/Test/TestDialect.cpp

227

Unresolved here?

mlir/test/lib/Dialect/Test/TestOps.td

1173

nit: You could use a "" for the descriptions as well.

[stephenneuendorffer]

If there are no further comments, I'd like to commit this. @bondhugula @mehdi_amini Do you want to accept?

Note that there's a small amount of new text under "### Regions" where I tried to capture the understanding about how Region Arguments are shared with the Block Arguments of the entry block, but that operation arguments/return values are explicitly decoupled from region arguments and terminators. Also terminator arguments do not need to match the block arguments of their successor blocks. All of this is under the control of specific operations and may be arbitrarily defined.

mlir/docs/LangRef.md

553 ↗

(On Diff #270965)

I've reworded this.

677 ↗

(On Diff #275753)

Actually, there were a few other minor problems with this testcase, including the fact that it missed out on the fact that:

%1 = op(%1)

should be valid, along with:

%1 = op() { otherop(%1) }

I also turned this into another testcase.

[mehdi_amini]

LGTM

[bondhugula]

mlir/include/mlir/IR/Dominance.h

87–93 ↗

(On Diff #277998)

Reflow: I think you aren't using the whole width.

mlir/lib/IR/Dominance.cpp

27 ↗

(On Diff #277998)

These should be ///

43 ↗

(On Diff #277998)

Nit: This should be //.

263–265 ↗

(On Diff #277998)

Nit: reflow to use width.

mlir/lib/IR/Verifier.cpp

66

Nit: terminate comment with period.

[bondhugula]

Quick question: how do we know in printed IR if something is a graph region or an SSA one?

mlir/docs/LangRef.md

30 ↗

(On Diff #277998)

a Block Argument?

42–72 ↗

(On Diff #277998)

Nit: Reflow to use width.

[stephenneuendorffer]

In D80358#2153978, @bondhugula wrote:

Quick question: how do we know in printed IR if something is a graph region or an SSA one?

You don't. Syntactically, there is no distinction for unregistered ops. Unregistered ops are handled conservatively as graph regions, so they are allowed to violate SSA dominance. Passes that require dominance-order traversal (i.e. CSE) won't operate on regions inside unregistered ops.

mlir/docs/LangRef.md

30 ↗

(On Diff #277998)

I parse it as 'exactly one (Operation or Block Argument)', so I think it makes sense as is?

mlir/include/mlir/IR/OpBase.td

 }
 
 // PredOpTrait is an op trait implemented by way of a predicate on the op.
 class PredOpTrait<string descr, Pred pred> : OpTrait {
   string description = descr;
   Pred predicate = pred;
 }
 
+// Op contains regions where dominance is not a required property
+def DominanceFreeScope : NativeOpTrait<"DominanceFreeScope">;
 // Op defines an affine scope.
 def AffineScope : NativeOpTrait<"AffineScope">;
 // Op defines an automatic allocation scope.
 def AutomaticAllocationScope : NativeOpTrait<"AutomaticAllocationScope">;
 // Op supports operand broadcast behavior.
 def ResultsBroadcastableShape :
   NativeOpTrait<"ResultsBroadcastableShape">;
 // TODO: Alias of the above, remove post integrate.

mlir/include/mlir/IR/OpDefinition.h

public:
   static LogicalResult verifyTrait(Operation *op) {
     for (auto &region : op->getRegions())
       if (!region.isIsolatedFromAbove(op->getLoc()))
         return failure();
     return success();
   }
 };
 
+/// A trait of region-holding operations that do not require the
+/// SSA-Dominance property.  This is useful for scopes with semantics
+/// that doesn't correspond with the traditional notion of a CDFG.
+/// For more details, see `Traits.md#DominanceFreeScope`.
+template <typename ConcreteType>
+class DominanceFreeScope : public TraitBase<ConcreteType, DominanceFreeScope> {
+public:
+  static LogicalResult verifyTrait(Operation *op) {
+    static_assert(!ConcreteType::template hasTrait<ZeroRegion>(),
+                  "expected operation to have one or more regions");
+    return success();
+  }
+};
+
 /// A trait of region holding operations that defines a new scope for polyhedral
 /// optimization purposes. Any SSA values of 'index' type that either dominate
 /// such an operation or are used at the top-level of such an operation
 /// automatically become valid symbols for the polyhedral scope defined by that
 /// operation. For more details, see `Traits.md#AffineScope`.
 template <typename ConcreteType>
 class AffineScope : public TraitBase<ConcreteType, AffineScope> {
 public:

mlir/lib/IR/Verifier.cpp

 // are not mutable and can be checked at time of construction.
 //
 //===----------------------------------------------------------------------===//
 
 #include "mlir/IR/Verifier.h"
 #include "mlir/IR/Attributes.h"
 #include "mlir/IR/Dialect.h"
 #include "mlir/IR/Dominance.h"
 #include "mlir/IR/Operation.h"
+#include "mlir/IR/OpDefinition.h"
 #include "llvm/ADT/StringMap.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/PrettyStackTrace.h"
 #include "llvm/Support/Regex.h"
 
 using namespace mlir;
 
 namespace {

 
 private:
   /// Verify the given potentially nested region or block.
   LogicalResult verifyRegion(Region &region);
   LogicalResult verifyBlock(Block &block);
   LogicalResult verifyOperation(Operation &op);
 
   /// Verify the dominance within the given IR unit.
-  LogicalResult verifyDominance(Region &region);
+  LogicalResult verifyDominance(Region &region, bool inDominanceScope);
   LogicalResult verifyDominance(Operation &op);
+  LogicalResult verifyDominanceOfContainedRegions(Operation &op);
 
   /// Emit an error for the given block.
   InFlightDiagnostic emitError(Block &bb, const Twine &message) {
     // Take the location information for the first operation in the block.
     if (!bb.empty())
       return bb.front().emitError(message);
 
     // Worst case, fall back to using the parent's location.
     return mlir::emitError(bb.getParent()->getLoc(), message);
if (failed(verifyOperation(op)))
     return failure();
 
   // Since everything looks structurally ok to this point, we do a dominance
   // check for any nested regions. We do this as a second pass since malformed
   // CFG's can cause dominator analysis constructure to crash and we want the
   // verifier to be resilient to malformed code.
   DominanceInfo theDomInfo(&op);
   domInfo = &theDomInfo;
-  for (auto &region : op.getRegions())
-    if (failed(verifyDominance(region)))
-      return failure();
+  if(failed(verifyDominanceOfContainedRegions(op)))
 
   domInfo = nullptr;
   return success();
 }
 
 LogicalResult OperationVerifier::verifyRegion(Region &region) {
   if (region.empty())
     return success();
LogicalResult OperationVerifier::verifyOperation(Operation &op) {
   }
 
   // If we can get operation info for this, check the custom hook.
   auto *opInfo = op.getAbstractOperation();
   if (opInfo && failed(opInfo->verifyInvariants(&op)))
     return failure();
 
   // Verify that all child regions are ok.
   for (auto &region : op.getRegions())
     if (failed(verifyRegion(region)))
       return failure();
 
   // If this is a registered operation, there is nothing left to do.
   if (opInfo)
     return success();
 
   // Otherwise, verify that the parent dialect allows un-registered operations.
   auto dialectPrefix = op.getName().getDialect();
 
   // Check for an existing answer for the operation dialect.
   auto it = dialectAllowsUnknownOps.find(dialectPrefix);
   if (it == dialectAllowsUnknownOps.end()) {
     // If the operation dialect is registered, query it directly.
     if (auto *dialect = ctx->getRegisteredDialect(dialectPrefix))
       it = dialectAllowsUnknownOps
                .try_emplace(dialectPrefix, dialect->allowsUnknownOperations())
                .first;
     // Otherwise, unregistered dialects (when allowed by the context)
     // conservatively allow unknown operations.
     else {
       if (!op.getContext()->allowsUnregisteredDialects() && !op.getDialect())
         return op.emitOpError()
if (!it->second) {
     return op.emitError("unregistered operation '")
            << op.getName() << "' found in dialect ('" << dialectPrefix
            << "') that does not allow unknown operations";
   }
 
   return success();
 }
 
-LogicalResult OperationVerifier::verifyDominance(Region &region) {
+LogicalResult OperationVerifier::verifyDominance(Region &region, bool inDominanceScope) {
   // Verify the dominance of each of the held operations.
   for (auto &block : region)
-    // Dominance is only reachable inside reachable blocks.
-    if (domInfo->isReachableFromEntry(&block))
+    // Dominance is only meaningful inside reachable blocks.
+    if (inDominanceScope && domInfo->isReachableFromEntry(&block))
       for (auto &op : block) {
         if (failed(verifyDominance(op)))
           return failure();
       }
     else
       // Verify the dominance of each of the nested blocks within this
       // operation, even if the operation itself is not reachable.
       for (auto &op : block)
-        for (auto &region : op.getRegions())
-          if (failed(verifyDominance(region)))
-            return failure();
+        if (failed(verifyDominanceOfContainedRegions(op)))
   return success();
 }
 
 LogicalResult OperationVerifier::verifyDominance(Operation &op) {
   // Check that operands properly dominate this use.
   for (unsigned operandNo = 0, e = op.getNumOperands(); operandNo != e;
        ++operandNo) {
     auto operand = op.getOperand(operandNo);
     if (domInfo->properlyDominates(operand, &op))
       continue;
 
     auto diag = op.emitError("operand #")
                 << operandNo << " does not dominate this use";
     if (auto *useOp = operand.getDefiningOp())
       diag.attachNote(useOp->getLoc()) << "operand defined here";
     return failure();
   }
 
-  // Verify the dominance of each of the nested blocks within this operation.
+  if (failed(verifyDominanceOfContainedRegions(op))) {
+    return failure();
+  }
+
+  return success();
+}
+
+LogicalResult OperationVerifier::verifyDominanceOfContainedRegions(Operation &op) {
+  bool inDominanceScope = !op.hasTrait<OpTrait::DominanceFreeScope>();
   for (auto &region : op.getRegions())
-    if (failed(verifyDominance(region)))
+    if (failed(verifyDominance(region, inDominanceScope)))
       return failure();
-
   return success();
 }
 
 //===----------------------------------------------------------------------===//
 // Entrypoint
 //===----------------------------------------------------------------------===//
 
 /// Perform (potentially expensive) checks of invariants, used to detect
 /// compiler bugs.  On error, this reports the error through the MLIRContext and
 /// returns failure.
 LogicalResult mlir::verify(Operation *op) {
   return OperationVerifier(op->getContext()).verify(*op);
 }

mlir/test/IR/traits.mlir

 
 // -----
 
 func @succeededResultSizeAttr() {
   // CHECK: test.attr_sized_results
   %0:4 = "test.attr_sized_results"() {result_segment_sizes = dense<[0, 2, 1, 1]>: vector<4xi32>} : () -> (i32, i32, i32, i32)
   return
 }
+
+// -----
+
+func @succededDominanceFreeScope() -> () {
+  test.dominance_free_scope {
+  // %1 is not dominated by its definition.
+    %2:3 = "bar"(%1) : (i64) -> (i1,i1,i1) // CHECK: [[VAL2:%.*]]:3 = "bar"([[VAL3:%.*]]) : (i64) -> (i1, i1, i1)
+    br ^bb4     // CHECK:   br ^bb2
+^bb2:         // CHECK: ^bb1:   // pred: ^bb1
+    br ^bb2     // CHECK:   br ^bb1
+^bb4:         // CHECK: ^bb2:   // pred: ^bb0
+    %1 = "foo"() : ()->i64 // CHECK: [[VAL3]] = "foo"() : () -> i64
+  }
+  return
+}            // CHECK: }
+
+// -----
+
+func @illegalCDFGInsideDominanceFreeScope() -> () {
+  test.dominance_free_scope {
+    func @test() -> i1 {
+^bb1:
+// expected-error @+1 {{operand #0 does not dominate this use}}
+      %2:3 = "bar"(%1) : (i64) -> (i1,i1,i1)
+      br ^bb4
+^bb2:
+      br ^bb2
+^bb4:
+      %1 = "foo"() : ()->i64   // expected-note {{operand defined here}}
+    return %2#1 : i1
+    }
+     "terminator"() : () -> ()
+  }
+  return
+}            // CHECK: }

mlir/test/lib/Dialect/Test/TestDialect.cpp

 static void print(OpAsmPrinter &p, IsolatedRegionOp op) {
   p << "test.isolated_region ";
   p.printOperand(op.getOperand());
   p.shadowRegionArgs(op.region(), op.getOperand());
   p.printRegion(op.region(), /*printEntryBlockArgs=*/false);
 }
 
 //===----------------------------------------------------------------------===//
+// Test DominanceFreeScopeOp
+//===----------------------------------------------------------------------===//
+
+static ParseResult parseDominanceFreeScopeOp(OpAsmParser &parser,
+                                      OperationState &result) {
+  // Parse the body region, and reuse the operand info as the argument info.
+  Region *body = result.addRegion();
+  return parser.parseRegion(*body, /*arguments=*/{}, /*argTypes=*/{});
+}
+
+static void print(OpAsmPrinter &p, DominanceFreeScopeOp op) {
+  p << "test.dominance_free_scope ";
+  p.printRegion(op.region(), /*printEntryBlockArgs=*/false);
+}
+
+//===----------------------------------------------------------------------===//
 // Test AffineScopeOp
 //===----------------------------------------------------------------------===//
 
 static ParseResult parseAffineScopeOp(OpAsmParser &parser,
                                       OperationState &result) {
   // Parse the body region, and reuse the operand info as the argument info.
   Region *body = result.addRegion();
   return parser.parseRegion(*body, /*arguments=*/{}, /*argTypes=*/{});
 }
 
 static void print(OpAsmPrinter &p, AffineScopeOp op) {
   p << "test.affine_scope ";
   p.printRegion(op.region(), /*printEntryBlockArgs=*/false);
 }
 
 //===----------------------------------------------------------------------===//

mlir/test/lib/Dialect/Test/TestOps.td

def IsolatedRegionOp : TEST_Op<"isolated_region", [IsolatedFromAbove]> {
   }];
 
   let arguments = (ins Index);
   let regions = (region SizedRegion<1>:$region);
   let parser = [{ return ::parse$cppClass(parser, result); }];
   let printer = [{ return ::print(p, *this); }];
 }
 
+def DominanceFreeScopeOp : TEST_Op<"dominance_free_scope", [DominanceFreeScope]> {
+  let summary =  "dominance-free scope operation";
+  let description = [{
+    Test op that defines a new domainance-free scope.
+  }];
+
+  let regions = (region AnyRegion:$region);
+  let parser = [{ return ::parse$cppClass(parser, result); }];
+  let printer = [{ return ::print(p, *this); }];
+}
+
 def AffineScopeOp : TEST_Op<"affine_scope", [AffineScope]> {
   let summary =  "affine scope operation";
   let description = [{
     Test op that defines a new affine scope.
   }];
 
   let regions = (region SizedRegion<1>:$region);
   let parser = [{ return ::parse$cppClass(parser, result); }];