[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

65

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

76

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.

218–233

nit: are only in scope

220

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/

434

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.

551

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

629

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.

632

nit: Link to the documentation for this.

634

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?

639

nit: the potential successor blocks

641

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

647

nit: are treated as unreachable and may be

671

nit: Regions -> regions

mlir/include/mlir/IR/RegionKindInterface.h

2

This line looks like it is one character to short.

15

Please fix the header guard style.

18

Can you trim these?

27

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

30

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

mlir/include/mlir/IR/RegionKindInterface.td

28

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

28

Missing period at the end of the summary.

31

nit: Remove double space.

40

nit: Please use multi line string for this description.

48

Leftover debugging?

56

Please remove.

61

Please fix the header guard style.

mlir/include/mlir/Interfaces/CMakeLists.txt

7 ↗

(On Diff #270965)

Seems unrelated.

mlir/lib/IR/RegionKindInterface.cpp

19

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

263

Please remove the mlir:: from each of these.

[stephenneuendorffer]

Update after review changes

mlir/docs/Interfaces.md

232

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

mlir/docs/LangRef.md

68

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.

76

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

501–508

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?"

634

@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)

639

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

641

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

[rriddle]

mlir/docs/LangRef.md

641

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

267

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

68

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)

634

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

68

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.

634

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

267

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

[mehdi_amini]

mlir/docs/LangRef.md

501–508

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

501–508

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

45–67

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

267

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

267

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

267

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

267

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

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

513

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

575

in which case some other operation will execute

That does not read well to me right now.

624–636

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

654

typo: relatinoships

656

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

684

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

The concept of entry block is no longer a guarantee

[stephenneuendorffer]

mlir/docs/LangRef.md

513

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.

575

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?

624–636

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

684

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

mlir/include/mlir/IR/Dominance.h

63

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

68

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).

80

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

I don't understand what this means here.

219

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)

221

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).

351–357

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?

434

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

i.e. Branches

Shouldn't this be e.g. instead?

496

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.

[mehdi_amini]

mlir/docs/LangRef.md

684

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

80

I've rewritten this section.

219

Yes, I believe this is talking about affine maps.

221

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

351–357

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?

496

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

683

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

nit: Drop the newline here.

232

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

64

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

65

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

68

nit: Regions to match the tense of the others.

220

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

351–357

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).

356

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

434

typo: represent represents

434

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

513

nit: Can you remove the double space before The.

548

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

601

nit: Remove the indent of this code snippet.

613

nitL Double space here.

627

nit: Double space here.

640

typo: ot.

660

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

672

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

687

Remove this now?

mlir/include/mlir/IR/Dominance.h

71–73

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

87

nit: B, i.e.

94–95

Same here and below: B, i.e.

mlir/include/mlir/IR/RegionKindInterface.h

19

I don't think this one is necessary.

23

nit: Please use /// here.

mlir/include/mlir/IR/RegionKindInterface.td

23

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

25

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

31

Unresolved?

41

nit: the strings are slightly misaligned here.

mlir/lib/IR/Dominance.cpp

46

nit: Cache the end iterator of this loop.

47

nit: Spell out auto here.

240

nit: Drop else after return.

262

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

264

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));
}

308

Same here, drop else after return.

mlir/lib/IR/Verifier.cpp

187–205

nit: Cache the end iterator here.

188

nit: Spell out auto here.

202

nit: expected graph region?

280

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

282

nit: Spell out auto here.

mlir/lib/Transforms/CSE.cpp

174

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

175

nit: Drop the double space here.

177

nit: Drop trivial braces.

mlir/test/IR/parser.mlir

1249–1262

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

406

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.

415

nit: This comment seems wrong.

428

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

442

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

505

nit: Indent the graph region.

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

263

Unresolved here?

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

1196

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

647

I've reworded this.

683

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

86–92

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

mlir/lib/IR/Dominance.cpp

27

These should be ///

43

Nit: This should be //.

262–264

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

65

a Block Argument?

77–107

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

65

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

mlir/docs/Interfaces.md

def ExampleOpInterface : OpInterface<"ExampleOpInterface"> {
   let methods = [
     InterfaceMethod<
       "Get the number of inputs for the current operation.",
       "unsigned", "getNumInputs"
     >,
   ];
 }
 ```
+
+#### Operation Interface List
+
+MLIR includes standard interfaces providing functionality that is
+likely to be common across many different operations. Below is a list
+of some key interfaces that may be used directly by any dialect. The
+format of the header for each interface section goes as follows:
+
+*   `Interface class name`
+    -   (`C++ class` -- `ODS class`(if applicable))
+
+##### CallInterfaces
+
+*   `CallOpInterface` - Used to represent operations like 'call'
+    -   `CallInterfaceCallable getCallableForCallee()`
+*   `CallableOpInterface` - Used to represent the target callee of call.
+    -   `Region * getCallableRegion()`
+    -   `ArrayRef<Type> getCallableResults()`
+
+##### RegionKindInterfaces
+
+*   `RegionKindInterface` - Used to describe the abstract semantics of regions.
+     - `RegionKind getRegionKind(unsigned index)` - Return the kind of the region with the given index inside this operation.
+         - RegionKind::Graph - represents a graph region without control flow semantics
+         - RegionKind::SSACFG - represents an [SSA-style control flow](LangRef.md#modeling-control-flow) region with basic blocks and reachability
+     - `hasSSADominance(unsigned index)` - Return true if the region with the given index inside this operation requires dominance.

mlir/docs/LangRef.md

 # MLIR Language Reference
 
 MLIR (Multi-Level IR) is a compiler intermediate representation with
 similarities to traditional three-address SSA representations (like
 [LLVM IR](http://llvm.org/docs/LangRef.html) or
 [SIL](https://github.com/apple/swift/blob/master/docs/SIL.rst)), but which
 introduces notions from polyhedral loop optimization as first-class concepts.
 This hybrid design is optimized to represent, analyze, and transform high level
 dataflow graphs as well as target-specific code generated for high performance
 data parallel systems. Beyond its representational capabilities, its single
 continuous design provides a framework to lower from dataflow graphs to
 high-performance target-specific code.
 
-This document defines and describes the key concepts in MLIR, and is intended to
-be a dry reference document - the [rationale documentation](Rationale/Rationale.md),
-[glossary](../getting_started/Glossary.md), and other content are hosted elsewhere.
+This document defines and describes the key concepts in MLIR, and is intended
+to be a dry reference document - the [rationale
+documentation](Rationale/Rationale.md),
+[glossary](../getting_started/Glossary.md), and other content are hosted
+elsewhere.
 
 MLIR is designed to be used in three different forms: a human-readable textual
 form suitable for debugging, an in-memory form suitable for programmatic
-transformations and analysis, and a compact serialized form suitable for storage
-and transport. The different forms all describe the same semantic content. This
-document describes the human-readable textual form.
+transformations and analysis, and a compact serialized form suitable for
+storage and transport. The different forms all describe the same semantic
+content. This document describes the human-readable textual form.
 
 [TOC]
 
 ## High-Level Structure
 
-MLIR is an
+MLIR is fundamentally based on a graph-like data structure of nodes, called
+*Operations*, and edges, called *Values*. Each Value is the result of exactly
+one Operation or Block Argument, and has a *Value Type* defined by the [type
+system](#type-system).  [Operations](#operations) are contained in
+[Blocks](#blocks) and Blocks are contained in [Regions](#regions). Operations
+are also ordered within their containing block and Blocks are ordered in their
+containing region, although this order may or may not be semantically
+meaningful in a given [kind of region](Interfaces.md#regionkindinterface)).
+Operations may also contain regions, enabling hierarchical structures to be
+represented.
+
+Operations can represent many different concepts, from higher-level concepts
+like function definitions, function calls, buffer allocations, view or slices
+of buffers, and process creation, to lower-level concepts like
+target-independent arithmetic, target-specific instructions, configuration
+registers, and logic gates. These different concepts are represented by
+different operations in MLIR and the set of operations usable in MLIR can be
+arbitrarily extended.
+
+MLIR also provides an extensible framework for transformations on operations,
+using familiar concepts of compiler [Passes](Passes.md). Enabling an arbitrary
+set of passes on an arbitrary set of operations results in a significant
+scaling challenge, since each transformation must potentially take into
+account the semantics of any operation. MLIR addresses this complexity by
+allowing operation semantics to be described abstractly using
+[Traits](Traits.md) and [Interfaces](Interfaces.md), enabling transformations
+to operate on operations more generically.  Traits often describe verification
+constraints on valid IR, enabling complex invariants to be captured and
+checked. (see
+[docs/Tutorials/Toy/Ch-2/#op-vs-operation-using-mlir-operations])
+
+One obvious application of MLIR is to represent an
 [SSA-based](https://en.wikipedia.org/wiki/Static_single_assignment_form) IR,
-which means that values are defined before use and have scope defined by their
-dominance relations. Operations may produce zero or more results, and each is a
-distinct SSA value with its own type defined by the [type system](#type-system).
-
-The unit of code in MLIR is an [Operation](#operations). Operations allow for
-representing many different concepts: allocating buffers, producing views to
-transform them, target-independent arithmetic, target-specific operations, and
-even arbitrary user-defined high-level operations including the
-[Module](#module) and [Function](#functions) operations. Operations may contain
-[Regions](#regions) that represent a Control Flow Graph (CFG) of
-[Blocks](#blocks), that contain operations and end with a
-[terminator operation](#terminator-operations) (like branches).
+like the LLVM core IR, with appropriate choice of Operation Types to define
+[Modules](#module), [Functions](#functions), Branches, Allocations, and
+verification constraints to ensure the SSA Dominance property. MLIR includes a
+'standard' dialect which defines just such structures. However, MLIR is
+intended to be general enough to represent other compiler-like data
+structures, such as Abstract Syntax Trees in a language frontend, generated
+instructions in a target-specific backend, or circuits in a High-Level
+Synthesis tool.
 
 Here's an example of an MLIR module:
 
 ```mlir
 // Compute A*B using an implementation of multiply kernel and print the
 // result using a TensorFlow op. The dimensions of A and B are partially
 // known. The shapes are assumed to match.
 func @mul(%A: tensor<100x?xf32>, %B: tensor<?x50xf32>) -> (tensor<100x50xf32>) {
   // Compute the inner dimension of %A using the dim operation.
   %n = dim %A, 1 : tensor<100x?xf32>
 
   // Allocate addressable "buffers" and copy tensors %A and %B into them.
   %A_m = alloc(%n) : memref<100x?xf32>
   tensor_store %A to %A_m : memref<100x?xf32>
 
   %B_m = alloc(%n) : memref<?x50xf32>
   tensor_store %B to %B_m : memref<?x50xf32>
 
   // Call function @multiply passing memrefs as arguments,
   // and getting returned the result of the multiplication.
   %C_m = call @multiply(%A_m, %B_m)
           : (memref<100x?xf32>, memref<?x50xf32>) -> (memref<100x50xf32>)
 
   dealloc %A_m : memref<100x?xf32>
   dealloc %B_m : memref<?x50xf32>
 
   // Load the buffer data into a higher level "tensor" value.
   %C = tensor_load %C_m : memref<100x50xf32>
   dealloc %C_m : memref<100x50xf32>
 
   // Call TensorFlow built-in function to print the result tensor.
   "tf.Print"(%C){message: "mul result"}
                   : (tensor<100x50xf32) -> (tensor<100x50xf32>)
 
   return %C : tensor<100x50xf32>
 }
 
 // A function that multiplies two memrefs and returns the result.
 func @multiply(%A: memref<100x?xf32>, %B: memref<?x50xf32>)
           -> (memref<100x50xf32>)  {
   // Compute the inner dimension of %A.
   %n = dim %A, 1 : memref<100x?xf32>
 
   // Allocate memory for the multiplication result.
   %C = alloc() : memref<100x50xf32>
func @multiply(%A: memref<100x?xf32>, %B: memref<?x50xf32>)
   }
   return %C : memref<100x50xf32>
 }
 ```
 
 ## Notation
 
 MLIR has a simple and unambiguous grammar, allowing it to reliably round-trip
-through a textual form. This is important for development of the compiler - e.g.
-for understanding the state of code as it is being transformed and writing test
-cases.
+through a textual form. This is important for development of the compiler -
+e.g.  for understanding the state of code as it is being transformed and
+writing test cases.
 
 This document describes the grammar using
 [Extended Backus-Naur Form (EBNF)](https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form).
 
 This is the EBNF grammar used in this document, presented in yellow boxes.
 
 ```
 alternation ::= expr0 | expr1 | expr2  // Either expr0 or expr1 or expr2.

 ### Identifiers and keywords
 
 Syntax:
 
 ```
 // Identifiers
 bare-id ::= (letter|[_]) (letter|digit|[_$.])*
 bare-id-list ::= bare-id (`,` bare-id)*
-ssa-id ::= `%` suffix-id
+value-id ::= `%` suffix-id
 suffix-id ::= (digit+ | ((letter|id-punct) (letter|id-punct|digit)*))
 
 symbol-ref-id ::= `@` (suffix-id | string-literal)
-ssa-id-list ::= ssa-id (`,` ssa-id)*
+value-id-list ::= value-id (`,` value-id)*
 
-// Uses of an SSA value, e.g. in an operand list to an operation.
-ssa-use ::= ssa-id
-ssa-use-list ::= ssa-use (`,` ssa-use)*
+// Uses of value, e.g. in an operand list to an operation.
+value-use ::= value-id
+value-use-list ::= value-use (`,` value-use)*
 ```
 
-Identifiers name entities such as SSA values, types and functions, and are
+Identifiers name entities such as values, types and functions, and are
 chosen by the writer of MLIR code. Identifiers may be descriptive (e.g.
 `%batch_size`, `@matmul`), or may be non-descriptive when they are
-auto-generated (e.g. `%23`, `@func42`). Identifier names for SSA values may be
+auto-generated (e.g. `%23`, `@func42`). Identifier names for values may be
 used in an MLIR text file but are not persisted as part of the IR - the printer
 will give them anonymous names like `%42`.
 
 MLIR guarantees identifiers never collide with keywords by prefixing identifiers
 with a sigil (e.g. `%`, `#`, `@`, `^`, `!`). In certain unambiguous contexts
 (e.g. affine expressions), identifiers are not prefixed, for brevity. New
 keywords may be added to future versions of MLIR without danger of collision
 with existing identifiers.
 
-The scope of SSA values is defined based on the standard definition of
-[dominance](https://en.wikipedia.org/wiki/Dominator_\(graph_theory\)). Argument
-identifiers in mapping functions are in scope for the mapping body. Function
-identifiers and mapping identifiers are visible across the entire module.
+Value identifiers are only [in scope](#value-scoping) for the (nested)
+region in which they are defined and cannot be accessed or referenced
+outside of that region. Argument identifiers in mapping functions are
+in scope for the mapping body. Particular operations may further limit
+which identifiers are in scope in their regions. For instance, the
+scope of values in a region with [SSA control flow
+semantics](#control-flow-and-ssacfg-regions) is constrained according
+to the standard definition of [SSA
+dominance](https://en.wikipedia.org/wiki/Dominator_\(graph_theory\)). Another
+example is the [IsolatedFromAbove trait](Traits.md#isolatedfromabove),
+which restricts directly accessing values defined in containing
+regions.
+
+Function identifiers and mapping identifiers are associated with
+[Symbols](SymbolsAndSymbolTables) and have scoping rules dependent on
+symbol attributes.
 
 ## Dialects
 
 Dialects are the mechanism by which to engage with and extend the MLIR
 ecosystem. They allow for defining new [operations](#operations), as well as
 [attributes](#attributes) and [types](#type-system). Each dialect is given a
 unique `namespace` that is prefixed to each defined attribute/operation/type.
 For example, the [Affine dialect](Dialects/Affine.md) defines the namespace:

 *   [Vector dialect](Dialects/Vector.md)
 
 ### Target specific operations
 
 Dialects provide a modular way in which targets can expose target-specific
 operations directly through to MLIR. As an example, some targets go through
 LLVM. LLVM has a rich set of intrinsics for certain target-independent
 operations (e.g. addition with overflow check) as well as providing access to
-target-specific operations for the targets it supports (e.g. vector permutation
-operations). LLVM intrinsics in MLIR are represented via operations that start
-with an "llvm." name.
+target-specific operations for the targets it supports (e.g. vector
+permutation operations). LLVM intrinsics in MLIR are represented via
+operations that start with an "llvm." name.
 
 Example:
 
 ```mlir
 // LLVM: %x = call {i16, i1} @llvm.sadd.with.overflow.i16(i16 %a, i16 %b)
 %x:2 = "llvm.sadd.with.overflow.i16"(%a, %b) : (i16, i16) -> (i16, i1)
 ```
 
 These operations only work when targeting LLVM as a backend (e.g. for CPUs and
 GPUs), and are required to align with the LLVM definition of these intrinsics.
 
 ## Operations
 
 Syntax:
 
 ```
 operation         ::= op-result-list? (generic-operation | custom-operation)
                       trailing-location?
-generic-operation ::= string-literal `(` ssa-use-list? `)`  successor-list?
+generic-operation ::= string-literal `(` value-use-list? `)`  successor-list?
                       (`(` region-list `)`)? attribute-dict? `:` function-type
 custom-operation  ::= bare-id custom-operation-format
 op-result-list    ::= op-result (`,` op-result)* `=`
-op-result         ::= ssa-id (`:` integer-literal)
+op-result         ::= value-id (`:` integer-literal)
 successor-list    ::= successor (`,` successor)*
 successor         ::= caret-id (`:` bb-arg-list)?
 region-list       ::= region (`,` region)*
 trailing-location ::= (`loc` `(` location `)`)?
 ```
 
-MLIR introduces a uniform concept called _operations_ to enable describing many
-different levels of abstractions and computations. Operations in MLIR are fully
-extensible (there is no fixed list of operations) and have application-specific
-semantics. For example, MLIR supports
-[target-independent operations](Dialects/Standard.md#memory-operations),
-[affine operations](Dialects/Affine.md), and
-[target-specific machine operations](#target-specific-operations).
+MLIR introduces a uniform concept called _operations_ to enable describing
+many different levels of abstractions and computations. Operations in MLIR are
+fully extensible (there is no fixed list of operations) and have
+application-specific semantics. For example, MLIR supports [target-independent
+operations](Dialects/Standard.md#memory-operations), [affine
+operations](Dialects/Affine.md), and [target-specific machine
+operations](#target-specific-operations).
 
 The internal representation of an operation is simple: an operation is
 identified by a unique string (e.g. `dim`, `tf.Conv2d`, `x86.repmovsb`,
-`ppc.eieio`, etc), can return zero or more results, take zero or more SSA
+`ppc.eieio`, etc), can return zero or more results, take zero or more
 operands, may have zero or more attributes, may have zero or more successors,
 and zero or more enclosed [regions](#regions). The generic printing form
 includes all these elements literally, with a function type to indicate the
 types of the results and operands.
 
 Example:
 
 ```mlir

 ```
 
 ### Module
 
 ```
 module ::= `module` symbol-ref-id? (`attributes` attribute-dict)? region
 ```
 
-An MLIR Module represents a top-level container operation. It contains
-a single region containing a single block which can contain any
-operations.  Operations within this region must not implicitly capture
-values defined outside the module.  Modules have an optional symbol
-name that can be used to refer to them in operations.
+An MLIR Module represents a top-level container operation. It contains a single
+[SSACFG region](#control-flow-and-ssacfg-regions) containing a single block
+which can contain any operations. Operations within this region cannot
+implicitly capture values defined outside the module, i.e. Modules are
+[IsolatedFromAbove](Traits.md#isolatedfromabove). Modules have an optional
+[symbol name](SymbolsAndSymbolTables.md) which can be used to refer to them in
+operations.
 
 ### Functions
 
-An MLIR Function is an operation with a name containing one [region](#regions).
-The region of a function is not allowed to implicitly capture values defined
-outside of the function, and all external references must use function arguments
-or attributes that establish a symbolic connection (e.g. symbols referenced by
-name via a string attribute like [SymbolRefAttr](#symbol-reference-attribute)):
+An MLIR Function is an operation with a name containing a single [SSACFG
+region)[#control-flow-and-ssacfg-regions].  Operations within this region
+cannot implicitly capture values defined outside of the function,
+i.e. Functions are [IsolatedFromAbove](Traits.md#isolatedfromabove).  All
+external references must use function arguments or attributes that establish a
+symbolic connection (e.g. symbols referenced by name via a string attribute
+like [SymbolRefAttr](#symbol-reference-attribute)):
 
 ```
 function ::= `func` function-signature function-attributes? function-body?
 
 function-signature ::= symbol-ref-id `(` argument-list `)`
                        (`->` function-result-list)?
 
 argument-list ::= (named-argument (`,` named-argument)*) | /*empty*/
 argument-list ::= (type attribute-dict? (`,` type attribute-dict?)*) | /*empty*/
-named-argument ::= ssa-id `:` type attribute-dict?
+named-argument ::= value-id `:` type attribute-dict?
 
 function-result-list ::= function-result-list-parens
                        | non-function-type
 function-result-list-parens ::= `(` `)`
                               | `(` function-result-list-no-parens `)`
 function-result-list-no-parens ::= function-result (`,` function-result)*
 function-result ::= type attribute-dict?
 
 function-attributes ::= `attributes` attribute-dict
 function-body ::= region
 ```
 
-An external function declaration (used when referring to a function declared in
-some other module) has no body. While the MLIR textual form provides a nice
-inline syntax for function arguments, they are internally represented as "block
-arguments" to the first block in the region.
+An external function declaration (used when referring to a function declared
+in some other module) has no body. While the MLIR textual form provides a nice
+inline syntax for function arguments, they are internally represented as
+"block arguments" to the first block in the region.
 
-Only dialect attribute names may be specified in the attribute dictionaries for
-function arguments, results, or the function itself.
+Only dialect attribute names may be specified in the attribute dictionaries
+for function arguments, results, or the function itself.
 
 Examples:
 
 ```mlir
 // External function definitions.
 func @abort()
 func @scribble(i32, i64, memref<? x 128 x f32, #layout_map0>) -> f64
 

 
 Syntax:
 
 ```
 block           ::= block-label operation+
 block-label     ::= block-id block-arg-list? `:`
 block-id        ::= caret-id
 caret-id        ::= `^` suffix-id
-ssa-id-and-type ::= ssa-id `:` type
+value-id-and-type ::= value-id `:` type
 
 // Non-empty list of names and types.
-ssa-id-and-type-list ::= ssa-id-and-type (`,` ssa-id-and-type)*
+value-id-and-type-list ::= value-id-and-type (`,` value-id-and-type)*
 
-block-arg-list ::= `(` ssa-id-and-type-list? `)`
+block-arg-list ::= `(` value-id-and-type-list? `)`
 ```
 
-A [block](https://en.wikipedia.org/wiki/Basic_block) is a sequential list of
-operations without control flow (a call or entering an op's region is not
-considered control flow for this purpose) that are executed from top to bottom.
-The last operation in a block is a
-[terminator operation](#terminator-operations), which ends the block.
-
-Blocks in MLIR take a list of block arguments, which represent SSA PHI nodes in
-a functional notation. The arguments are defined by the block, and values are
-provided for these block arguments by branches that go to the block.
+A *Block* is an ordered list of operations, concluding with a single
+[terminator operation](#terminator-operations). In [SSACFG
+regions](#control-flow-and-ssacfg-regions), each block represents a compiler
+[basic block] (https://en.wikipedia.org/wiki/Basic_block) where instructions
+inside the block are executed in order and terminator operations implement
+control flow branches between basic blocks.
+
+Blocks in MLIR take a list of block arguments, notated in a function-like
+way. Block arguments are bound to values specified by the semantics of
+individual operations. Block arguments of the entry block of a region are also
+arguments to the region and the values bound to these arguments are determined
+by the semantics of the containing operation. Block arguments of other blocks
+are determined by the semantics of terminator operations, e.g. Branches, which
+have the block as a successor. In regions with [control
+flow](#control-flow-and-ssacfg-regions), MLIR leverages this structure to
+implicitly represent the passage of control-flow dependent values without the
+complex nuances of PHI nodes in traditional SSA representations. Note that
+values which are not control-flow dependent can be referenced directly and do
+not need to be passed through block arguments.
 
 Here is a simple example function showing branches, returns, and block
 arguments:
 
 ```mlir
 func @simple(i64, i1) -> i64 {
 ^bb0(%a: i64, %cond: i1): // Code dominated by ^bb0 may refer to %a
   cond_br %cond, ^bb1, ^bb2
 
 ^bb1:
   br ^bb3(%a: i64)    // Branch passes %a as the argument
 
 ^bb2:
   %b = addi %a, %a : i64
   br ^bb3(%b: i64)    // Branch passes %b as the argument
 
 // ^bb3 receives an argument, named %c, from predecessors
-// and passes it on to bb4 twice.
+// and passes it on to bb4 along with %a. %a is referenced
+// directly from its defining operation and is not passed through
+// an argument of ^bb3.
 ^bb3(%c: i64):
-  br ^bb4(%c, %c : i64, i64)
+  br ^bb4(%c, %a : i64, i64)
 
 ^bb4(%d : i64, %e : i64):
   %0 = addi %d, %e : i64
-  return %0 : i64
+  return %0 : i64   // Return is also a terminator.
 }
 ```
 
-**Context:** The "block argument" representation eliminates a number of special
-cases from the IR compared to traditional "PHI nodes are operations" SSA IRs
-(like LLVM). For example, the
-[parallel copy semantics](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.524.5461&rep=rep1&type=pdf)
-of SSA is immediately apparent, and function arguments are no longer a special
-case: they become arguments to the entry block
-[[more rationale](Rationale/Rationale.md#block-arguments-vs-phi-nodes)].
+**Context:** The "block argument" representation eliminates a number
+of special cases from the IR compared to traditional "PHI nodes are
+operations" SSA IRs (like LLVM). For example, the [parallel copy
+semantics](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.524.5461&rep=rep1&type=pdf)
+of SSA is immediately apparent, and function arguments are no longer a
+special case: they become arguments to the entry block [[more
+rationale](Rationale/Rationale.md#block-arguments-vs-phi-nodes)]. Blocks
+are also a fundamental concept that cannot be represented by
+operations because values defined in an operation cannot be accessed
+outside the operation.
 
 ## Regions
 
 ### Definition
 
-A region is a CFG of MLIR [Blocks](#blocks). Regions serve to group semantically
-connected blocks, where the semantics is not imposed by the IR. Instead, the
-containing operation defines the semantics of the regions it contains. Regions
-do not have a name or an address, only the blocks contained in a region do.
-Regions are meaningless outside of the containing entity and have no type or
-attributes.
-
-The first block in the region cannot be a successor of any other block. The
-syntax for the region is as follows:
+A region is an ordered list of MLIR [Blocks](#blocks). The semantics within a
+region is not imposed by the IR. Instead, the containing operation defines the
+semantics of the regions it contains. MLIR currently defines two kinds of
+regions: [SSACFG regions](#control-flow-and-ssacfg-regions), which describe
+control flow between blocks, and [Graph regions](#graph-regions), which do not
+require control flow between block. The kinds of regions within an operation
+are described using the
+[RegionKindInterface](Interfaces.md#regionkindinterface).
+
+Regions do not have a name or an address, only the blocks contained in a
+region do. Regions must be contained within operations and have no type or
+attributes. The first block in the region is a special block called the 'entry
+block'. The arguments to the entry block are also the arguments of the region
+itself. The entry block cannot be listed as a successor of any other
+block. The syntax for a region is as follows:
 
 ```
 region ::= `{` block* `}`
 ```
 
-The function body is an example of a region: it consists of a CFG of blocks and
-has additional semantic restrictions that other types of regions may not have
-(block terminators must either branch to a different block, or return from a
-function where the types of the `return` arguments must match the result types
-of the function signature).
-
-### Control and Value Scoping
-
-Regions provide nested control isolation: it is impossible to branch to a block
-within a region from outside it or to branch from within a region to a block
-outside it. Similarly, it provides a natural scoping for value visibility: SSA
-values defined in a region don't escape to the enclosing region, if any. By
-default, a region can reference values defined outside of the region whenever it
-would have been legal to use them as operands to the enclosing operation.
+A function body is an example of a region: it consists of a CFG of blocks and
+has additional semantic restrictions that other types of regions may not have.
+For example, in a function body, block terminators must either branch to a
+different block, or return from a function where the types of the `return`
+arguments must match the result types of the function signature.  Similarly,
+the function arguments must match the types and count of the region arguments.
+In general, operations with regions can define these correspondances
+arbitrarily.
+
+### Value Scoping
+
+Regions provide hierarchical encapsulation of programs: it is impossible to
+reference, i.e. branch to, a block which is not in the same region as the
+source of the reference, i.e. a terminator operation. Similarly, regions
+provides a natural scoping for value visibility: values defined in a region
+don't escape to the enclosing region, if any. By default, operations inside a
+region can reference values defined outside of the region whenever it would
+have been legal for operands of the enclosing operation to reference those
+values, but this can be restricted using traits, such as
+[OpTrait::IsolatedFromAbove](Traits.md#isolatedfromabove), or a custom
+verifier.
 
 Example:
 
 ```mlir
-func @accelerator_compute(i64, i1) -> i64 {
+  "any_op"(%a) ({ // if %a is in-scope in the containing region...
+   // then %a is in-scope here too.
+    %new_value = "another_op"(%a) : (i64) -> (i64)
+  }) : (i64) -> (i64)
+```
+
+MLIR defines a generalized 'hierarchical dominance' concept that operates
+across hierarchy and defines whether a value is 'in scope' and can be used by
+a particular operation. Whether a value can be used by another operation in
+the same region is defined by the kind of region. A value defined in a region
+can be used by an operation which has a parent in the same region, if and only
+if the parent could use the value. A value defined by an argument to a region
+can always be used by any operation deeply contained in the region. A value
+defined in a region can never be used outside of the region.
+
+### Control Flow and SSACFG Regions
+
+In MLIR, control flow semantics of a region is indicated by
+[RegionKind::SSACFG](Interfaces.md#regionkindinterface).  Informally, these
+regions support semantics where operations in a region 'execute
+sequentially'. Before an operation executes, its operands have well-defined
+values. After an operation executes, the operands have the same values and
+results also have well-defined values. After an operation executes, the next
+operation in the block executes until the operation is the terminator operation
+at the end of a block, in which case some other operation will execute. The
+determination of the next instruction to execute is the 'passing of control
+flow'.
+
+In general, when control flow is passed to an operation, MLIR does not
+restrict when control flow enters or exits the regions contained in that
+operation. However, when control flow enters a region, it always begins in the
+first block of the region, called the *entry* block.  Terminator operations
+ending each block represent control flow by explicitly specifying the
+successor blocks of the block. 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 control back to the containing operation. Within
+these restrictions, the particular semantics of terminator operations is
+determined by the specific dialect operations involved. Blocks (other than the
+entry block) that are not listed as a successor of a terminator operation are
+defined to be unreachable and can be removed without affecting the semantics
+of the containing operation.
+
+Although control flow always enters a region through the entry block, control
+flow may exit a region through any block with an appropriate terminator. The
+standard dialect leverages this capability to define operations with
+Single-Entry-Multiple-Exit (SEME) regions, possibly flowing through different
+blocks in the region and exiting through any block with a `return`
+operation. This behavior is similar to that of a function body in most
+programming languages. In addition, control flow may also not reach the end of
+a block or region, for example if a function call does not return.
+
+Example:
+
+```mlir
+func @accelerator_compute(i64, i1) -> i64 { // An SSACFG region
 ^bb0(%a: i64, %cond: i1): // Code dominated by ^bb0 may refer to %a
   cond_br %cond, ^bb1, ^bb2
 
 ^bb1:
   // This def for %value does not dominate ^bb2
   %value = "op.convert"(%a) : (i64) -> i64
   br ^bb3(%a: i64)    // Branch passes %a as the argument
 
 ^bb2:
-  "accelerator.launch"() {
+  accelerator.launch() { // An SSACFG region
     ^bb0:
       // Region of code nested under "accelerator.launch", it can reference %a but
       // not %value.
       %new_value = "accelerator.do_something"(%a) : (i64) -> ()
   }
   // %new_value cannot be referenced outside of the region
 
 ^bb3:
   ...
 }
 ```
 
-This can be further restricted using the custom verifier associated with the
-enclosing operation, for example, disallowing references to values defined
-outside the region completely.
-
-### Control Flow
-
-Regions are Single-Entry-Multiple-Exit (SEME). This means that control can only
-flow into the first block of the region, but can flow out of the region at the
-end of any of the contained blocks (This behavior is similar to that of a
-function body in most programming languages). A terminator of a block within a
-region may transfer the control flow to another block in this region, or return
-it to the immediately enclosing op. The semantics of the enclosing op defines
-where the control flow is transmitted next. It may, for example, enter a region
-of the same op, including the same region that returned the control flow.
-
-The enclosing operation determines the way in which control is transmitted into
-the entry block of a Region. The successor to a Region’s exit points may not
-necessarily exist: for example a call to a function that does not return.
-Concurrent or asynchronous execution of Regions is unspecified. Operations may
-define specific rules of execution, e.g. sequential loops or switch cases.
-
-A Region may also enter another region within the enclosing operation. If an
-operation has multiple regions, the semantics of the operation defines into
-which regions the control flows and in which order, if any. An operation may
-transmit control into Regions that were specified in other operations, in
-particular those that defined the values the given operation uses. Thus, such
-operations can be treated opaquely in the enclosing control flow graph,
-providing a level of control flow isolation similar to that of the call
-operation.
+#### Operations with Multiple Regions
+
+An operation containing multiple regions also completely determines the
+semantics of those regions. In particular, when control flow is passed to an
+operation, it may transfer control flow to any contained region. When control
+flow exits a region and is returned to the containing operation, the
+containing operation may pass control flow to any region in the same
+operation. An operation may also pass control flow to multiple contained
+regions concurrently. An operation may also pass control flow into regions
+that were specified in other operations, in particular those that defined the
+values or symbols the given operation uses as in a call operation. This
+passage of control is generally independent of passage of control flow through
+the basic blocks of the containing region.
 
 #### Closure
 
 Regions allow defining an operation that creates a closure, for example by
 “boxing” the body of the region into a value they produce. It remains up to the
 operation to define its semantics. Note that if an operation triggers
 asynchronous execution of the region, it is under the responsibility of the
 operation caller to wait for the region to be executed guaranteeing that any
 directly used values remain live.
 
+### Graph Regions
+
+In MLIR, graph-like semantics in a region is indicated by
+[RegionKind::Graph](Interfaces.md#regionkindinterface). Graph regions are
+appropriate for concurrent semantics without control flow, or for modeling
+generic directed graph data structures. Graph regions are appropriate for
+representing cyclic relationships between coupled values where there is no
+fundamental order to the relationships. For instance, operations in a graph
+region may represent independent threads of control with values representing
+streams of data. As usual in MLIR, the particular semantics of a region is
+completely determined by its containing operation. Graph regions may only
+contain a single basic block (the entry block).
+
+**Rationale:** Currently graph regions are arbitrarily limited to a single
+basic block, although there is no particular semantic reason for this
+limitation. This limitation has been added to make it easier to stabilize the
+pass infrastructure and commonly used passes for processing graph regions to
+properly handle feedback loops. Multi-block regions may be allowed in the
+future if use cases that require it arise.
+
+In graph regions, MLIR operations naturally represent nodes, while each MLIR
+value represents a multi-edge connecting a single source node and multiple
+destination nodes. All values defined in the region as results of operations
+are in scope within the region and can be accessed by any other operation in
+the region. In graph regions, the order of operations within a block and the
+order of blocks in a region is not semantically meaningful and non-terminator
+operations may be freely reordered, for instance, by canonicalization. Other
+kinds of graphs, such as graphs with multiple source nodes and multiple
+destination nodes, can also be represented by representing graph edges as MLIR
+operations.
+
+Note that cycles can occur within a single block in a graph region, or between
+basic blocks.
+
+```mlir
+"test.graph_region"() ({ // A Graph region
+  %1 = "op1"(%1, %3) : (i32, i32) -> (i32)  // OK: %1, %3 allowed here
+  %2 = "test.ssacfg_region"() ({
+   %5 = "op2"(%1, %2, %3, %4) : (i32, i32, i32, i32) -> (i32) // OK: %1, %2, %3, %4 all defined in the containing region
+  }) : () -> (i32)
+  %3 = "op2"(%1, %4) : (i32, i32) -> (i32)  // OK: %4 allowed here
+  %4 = "op3"(%1) : (i32) -> (i32)
+}) : () -> ()
+```
+
 ### Arguments and Results
 
 The arguments of the first block of a region are treated as arguments of the
 region. The source of these arguments is defined by the semantics of the parent
 operation. They may correspond to some of the values the operation itself uses.
 
 Regions produce a (possibly empty) list of values. The operation semantics
 defines the relation between the region results and the operation results.
 
 ## Type System
 
-Each SSA value in MLIR has a type defined by the type system below. There are a
+Each value in MLIR has a type defined by the type system below. There are a
 number of primitive types (like integers) and also aggregate types for tensors
 and memory buffers. MLIR [standard types](#standard-types) do not include
 structures, arrays, or dictionaries.
 
 MLIR has an open type system (i.e. there is no fixed list of types), and types
 may have application-specific semantics. For example, MLIR supports a set of
 [dialect types](#dialect-types).
 
 ```
 type ::= type-alias | dialect-type | standard-type
 
 type-list-no-parens ::=  type (`,` type)*
 type-list-parens ::= `(` `)`
                    | `(` type-list-no-parens `)`
 
-// This is a common way to refer to an SSA value with a specified type.
+// This is a common way to refer to a value with a specified type.
 ssa-use-and-type ::= ssa-use `:` type
 
 // Non-empty list of names and types.
 ssa-use-and-type-list ::= ssa-use-and-type (`,` ssa-use-and-type)*
 ```
 
 ### Type Aliases
 

 function-result-type ::= type-list-parens
                        | non-function-type
 
 function-type ::= type-list-parens `->` function-result-type
 ```
 
 MLIR supports first-class functions: for example, the
 [`constant` operation](Dialects/Standard.md#constant-operation) produces the
-address of a function as an SSA value. This SSA value may be passed to and
+address of a function as a value. This value may be passed to and
 returned from functions, merged across control flow boundaries with
 [block arguments](#blocks), and called with the
 [`call_indirect` operation](Dialects/Standard.md#call-indirect-operation).
 
 Function types are also used to indicate the arguments and results of
 [operations](#operations).
 
 #### Index Type

 tensor-memref-element-type ::= vector-element-type | vector-type | complex-type
 
 // memref requires a known rank, but tensor does not.
 dimension-list ::= dimension-list-ranked | (`*` `x`)
 dimension-list-ranked ::= (dimension `x`)*
 dimension ::= `?` | decimal-literal
 ```
 
-SSA values of tensor type represents aggregate N-dimensional data values, and
+Values with tensor type represents aggregate N-dimensional data values, and
 have a known element type. It may have an unknown rank (indicated by `*`) or may
 have a fixed rank with a list of dimensions. Each dimension may be a static
 non-negative decimal constant or be dynamically determined (indicated by `?`).
 
 The runtime representation of the MLIR tensor type is intentionally abstracted -
 you cannot control layout or get a pointer to the data. For low level buffer
 access, MLIR has a [`memref` type](#memref-type). This abstracted runtime
 representation holds both the tensor data values as well as information about

 
 This attribute can only be held internally by
 [array attributes](#array-attribute) and
 [dictionary attributes](#dictionary-attribute)(including the top-level operation
 attribute dictionary), i.e. no other attribute kinds such as Locations or
 extended attribute kinds.
 
 **Rationale:** Identifying accesses to global data is critical to
-enabling efficient multi-threaded compilation.  Restricting global
+enabling efficient multi-threaded compilation. Restricting global
 data access to occur through symbols and limiting the places that can
 legally hold a symbol reference simplifies reasoning about these data
 accesses.
 
 See [`Symbols And SymbolTables`](SymbolsAndSymbolTables.md) for more
 information.
 
 #### Type Attribute

mlir/include/mlir/IR/CMakeLists.txt

 add_mlir_interface(OpAsmInterface)
 add_mlir_interface(SymbolInterfaces)
+add_mlir_interface(RegionKindInterface)

mlir/include/mlir/IR/Dominance.h

public:
   /// Recalculate the dominance info.
   void recalculate(Operation *op);
 
   /// Finds the nearest common dominator block for the two given blocks a
   /// and b. If no common dominator can be found, this function will return
   /// nullptr.
   Block *findNearestCommonDominator(Block *a, Block *b) const;
 
+  /// Return true if there is dominanceInfo for the given region.
+  bool hasDominanceInfo(Region *region) {
+    return dominanceInfos.count(region) != 0;
+  }
+
   /// Get the root dominance node of the given region.
   DominanceInfoNode *getRootNode(Region *region) {
     assert(dominanceInfos.count(region) != 0);
     return dominanceInfos[region]->getRootNode();
   }
 
   /// Return the dominance node from the Region containing block A.
   DominanceInfoNode *getNode(Block *a);
 
 protected:
   using super = DominanceInfoBase<IsPostDom>;
 
   /// Return true if the specified block A properly dominates block B.
   bool properlyDominates(Block *a, Block *b) const;
 
   /// Return true if the specified block is reachable from the entry
   /// block of its region.
   bool isReachableFromEntry(Block *a) const;
 
   /// A mapping of regions to their base dominator tree.
   DenseMap<Region *, std::unique_ptr<base>> dominanceInfos;
 };
 } // end namespace detail
 
-/// A class for computing basic dominance information.
+/// A class for computing basic dominance information. Note that this
+/// class is aware of different types of regions and returns a
+/// region-kind specific concept of dominance. See RegionKindInterface.
 class DominanceInfo : public detail::DominanceInfoBase</*IsPostDom=*/false> {
 public:
   using super::super;
 
-  /// Return true if the specified block is reachable from the entry
-  /// block of its region.
+  /// Return true if the specified block is reachable from the entry block of
+  /// its region. In an SSACFG region, a block is reachable from the entry block
+  /// if it is the successor of the entry block or another reachable block. In a
+  /// Graph region, all blocks are reachable.
   bool isReachableFromEntry(Block *a) const {
     return super::isReachableFromEntry(a);
   }
 
-  /// Return true if operation A properly dominates operation B.
+  /// Return true if operation A properly dominates operation B, i.e. if A and B
+  /// are in the same block and A properly dominates B within the block, or if
+  /// the block that contains A properly dominates the block that contains B. In
+  /// an SSACFG region, Operation A dominates Operation B in the same block if A
+  /// preceeds B. In a Graph region, all operations in a block dominate all
+  /// other operations in the same block.
   bool properlyDominates(Operation *a, Operation *b) const;
 
-  /// Return true if operation A dominates operation B.
+  /// Return true if operation A dominates operation B, i.e. if A and B are the
+  /// same operation or A properly dominates B.
   bool dominates(Operation *a, Operation *b) const {
     return a == b || properlyDominates(a, b);
   }
 
-  /// Return true if value A properly dominates operation B.
+  /// Return true if value A properly dominates operation B, i.e if the
+  /// operation that defines A properlyDominates B and the operation that
+  /// defines A does not contain B.
   bool properlyDominates(Value a, Operation *b) const;
 
-  /// Return true if operation A dominates operation B.
+  /// Return true if operation A dominates operation B, i.e if the operation
+  /// that defines A dominates B.
   bool dominates(Value a, Operation *b) const {
     return (Operation *)a.getDefiningOp() == b || properlyDominates(a, b);
   }
 
-  /// Return true if the specified block A dominates block B.
+  /// Return true if the specified block A dominates block B, i.e. if block A
+  /// and block B are the same block or block A properly dominates block B.
   bool dominates(Block *a, Block *b) const {
     return a == b || properlyDominates(a, b);
   }
 
-  /// Return true if the specified block A properly dominates block B.
+  /// Return true if the specified block A properly dominates block B, i.e.: if
+  /// block A contains block B, or if the region which contains block A also
+  /// contains block B or some parent of block B and block A dominates that
+  /// block in that kind of region.  In an SSACFG region, block A dominates
+  /// block B if all control flow paths from the entry block to block B flow
+  /// through block A. In a Graph region, all blocks dominate all other blocks.
   bool properlyDominates(Block *a, Block *b) const {
     return super::properlyDominates(a, b);
   }
 
   /// Update the internal DFS numbers for the dominance nodes.
   void updateDFSNumbers();
 };
 

mlir/include/mlir/IR/RegionKindInterface.h

+//===- RegionKindInterface.h - Region Kind Interfaces -----------*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// This file contains the definitions of the infer op interfaces defined in
+// `RegionKindInterface.td`.
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef MLIR_IR_REGIONKINDINTERFACE_H_
+#define MLIR_IR_REGIONKINDINTERFACE_H_
+
+#include "mlir/IR/OpDefinition.h"
+
+namespace mlir {
+
+/// The kinds of regions contained in an operation. SSACFG regions
+/// require the SSA-Dominance property to hold. Graph regions do not
+/// require SSA-Dominance. If a registered operation does not implement
+/// RegionKindInterface, then any regions it contains are assumed to be
+/// SSACFG regions.
+enum class RegionKind {
+  SSACFG,
+  Graph,
+};
+
+} // namespace mlir
+
+#include "mlir/IR/RegionKindInterface.h.inc"
+
+#endif // MLIR_IR_REGIONKINDINTERFACE_H_

mlir/include/mlir/IR/RegionKindInterface.td

+//===- RegionKindInterface.td - Region kind interfaces -----*- tablegen -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// This file contains a set of interfaces to query the properties of regions
+// in an operation.
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef MLIR_IR_REGIONKINDINTERFACE
+#define MLIR_IR_REGIONKINDINTERFACE
+
+include "mlir/IR/OpBase.td"
+
+// OpInterface to query the properties of regions in an operation
+def RegionKindInterface : OpInterface<"RegionKindInterface"> {
+  let description = [{
+    Interface for operations to describe the abstract semantics of
+    their regions. Currently, two kinds of regions are
+    supported. RegionKind::Graph represents a graph region without
+    control flow semantics. RegionKind::SSACFG represents an
+    [SSA-style control flow](LangRef.md#modeling-control-flow) region
+    with basic blocks, sequential semantics, and reachability.
+  }];
+  let cppNamespace = "::mlir";
+
+  let methods = [
+    StaticInterfaceMethod<
+      /*desc=*/[{
+        Return the kind of the region with the given index inside this operation.
+      }],
+      /*retTy=*/"RegionKind",
+      /*methodName=*/"getRegionKind",
+      /*args=*/(ins "unsigned":$index)
+    >,
+    StaticInterfaceMethod<
+      /*desc=*/"Return true if the kind of the given region requires the "
+               "SSA-Dominance property",
+      /*retTy=*/"bool",
+      /*methodName=*/"hasSSADominance",
+      /*args=*/(ins "unsigned":$index),
+      /*methodBody=*/[{
+        return getRegionKind(index) == RegionKind::SSACFG;
+      }]
+    >,
+  ];
+}
+
+#endif // MLIR_IR_REGIONKINDINTERFACE

mlir/lib/IR/CMakeLists.txt

add_mlir_library(MLIRIR
   IntegerSet.cpp
   Location.cpp
   MLIRContext.cpp
   Module.cpp
   Operation.cpp
   OperationSupport.cpp
   PatternMatch.cpp
   Region.cpp
+  RegionKindInterface.cpp
   StandardTypes.cpp
   SymbolTable.cpp
   Types.cpp
   TypeUtilities.cpp
   Value.cpp
   Verifier.cpp
   Visitors.cpp
 
   ADDITIONAL_HEADER_DIRS
   ${MLIR_MAIN_INCLUDE_DIR}/mlir/IR
 
   DEPENDS
   MLIRCallInterfacesIncGen
   MLIROpAsmInterfaceIncGen
   MLIRSymbolInterfacesIncGen
+  MLIRRegionKindInterfaceIncGen
 
   LINK_LIBS PUBLIC
   MLIRSupport
   )

mlir/lib/IR/Dominance.cpp

 //===- Dominance.cpp - Dominator analysis for CFGs ------------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 //
 // Implementation of dominance related classes and instantiations of extern
 // templates.
 //
 //===----------------------------------------------------------------------===//
 
 #include "mlir/IR/Dominance.h"
 #include "mlir/IR/Operation.h"
+#include "mlir/IR/RegionKindInterface.h"
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/Support/GenericDomTreeConstruction.h"
 
 using namespace mlir;
 using namespace mlir::detail;
 
 template class llvm::DominatorTreeBase<Block, /*IsPostDom=*/false>;
 template class llvm::DominatorTreeBase<Block, /*IsPostDom=*/true>;
 template class llvm::DomTreeNodeBase<Block>;
 
+/// Return true if the region with the given index inside the operation
+/// has SSA dominance.
+static bool hasSSADominance(Operation *op, unsigned index) {
+  auto kindInterface = dyn_cast<RegionKindInterface>(op);
+  return op->isRegistered() &&
+         (!kindInterface || kindInterface.hasSSADominance(index));
+}
+
 //===----------------------------------------------------------------------===//
 // DominanceInfoBase
 //===----------------------------------------------------------------------===//
 
 template <bool IsPostDom>
 void DominanceInfoBase<IsPostDom>::recalculate(Operation *op) {
   dominanceInfos.clear();
 
-  /// Build the dominance for each of the operation regions.
+  // Build the dominance for each of the operation regions.
   op->walk([&](Operation *op) {
-    for (auto &region : op->getRegions()) {
+    auto kindInterface = dyn_cast<RegionKindInterface>(op);
+    unsigned numRegions = op->getNumRegions();
+    for (unsigned i = 0; i < numRegions; i++) {
+      Region &region = op->getRegion(i);
       // Don't compute dominance if the region is empty.
       if (region.empty())
         continue;
+
+      // Dominance changes based on the region type. Avoid the helper
+      // function here so we don't do the region cast repeatedly.
+      bool hasSSADominance =
+          op->isRegistered() &&
+          (!kindInterface || kindInterface.hasSSADominance(i));
+      // If a region has SSADominance, then compute detailed dominance
+      // info.  Otherwise, all values in the region are live anywhere
+      // in the region, which is represented as an empty entry in the
+      // dominanceInfos map.
+      if (hasSSADominance) {
         auto opDominance = std::make_unique<base>();
         opDominance->recalculate(region);
         dominanceInfos.try_emplace(&region, std::move(opDominance));
       }
+    }
   });
 }
 
 /// Walks up the list of containers of the given block and calls the
 /// user-defined traversal function for every pair of a region and block that
 /// could be found during traversal. If the user-defined function returns true
 /// for a given pair, traverseAncestors will return the current block. Nullptr
 /// otherwise.
DominanceInfoBase<IsPostDom>::findNearestCommonDominator(Block *a,
 
   // Since the blocks live in the same region, we can rely on already
   // existing dominance functionality.
   return infoAIt->second->findNearestCommonDominator(a, b);
 }
 
 template <bool IsPostDom>
 DominanceInfoNode *DominanceInfoBase<IsPostDom>::getNode(Block *a) {
-  auto *region = a->getParent();
+  Region *region = a->getParent();
   assert(dominanceInfos.count(region) != 0);
   return dominanceInfos[region]->getNode(a);
 }
 
 /// Return true if the specified block A properly dominates block B.
 template <bool IsPostDom>
 bool DominanceInfoBase<IsPostDom>::properlyDominates(Block *a, Block *b) const {
   // A block dominates itself but does not properly dominate itself.
   if (a == b)
     return false;
 
   // If either a or b are null, then conservatively return false.
   if (!a || !b)
     return false;
 
   // If both blocks are not in the same region, 'a' properly dominates 'b' if
   // 'b' is defined in an operation region that (recursively) ends up being
   // dominated by 'a'. Walk up the list of containers enclosing B.
-  auto *regionA = a->getParent();
+  Region *regionA = a->getParent();
   if (regionA != b->getParent()) {
     b = traverseAncestors(
         b, [&](Block *block) { return block->getParent() == regionA; });
 
     // If we could not find a valid block b then it is either a not a dominator
     // or a post dominator.
     if (!b)
       return IsPostDom;
if (baseInfoIt == dominanceInfos.end())
     return true;
   return baseInfoIt->second->properlyDominates(a, b);
 }
 
 /// Return true if the specified block is reachable from the entry block of its
 /// region.
 template <bool IsPostDom>
 bool DominanceInfoBase<IsPostDom>::isReachableFromEntry(Block *a) const {
-  auto *regionA = a->getParent();
+  Region *regionA = a->getParent();
   auto baseInfoIt = dominanceInfos.find(regionA);
   if (baseInfoIt == dominanceInfos.end())
     return true;
   return baseInfoIt->second->isReachableFromEntry(a);
 }
 
-template class mlir::detail::DominanceInfoBase</*IsPostDom=*/true>;
-template class mlir::detail::DominanceInfoBase</*IsPostDom=*/false>;
+template class detail::DominanceInfoBase</*IsPostDom=*/true>;
+template class detail::DominanceInfoBase</*IsPostDom=*/false>;
 
 //===----------------------------------------------------------------------===//
 // DominanceInfo
 //===----------------------------------------------------------------------===//
 
 /// Return true if operation A properly dominates operation B.
 bool DominanceInfo::properlyDominates(Operation *a, Operation *b) const {
-  auto *aBlock = a->getBlock(), *bBlock = b->getBlock();
+  Block *aBlock = a->getBlock(), *bBlock = b->getBlock();
+  Region *aRegion = a->getParentRegion();
+  unsigned aRegionNum = aRegion->getRegionNumber();
+  Operation *ancestor = aRegion->getParentOp();
 
   // If a or b are not within a block, then a does not dominate b.
   if (!aBlock || !bBlock)
     return false;
 
+  if (aBlock == bBlock) {
+    // Dominance changes based on the region type. In a region with SSA
+    // dominance, uses inside the same block must follow defs. In other
+    // regions kinds, uses and defs can come in any order inside a block.
+    if (hasSSADominance(ancestor, aRegionNum)) {
       // If the blocks are the same, then check if b is before a in the block.
-  if (aBlock == bBlock)
       return a->isBeforeInBlock(b);
+    }
+    return true;
+  }
 
   // Traverse up b's hierarchy to check if b's block is contained in a's.
   if (auto *bAncestor = aBlock->findAncestorOpInBlock(*b)) {
     // Since we already know that aBlock != bBlock, here bAncestor != b.
     // a and bAncestor are in the same block; check if 'a' dominates
     // bAncestor.
     return dominates(a, bAncestor);
   }
 
   // If the blocks are different, check if a's block dominates b's.
   return properlyDominates(aBlock, bBlock);
 }
 
 /// Return true if value A properly dominates operation B.
 bool DominanceInfo::properlyDominates(Value a, Operation *b) const {
   if (auto *aOp = a.getDefiningOp()) {
+    // Dominance changes based on the region type.
+    auto *aRegion = aOp->getParentRegion();
+    unsigned aRegionNum = aRegion->getRegionNumber();
+    Operation *ancestor = aRegion->getParentOp();
+    // Dominance changes based on the region type. In a region with SSA
+    // dominance, values defined by an operation cannot be used by the
+    // operation. In other regions kinds they can be used the operation.
+    if (hasSSADominance(ancestor, aRegionNum)) {
       // The values defined by an operation do *not* dominate any nested
       // operations.
       if (aOp->getParentRegion() != b->getParentRegion() && aOp->isAncestor(b))
         return false;
+    }
     return properlyDominates(aOp, b);
   }
 
   // block arguments properly dominate all operations in their own block, so
   // we use a dominates check here, not a properlyDominates check.
   return dominates(a.cast<BlockArgument>().getOwner(), b->getBlock());
 }
 
 void DominanceInfo::updateDFSNumbers() {
   for (auto &iter : dominanceInfos)
     iter.second->updateDFSNumbers();
 }
 
 //===----------------------------------------------------------------------===//
 // PostDominanceInfo
 //===----------------------------------------------------------------------===//
 
 /// Returns true if statement 'a' properly postdominates statement b.
 bool PostDominanceInfo::properlyPostDominates(Operation *a, Operation *b) {
   auto *aBlock = a->getBlock(), *bBlock = b->getBlock();
+  auto *aRegion = a->getParentRegion();
+  unsigned aRegionNum = aRegion->getRegionNumber();
+  Operation *ancestor = aRegion->getParentOp();
 
   // If a or b are not within a block, then a does not post dominate b.
   if (!aBlock || !bBlock)
     return false;
 
   // If the blocks are the same, check if b is before a in the block.
-  if (aBlock == bBlock)
+  if (aBlock == bBlock) {
+    // Dominance changes based on the region type.
+    if (hasSSADominance(ancestor, aRegionNum)) {
+      // If the blocks are the same, then check if b is before a in the block.
       return b->isBeforeInBlock(a);
+    }
+    return true;
+  }
 
   // Traverse up b's hierarchy to check if b's block is contained in a's.
   if (auto *bAncestor = a->getBlock()->findAncestorOpInBlock(*b))
     // Since we already know that aBlock != bBlock, here bAncestor != b.
     // a and bAncestor are in the same block; check if 'a' postdominates
     // bAncestor.
     return postDominates(a, bAncestor);
 
   // If the blocks are different, check if a's block post dominates b's.
   return properlyDominates(aBlock, bBlock);
 }

mlir/lib/IR/RegionKindInterface.cpp

+//===- RegionKindInterface.cpp - Region Kind Interfaces ---------*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// This file contains the definitions of the region kind interfaces defined in
+// `RegionKindInterface.td`.
+//
+//===----------------------------------------------------------------------===//
+
+#include "mlir/IR/RegionKindInterface.h"
+
+using namespace mlir;
+
+#include "mlir/IR/RegionKindInterface.cpp.inc"

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/RegionKindInterface.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 {
public:
   }
 
 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.
+  /// Verify the dominance property of operations within the given Region.
   LogicalResult verifyDominance(Region &region);
-  LogicalResult verifyDominance(Operation &op);
+
+  /// Verify the dominance property of regions contained within the given
+  /// Operation.
+  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();
 
   // Verify the first block has no predecessors.
   auto *firstBB = &region.front();
   if (!firstBB->hasNoPredecessors())
     return mlir::emitError(region.getLoc(),
                            "entry block of region may not have predecessors");
 
   // Verify each of the blocks within the region.
-  for (auto &block : region)
+  for (Block &block : region)
     if (failed(verifyBlock(block)))
       return failure();
   return success();
 }
 
 LogicalResult OperationVerifier::verifyBlock(Block &block) {
   for (auto arg : block.getArguments())
     if (arg.getOwner() != &block)
if (auto *dialect = getDialectForAttribute(attr))
         return failure();
   }
 
   // If we can get operation info for this, check the custom hook.
   auto *opInfo = op.getAbstractOperation();
   if (opInfo && failed(opInfo->verifyInvariants(&op)))
     return failure();
 
+  auto kindInterface = dyn_cast<mlir::RegionKindInterface>(op);
+
   // Verify that all child regions are ok.
-  for (auto &region : op.getRegions())
+  unsigned numRegions = op.getNumRegions();
+  for (unsigned i = 0; i < numRegions; i++) {
+    Region &region = op.getRegion(i);
+    // Check that Graph Regions only have a single basic block. This is
+    // similar to the code in SingleBlockImplicitTerminator, but doesn't
+    // require the trait to be specified. This arbitrary limitation is
+    // designed to limit the number of cases that have to be handled by
+    // transforms and conversions until the concept stabilizes.
+    if (op.isRegistered() && kindInterface &&
+        kindInterface.getRegionKind(i) == RegionKind::Graph) {
+      // Empty regions are fine.
+      if (region.empty())
+        continue;
+
+      // Non-empty regions must contain a single basic block.
+      if (std::next(region.begin()) != region.end())
+        return op.emitOpError("expects graph region #")
+               << i << " to have 0 or 1 blocks";
+    }
     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();
 
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) {
   // Verify the dominance of each of the held operations.
-  for (auto &block : region)
-    // Dominance is only reachable inside reachable blocks.
+  for (Block &block : region) {
+    // Dominance is only meaningful inside reachable blocks.
     if (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();
-  return success();
-}
-
-LogicalResult OperationVerifier::verifyDominance(Operation &op) {
+      for (Operation &op : block)
         // 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();
         }
+    // Recursively verify dominance within each operation in the
+    // block, even if the block itself is not reachable, or we are in
+    // a region which doesn't respect dominance.
+    for (Operation &op : block)
+      if (failed(verifyDominanceOfContainedRegions(op)))
+        return failure();
+  }
+  return success();
+}
 
-  // Verify the dominance of each of the nested blocks within this operation.
-  for (auto &region : op.getRegions())
+/// Verify the dominance of each of the nested blocks within the given operation
+LogicalResult
+OperationVerifier::verifyDominanceOfContainedRegions(Operation &op) {
+  for (Region &region : op.getRegions()) {
     if (failed(verifyDominance(region)))
       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/lib/Transforms/CSE.cpp

void CSE::simplifyRegion(ScopedMapTy &knownValues, DominanceInfo &domInfo,
 
   // If the region only contains one block, then simplify it directly.
   if (std::next(region.begin()) == region.end()) {
     ScopedMapTy::ScopeTy scope(knownValues);
     simplifyBlock(knownValues, domInfo, &region.front());
     return;
   }
 
+  // If the region does not have dominanceInfo, then skip it.
+  // TODO: Regions without SSA dominance should define a different
+  // traversal order which is appropriate and can be used here.
+  if (!domInfo.hasDominanceInfo(&region))
+    return;
+
   // Note, deque is being used here because there was significant performance
   // gains over vector when the container becomes very large due to the
   // specific access patterns. If/when these performance issues are no
   // longer a problem we can change this to vector. For more information see
   // the llvm mailing list discussion on this:
   // http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20120116/135228.html
   std::deque<std::unique_ptr<CFGStackNode>> stack;
 

mlir/test/CMakeLists.txt

 
 add_lit_testsuite(check-mlir "Running the MLIR regression tests"
   ${CMAKE_CURRENT_BINARY_DIR}
   DEPENDS ${MLIR_TEST_DEPENDS}
   )
 set_target_properties(check-mlir PROPERTIES FOLDER "Tests")
 
 add_lit_testsuites(MLIR ${CMAKE_CURRENT_SOURCE_DIR}
-  DEPENDS ${MLIR_TEST_DEPS}
+  DEPENDS ${MLIR_TEST_DEPENDS}
 )

mlir/test/IR/invalid.mlir

 // -----
 
 // expected-error @+1 {{expected non-function type}}
 func @negative_in_tensor_size() -> tensor<1x-1xi32>
 
 // -----
 
 func @invalid_nested_dominance() {
-  "foo.region"() ({
+  "test.ssacfg_region"() ({
     // expected-error @+1 {{operand #0 does not dominate this use}}
     "foo.use" (%1) : (i32) -> ()
     br ^bb2
 
   ^bb2:
     // expected-note @+1 {{operand defined here}}
     %1 = constant 0 : i32
     "foo.yield" () : () -> ()

 // -----
 
 // expected-error @+1 {{attribute names with a '.' are reserved for dialect-defined names}}
 #foo.attr = i32
 
 // -----
 
 func @invalid_region_dominance() {
-  "foo.region"() ({
+  "test.ssacfg_region"() ({
     // expected-error @+1 {{operand #0 does not dominate this use}}
     "foo.use" (%def) : (i32) -> ()
     "foo.yield" () : () -> ()
   }, {
     // expected-note @+1 {{operand defined here}}
     %def = "foo.def" () : () -> i32
   }) : () -> ()
   return
 }
 
 // -----
 
 func @invalid_region_dominance() {
   // expected-note @+1 {{operand defined here}}
-  %def = "foo.region_with_def"() ({
+  %def = "test.ssacfg_region"() ({
     // expected-error @+1 {{operand #0 does not dominate this use}}
     "foo.use" (%def) : (i32) -> ()
     "foo.yield" () : () -> ()
   }) : () -> (i32)
   return
 }
 
 // -----

 }
 
 // -----
 
 func @dominance_error_in_unreachable_op() -> i1 {
   %c = constant false
   return %c : i1
 ^bb0:
-  "dummy" () ({  // unreachable
+  "test.ssacfg_region" () ({ // unreachable
     ^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 %c : i1
 }
+
+// -----
+
+func @invalid_region_dominance_with_dominance_free_regions() {
+  test.graph_region {
+    "foo.use" (%1) : (i32) -> ()
+    "foo.region"() ({
+      %1 = constant 0 : i32  // This value is used outside of the region.
+      "foo.yield" () : () -> ()
+    }, {
+      // expected-error @+1 {{expected operation name in quotes}}
+      %2 = constant 1 i32  // Syntax error causes region deletion.
+    }) : () -> ()
+  }
+  return
+}

mlir/test/IR/parser.mlir

func @pretty_names() {
 
   %q:3, %r = test.string_attr_pretty_name
   // CHECK: %q, %q_1, %q_2, %r = test.string_attr_pretty_name attributes {names = ["q", "q", "q", "r"]}
 
   // CHECK: return
   return
 }
 
+// CHECK-LABEL: func @unreachable_dominance_violation_ok
 func @unreachable_dominance_violation_ok() -> i1 {
-  %c = constant false       // CHECK: [[VAL:%.*]] = constant false
-  return %c : i1    // CHECK:   return [[VAL]] : i1
-^bb1:         // CHECK: ^bb1:   // no predecessors
+// CHECK:   [[VAL:%.*]] = constant false
+// CHECK:   return [[VAL]] : i1
+// CHECK: ^bb1:   // no predecessors
+// CHECK:   [[VAL2:%.*]]:3 = "bar"([[VAL3:%.*]]) : (i64) -> (i1, i1, i1)
+// CHECK:   br ^bb3
+// CHECK: ^bb2:   // pred: ^bb2
+// CHECK:   br ^bb2
+// CHECK: ^bb3:   // pred: ^bb1
+// CHECK:   [[VAL3]] = "foo"() : () -> i64
+// CHECK:   return [[VAL2]]#1 : i1
+// CHECK: }
+  %c = constant false
+  return %c : i1
+^bb1:
   // %1 is not dominated by it's definition, but block is not reachable.
-  %2:3 = "bar"(%1) : (i64) -> (i1,i1,i1) // CHECK: [[VAL2:%.*]]:3 = "bar"([[VAL3:%.*]]) : (i64) -> (i1, i1, i1)
-  br ^bb4     // CHECK:   br ^bb3
-^bb2:         // CHECK: ^bb2:   // pred: ^bb2
-  br ^bb2     // CHECK:   br ^bb2
-^bb4:         // CHECK: ^bb3:   // pred: ^bb1
-  %1 = "foo"() : ()->i64 // CHECK: [[VAL3]] = "foo"() : () -> i64
-  return %2#1 : i1 // CHECK: return [[VAL2]]#1 : i1
-}            // CHECK: }
+  %2:3 = "bar"(%1) : (i64) -> (i1,i1,i1)
+  br ^bb3
+^bb2:
+  br ^bb2
+^bb3:
+  %1 = "foo"() : ()->i64
+  return %2#1 : i1
+}
+
+// CHECK-LABEL: func @graph_region_in_hierarchy_ok
+func @graph_region_in_hierarchy_ok() -> i64 {
+// CHECK:   br ^bb2
+// CHECK: ^bb1:
+// CHECK:   test.graph_region {
+// CHECK:     [[VAL2:%.*]]:3 = "bar"([[VAL3:%.*]]) : (i64) -> (i1, i1, i1)
+// CHECK:   }
+// CHECK:   br ^bb3
+// CHECK: ^bb2:   // pred: ^bb0
+// CHECK:   [[VAL3]] = "foo"() : () -> i64
+// CHECK:   br ^bb1
+// CHECK: ^bb3:   // pred: ^bb1
+// CHECK:   return [[VAL3]] : i64
+// CHECK: }
+  br ^bb2
+^bb1:
+  test.graph_region {
+    // %1 is well-defined here, since bb2 dominates bb1.
+    %2:3 = "bar"(%1) : (i64) -> (i1,i1,i1)
+  }
+  br ^bb4
+^bb2:
+  %1 = "foo"() : ()->i64
+  br ^bb1
+^bb4:
+  return %1 : i64
+}
+
+// CHECK-LABEL: func @graph_region_kind
+func @graph_region_kind() -> () {
+// CHECK: [[VAL2:%.*]]:3 = "bar"([[VAL3:%.*]]) : (i64) -> (i1, i1, i1)
+// CHECK: [[VAL3]] = "baz"([[VAL2]]#0) : (i1) -> i64
+  test.graph_region {
+    // %1 OK here in in graph region.
+    %2:3 = "bar"(%1) : (i64) -> (i1,i1,i1)
+    %1 = "baz"(%2#0) : (i1) -> (i64)
+  }
+  return
+}
+
+// CHECK-LABEL: func @graph_region_inside_ssacfg_region
+func @graph_region_inside_ssacfg_region() -> () {
+// CHECK: "test.ssacfg_region"
+// CHECK:   [[VAL3:%.*]] = "baz"() : () -> i64
+// CHECK:   test.graph_region {
+// CHECK:     [[VAL2:%.*]]:3 = "bar"([[VAL3]]) : (i64) -> (i1, i1, i1)
+// CHECK:   }
+// CHECK:   [[VAL4:.*]] = "baz"() : () -> i64
+  "test.ssacfg_region"() ({
+    %1 = "baz"() : () -> (i64)
+    test.graph_region {
+      %2:3 = "bar"(%1) : (i64) -> (i1,i1,i1)
+    }
+    %3 = "baz"() : () -> (i64)
+  }) : () -> ()
+  return
+}
+
+// CHECK-LABEL: func @graph_region_in_graph_region_ok
+func @graph_region_in_graph_region_ok() -> () {
+// CHECK: test.graph_region {
+// CHECK:   test.graph_region {
+// CHECK:     [[VAL2:%.*]]:3 = "bar"([[VAL3:%.*]]) : (i64) -> (i1, i1, i1)
+// CHECK:   }
+// CHECK:   [[VAL3]] = "foo"() : () -> i64
+// CHECK: }
+test.graph_region {
+    test.graph_region {
+    // %1 is well-defined here since defined in graph region
+      %2:3 = "bar"(%1) : (i64) -> (i1,i1,i1)
+    }
+    %1 = "foo"() : ()->i64
+    "test.terminator"() : ()->()
+  }
+  return
+}
+
+// CHECK: test.graph_region {
+test.graph_region {
+// CHECK:   [[VAL1:%.*]] = "op1"([[VAL3:%.*]]) : (i32) -> i32
+// CHECK:   [[VAL2:%.*]] = "test.ssacfg_region"([[VAL1]], [[VAL2]], [[VAL3]], [[VAL4:%.*]]) ( {
+// CHECK:     [[VAL5:%.*]] = "op2"([[VAL1]], [[VAL2]], [[VAL3]], [[VAL4]]) : (i32, i32, i32, i32) -> i32
+// CHECK:   }) : (i32, i32, i32, i32) -> i32
+// CHECK:   [[VAL3]] = "op2"([[VAL1]], [[VAL4]]) : (i32, i32) -> i32
+// CHECK:   [[VAL4]] = "op3"([[VAL1]]) : (i32) -> i32
+  %1 = "op1"(%3) : (i32) -> (i32)
+  %2 = "test.ssacfg_region"(%1, %2, %3, %4) ({
+    %5 = "op2"(%1, %2, %3, %4) :
+   (i32, i32, i32, i32) -> (i32)
+  }) : (i32, i32, i32, i32) -> (i32)
+  %3 = "op2"(%1, %4) : (i32, i32) -> (i32)
+  %4 = "op3"(%1) : (i32) -> (i32)
+}
+
+// CHECK: "unregistered_func_might_have_graph_region"() ( {
+// CHECK: [[VAL1:%.*]] = "foo"([[VAL1]], [[VAL2:%.*]]) : (i64, i64) -> i64
+// CHECK: [[VAL2]] = "bar"([[VAL1]])
+"unregistered_func_might_have_graph_region"() ( {
+  %1 = "foo"(%1, %2) : (i64, i64) -> i64
+  %2 = "bar"(%1) : (i64) -> i64
+  "unregistered_terminator"() : () -> ()
+}) {sym_name = "unregistered_op_dominance_violation_ok", type = () -> i1} : () -> ()

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 @failedHasDominanceScopeOutsideDominanceFreeScope() -> () {
+  "test.ssacfg_region"() ({
+    test.graph_region {
+      // expected-error @+1 {{operand #0 does not dominate this use}}
+      %2:3 = "bar"(%1) : (i64) -> (i1,i1,i1)
+    }
+    // expected-note @+1 {{operand defined here}}
+    %1 = "baz"() : () -> (i64)
+  }) : () -> ()
+  return
+}
+
+// -----
+
+// Ensure that SSACFG regions of operations in GRAPH regions are
+// checked for dominance
+func @illegalInsideDominanceFreeScope() -> () {
+  test.graph_region {
+    func @test() -> i1 {
+    ^bb1:
+      // expected-error @+1 {{operand #0 does not dominate this use}}
+      %2:3 = "bar"(%1) : (i64) -> (i1,i1,i1)
+      // expected-note @+1 {{operand defined here}}
+     %1 = "baz"(%2#0) : (i1) -> (i64)
+      return %2#1 : i1
+    }
+    "terminator"() : () -> ()
+  }
+  return
+}
+
+// -----
+
+// Ensure that SSACFG regions of operations in GRAPH regions are
+// checked for dominance
+func @illegalCDFGInsideDominanceFreeScope() -> () {
+  test.graph_region {
+    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
+}
+
+// -----
+
+// Ensure that GRAPH regions still have all values defined somewhere.
+func @illegalCDFGInsideDominanceFreeScope() -> () {
+  test.graph_region {
+    // expected-error @+1 {{use of undeclared SSA value name}}
+    %2:3 = "bar"(%1) : (i64) -> (i1,i1,i1)
+    "terminator"() : () -> ()
+  }
+  return
+}
+
+// -----
+
+func @graph_region_cant_have_blocks() {
+  test.graph_region {
+    // expected-error@-1 {{'test.graph_region' op expects graph region #0 to have 0 or 1 blocks}}
+  ^bb42:
+    br ^bb43
+  ^bb43:
+    "terminator"() : () -> ()
+  }
+}

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

 
 #ifndef MLIR_TESTDIALECT_H
 #define MLIR_TESTDIALECT_H
 
 #include "mlir/Dialect/Traits.h"
 #include "mlir/IR/Dialect.h"
 #include "mlir/IR/OpDefinition.h"
 #include "mlir/IR/OpImplementation.h"
+#include "mlir/IR/RegionKindInterface.h"
 #include "mlir/IR/StandardTypes.h"
 #include "mlir/IR/SymbolTable.h"
 #include "mlir/Interfaces/CallInterfaces.h"
 #include "mlir/Interfaces/ControlFlowInterfaces.h"
 #include "mlir/Interfaces/DerivedAttributeOpInterface.h"
 #include "mlir/Interfaces/InferTypeOpInterface.h"
 #include "mlir/Interfaces/SideEffectInterfaces.h"
 

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 SSACFGRegionOp
+//===----------------------------------------------------------------------===//
+
+RegionKind SSACFGRegionOp::getRegionKind(unsigned index) {
+  return RegionKind::SSACFG;
+}
+
+//===----------------------------------------------------------------------===//
+// Test GraphRegionOp
+//===----------------------------------------------------------------------===//
+
+static ParseResult parseGraphRegionOp(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, GraphRegionOp op) {
+  p << "test.graph_region ";
+  p.printRegion(op.region(), /*printEntryBlockArgs=*/false);
+}
+
+RegionKind GraphRegionOp::getRegionKind(unsigned index) {
+  return RegionKind::Graph;
+}
+
+//===----------------------------------------------------------------------===//
 // 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=*/{});
OpFoldResult TestOpInPlaceFold::fold(ArrayRef<Attribute> operands) {
   assert(operands.size() == 1);
   if (operands.front()) {
     setAttr("attr", operands.front());
     return getResult();
   }
   return {};
 }
 
-LogicalResult mlir::OpWithInferTypeInterfaceOp::inferReturnTypes(
+LogicalResult OpWithInferTypeInterfaceOp::inferReturnTypes(
     MLIRContext *, Optional<Location> location, ValueRange operands,
     DictionaryAttr attributes, RegionRange regions,
     SmallVectorImpl<Type> &inferredReturnTypes) {
   if (operands[0].getType() != operands[1].getType()) {
     return emitOptionalError(location, "operand type mismatch ",
                              operands[0].getType(), " vs ",
                              operands[1].getType());
   }
LogicalResult OpWithShapedTypeInferTypeInterfaceOp::inferReturnTypeComponents(
   auto type = IntegerType::get(17, context);
   inferredReturnShapes.push_back(ShapedTypeComponents({dim}, type));
   return success();
 }
 
 LogicalResult OpWithShapedTypeInferTypeInterfaceOp::reifyReturnTypeShapes(
     OpBuilder &builder, llvm::SmallVectorImpl<Value> &shapes) {
   shapes = SmallVector<Value, 1>{
-      builder.createOrFold<mlir::DimOp>(getLoc(), getOperand(0), 0)};
+      builder.createOrFold<DimOp>(getLoc(), getOperand(0), 0)};
   return success();
 }
 
 //===----------------------------------------------------------------------===//
 // Test SideEffect interfaces
 //===----------------------------------------------------------------------===//
 
 namespace {
void RegionIfOp::getSuccessorRegions(
   regions.push_back(RegionSuccessor(&elseRegion(), getElseArgs()));
 }
 
 //===----------------------------------------------------------------------===//
 // Dialect Registration
 //===----------------------------------------------------------------------===//
 
 // Static initialization for Test dialect registration.
-static mlir::DialectRegistration<mlir::TestDialect> testDialect;
+static DialectRegistration<TestDialect> testDialect;
 
 #include "TestOpEnums.cpp.inc"
 #include "TestOpStructs.cpp.inc"
 #include "TestTypeInterfaces.cpp.inc"
 
 #define GET_OP_CLASSES
 #include "TestOps.cpp.inc"

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

 //===-- TestOps.td - Test dialect operation definitions ----*- tablegen -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef TEST_OPS
 #define TEST_OPS
 
 include "mlir/Dialect/Affine/IR/AffineOpsBase.td"
 include "mlir/IR/OpBase.td"
 include "mlir/IR/OpAsmInterface.td"
+include "mlir/IR/RegionKindInterface.td"
 include "mlir/IR/SymbolInterfaces.td"
 include "mlir/Interfaces/SideEffectInterfaces.td"
 include "mlir/Interfaces/CallInterfaces.td"
 include "mlir/Interfaces/ControlFlowInterfaces.td"
 include "mlir/Interfaces/InferTypeOpInterface.td"
 include "mlir/Interfaces/SideEffectInterfaces.td"
 
 def Test_Dialect : Dialect {
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 SSACFGRegionOp : TEST_Op<"ssacfg_region",  [
+    DeclareOpInterfaceMethods<RegionKindInterface>]> {
+  let summary =  "operation with an SSACFG region";
+  let description = [{
+    Test op that defines an SSACFG region.
+  }];
+
+  let regions = (region VariadicRegion<AnyRegion>:$regions);
+  let arguments = (ins Variadic<AnyType>);
+  let results = (outs Variadic<AnyType>);
+}
+
+def GraphRegionOp : TEST_Op<"graph_region",  [
+    DeclareOpInterfaceMethods<RegionKindInterface>]> {
+  let summary =  "operation with a graph region";
+  let description = [{
+    Test op that defines a graph region.
+  }];
+
+  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); }];