[mlir] Introduce IRDL dialect

[math-fehr]

Summary

This patch introduces the IRDL dialect, which allow users to represent
dynamic dialect definitions as an MLIR program.

The IRDL dialect defines operations, attributes, and types, using
attribute constraints. For example:

module {
  irdl.dialect @cmath {
    irdl.type @complex {
      %0 = irdl.is f32
      %1 = irdl.is f64
      %2 = irdl.any_of(%0, %1)
      irdl.parameters(%2)
    }

    irdl.operation @norm {
      %0 = irdl.any
      %1 = irdl.parametric @complex<%0>
      irdl.operands(%1)
      irdl.results(%0)
    }
}

This program will define a new cmath.complex type, which expects a single
parameter, which is either an f32 or an f64. It also defines an
cmath.norm operation, which expects a single cmath.complex type as operand,
and returns a value of the underlying type. Note that like PDL (which IRDL is
heavily inspired from), both uses of %0 are expected to be of the same attribute.

IRDL handles attributes and types with the same operations, and does this by always
wrapping types in a TypeAttr. This is to simplify the language.

Depends on D144690

[rengolin]

Nice work! I have some comments inline, mostly to understand the dialect.

mlir/include/mlir/Dialect/IRDL/IR/IRDLOps.td

144

Many patterns have matches against any type or any shaped type, etc. I'm guessing you'd have to create a type that means any type, but not necessarily any attribute, so irdl.any doesn't cut. Attributes are also "open world" (unbound list), so better to add all types than to restrict attributes.

Perhaps a "library" of those things (always included) would do the trick, where you define irdl.any_int to be a union of all known integers, irdl.any_float with floats, etc. and irdl.any_type to be the union of all irdl.any_*_type.

156

%2 = any_of missing here

161

Some of your examples use parameters(%2), others parameters(%0, %0) for the same type declaration (complex). It's unclear to me how to use this.

It could be that parameter(%2) means a restriction for any type in a complex type, and that parameter(%0, %1) could have different types for complex, but they'd have to be declared differently, ex. complex<%0> vs. complex<%1, %2>.

I find the latter way (explicit in the number of types) more appealing, since it gives me information on all of the types, even if they're the same.

Is that what it means? Or am I just mixing semantics?

220

I'm imagining to support variadic here you'd probably need to create a new operation (like irdl.var) which would have type irdl.any_type or something, and just lower to the Variadic argument with the right type.

229

High-level question: Will IRDL detect this case where all ops must have the same type and add the appropriate trait to the op declaration? Similar for other attributes like isolatedFromAbove etc.

From the RFC, this seems to be in the roadmap, I'm just curious as if the intention is to request users to add manually the constraints or to automatically detect at least some basic ones.

309

Right, we could use this to create the irdl.any_int classes.

[math-fehr]

Thanks! I'll add the any_type, and cleanup a bit some parts of the documentation!

mlir/include/mlir/Dialect/IRDL/IR/IRDLOps.td

144

Good point, I'll add irdl.any_type for this patch!

Otherwise, irdl.any_float should be exactly irdl.any_of.(%0, %1, %2, %3, ...), where the variables are here the different possible floats. Now maybe we should find a way to create aliases (maybe using functions?), so we could create a any_float function somewhere, that people could use with a irdl.call @any_float() (which would be inlined later). Though I believe we should put that in a different patch.

For any_int, this is a bit more complex, since we would need to create a wrapper for builtin.integer, but this is complex since bulitin.integer does not have attribute parameters. My solution for this would be to use custom constraints, which are constraints defined by the user in C++. Once I add them, I agree we should have some sort of "library" of the most common ones, like "any_integer". But I would also suggest to do this in a following patch, if that makes sense?

My overall feeling is that we should try to keep a small "core calculus" for IRDL, so we can easily interpret it. Then we add more complex features on top through aliases and custom constraints.

156

Thanks! I'll fix this.

161

My mistake, I'll change the example to make this clearer! I should not have used the same name twice!

parameters(%2) declares that the attribute/type has only a single parameter, while parameters(%0, %0) declares that the attribute has two parameters, that are exactly the same (in practice, no one should write this).

220

Variadics might be a little bit more complex, because we need to differentiate A variadic number of operands of type %0 and A variadic number of operands of type %0, that all have the same type.

My feeling is that this will be implemented using regions, something like:

%1 = irdl.variadic {
  %0 = irdl.any_type
  irdl.yield %0
}

to represent a variadic of heterogeneous types.

and

%0 = irdl.any_type
%1 = irdl.variadic {
  irdl.yield %0
}

to represent a variadic of homogeneous types.

The semantics would be that any variable inside an irdl.variadic is reset at each check inside the variadic.
But this is something we should probably explore more, to find a possible better design.

229

Since we can detect it, I see no reasons not to include that later! Note that the trait would be useful to interacting with the operation, but otherwise the verifier itself is already performing intelligent checks for that.

309

Yes, that's how I see this at least!

[Mogball]

mostly stylistic comments

mlir/lib/Dialect/IRDL/AttributeWrapper.cpp

16 ↗

(On Diff #500029)

please use isa<TypeAttr>(attr)

20 ↗

(On Diff #500029)

26 ↗

(On Diff #500029)

please drop the llvm:: prefix. They aren't needed

mlir/lib/Dialect/IRDL/IR/IRDL.cpp

64

empty?

mlir/lib/Dialect/IRDL/IR/IRDLAttributes.cpp

32 ↗

(On Diff #500029)

[math-fehr]

Address comments

[math-fehr]

I addressed the comments. I'm currently splitting this patch again, by removing support of TypeWrapper and AttributeWrapper.
This should make it easier to review, and I'll add support for these constructs in a follow-up patch.

mlir/include/mlir/Dialect/IRDL/IR/IRDLOps.td

144

Actually, if this is fine for you, I'd prefer adding it on a following patch.
Right now, this patch is already quite big, and I would prefer keep things relatively small if that makes sense?

[math-fehr]

Remove attribute wrappers

[math-fehr]

I removed attribute wrappers from IRDL to make this patch much smaller. I'll add them back after the registration patches.

I think this patch should now be with minimal features, and only does the IRDL dialect definition.

[rengolin]

mlir/include/mlir/Dialect/IRDL/IR/IRDLOps.td

144

Absolutely! That's a big change indeed.

[math-fehr]

Remove any_of from irdl

[math-fehr]

To further simplify this patch (and the registration one), I removed any_of from irdl.
I'll add it in the patch right after the registrations one.

However, I kept the mentions to any_of in the documentation, if that is fine for you, to not rewrite almost all the code snippets (since all of them used any_of).

[rengolin]

In D144692#4179101, @math-fehr wrote:

To further simplify this patch (and the registration one), I removed any_of from irdl.
I'll add it in the patch right after the registrations one.

However, I kept the mentions to any_of in the documentation, if that is fine for you, to not rewrite almost all the code snippets (since all of them used any_of).

I don't mind a minimal version of any_of being here and then improved later. If you really want to split the work, then it would be good to see the patch series now, which is a bit more convoluted.

Basically, create another patch that depends on this one, and so forth until you can run a test that demonstrates a minimal functionality.

From what I read, you probably need about three patches to get to a nice place: This one, the registration one and the final tie on basic ops.

As it seems having types without any_of would be a bit pointless, not having it here would still need to show "elsewhere" how it would be implemented...

[rengolin]

PS: I have just merged the dependency D144690.

[math-fehr]

As it seems having types without any_of would be a bit pointless, not having it here would still need to show "elsewhere" how it would be implemented...

That makes sense, I'm adding this in a follow-up patch.
The reason why I removed any_of in particular was that it requires non-trivial code in the registration, around
100+ lines of code to check that we won't have backtracking problems in the registration.

Currently, I want to have 5+ patches:

• This one, that just introduce the dialect
• D144692, which introduces the registration, by just registering operations and types without checking their correctness
• 1 or more patches to introduce the actual verification logic. This change is still 600+ lines so I'm trying to make it into smaller patches
• Introduction of any_of
• Introduction of type and attribute wrappers, so we can use C++ types

[rengolin]

In D144692#4182393, @math-fehr wrote:

That makes sense, I'm adding this in a follow-up patch.

Awesome, thanks!

Can you name the patches "[1/5] ...", "[2/5] ..." etc? Makes it easier to review when we know in which order they are. The parent/child relationship in Phab isn't super evident.

As with other patch series, we review all patches and only when all patches are approved you can merge them all at once. This is to make sure all points are covered, and to make it easier to pre-approve the good ones and focus discussion on the hard ones.

[mehdi_amini]

In D144692#4183066, @rengolin wrote:

As with other patch series, we review all patches and only when all patches are approved you can merge them all at once. This is to make sure all points are covered, and to make it easier to pre-approve the good ones and focus discussion on the hard ones.

I don't believe there is any rule like that: I merge my patches as they get approved in general. We mostly need to agree about the overall design, then we can develop incrementally in tree. Stacked patches are mostly a convenient way of streamlining the development and review process.

[math-fehr]

That makes sense!
In that case I'll make it a 5 patch series that should include almost everything.
I'll keep a last patch for after this is merged, which is the AttributeWrapper stuff, that I want to rework a bit, and that is less important for now!

[mehdi_amini]

mlir/include/mlir/Dialect/IRDL/IR/IRDLTraits.h

26

Should make a note that this isn't recursive (you're not "walking" into the region)

39

48

If there are multiple ChildOp, this will traverse the region multiple times, can you look into having a single traversal?

82

(newline)

mlir/include/mlir/Dialect/IRDL/IR/IRDLTypes.td

47

Can you revisit this? At minima there is no %2 in the example.

[math-fehr]

I added all of the major patches (the following ones can be purely incremental)

• D144692 [mlir] Introduce IRDL dialect: Defining the dialect itself
• D144693 [mlir][irdl] Add IRDL registration: Register the dialects in mlir-opt, but without the verification logic
• D145733 [mlir][irdl] Add IRDL verification constraint classes: Adding the verification infrastructure, without using it
• D145734 [mlir][irdl] Add verification of IRDL ops: Use the verification infrastructure when registering IRDL dialects
• D145735 [mlir][irdl] Add irdl.any_of operation: Add the last core operation, any_of

[rengolin]

In D144692#4183069, @mehdi_amini wrote:

I don't believe there is any rule like that: I merge my patches as they get approved in general. We mostly need to agree about the overall design, then we can develop incrementally in tree. Stacked patches are mostly a convenient way of streamlining the development and review process.

Approving a patch-set in bulk isn't new or seldom used. We've been doing this in LLVM for at least a decade for all sorts of new features, including all new targets. What you describe is a completely different scenario.

We can't "agree about the overall design" if we can't see what the design is. That's the point of the initial patch-set being approved in bulk.

I'm not asking @math-fehr to post his entire work in one go, just those initial patches that would let us see "the overall design", but some parts may need more scrutiny than others.

After the initial set is approved and merged, then the work continues as usual, one patch at a time.

[mehdi_amini]

In D144692#4184072, @rengolin wrote:

In D144692#4183069, @mehdi_amini wrote:

I don't believe there is any rule like that: I merge my patches as they get approved in general. We mostly need to agree about the overall design, then we can develop incrementally in tree. Stacked patches are mostly a convenient way of streamlining the development and review process.

Approving a patch-set in bulk isn't new or seldom used. We've been doing this in LLVM for at least a decade for all sorts of new features, including all new targets. What you describe is a completely different scenario.

I don’t think so: I am describing how most of MLIR has been developed and how most of my work in LLVM in general happened ( I think I have my fair share of contributing and reviewing new features in LLVM and MLIR to know what I am talking about?).
What I am pointing at here is that your experience isn’t necessarily THE way, and that there is a spectrum and a lot of variability, yet you seem to present it as such.

We can't "agree about the overall design" if we can't see what the design is.

There is much more than code ; for any large components we’ve been operating with open meeting presentation and RFC to understand designs. In this case there is even a paper describing the design. “Understanding the design” is important, it just does not necessarily imply to have all the code ready.

Many large MLIR components were landed that way.
Take the “Action” framework for example I am currently landing in the codebase, https://reviews.llvm.org/D144811 landed much before the entire stack was reviewed. For other components we started landing patches much earlier in the stack.

Anyway, let go back to the review and when this patch is approved we should just feel free to merge it.

[math-fehr]

Address comments

Please tell me if the style of getChildOpIndex makes sense or
not, I have the feeling this could be rewritten in a nicer way,
but I have no clue how.

[math-fehr]

Rebase to main

[mehdi_amini]

mlir/include/mlir/Dialect/IRDL/IR/IRDLTraits.h

41

I think we can avoid the test here by adding an operand:

/// Return the index of the operation concrete type in the variadic list of
/// operation concrete types.
/// Return -1 if the operation class is not in the list.
template <typename Op, typename... Ops>
static int getChildOpIndex(Operation *op, int index = 0) {
  if (llvm::isa<Op>(op))
    return index;

  return getChildOpIndex<Ops...>(op, index+1);

68

What provides the getOps() here? Is there a traits for that or something?
Probably something to add to the class documentation as well as a contract on the template argument.

mlir/include/mlir/Dialect/IRDL/IR/IRDLTypes.td

47

The documentation says that This type represents a handle to an instance of an mlir::Attribute, but %1 is more like a handle to an mlir::Type right?

[math-fehr]

mlir/include/mlir/Dialect/IRDL/IR/IRDLTraits.h

68

This comes from OneRegion, which is added in the static_assert, is that the right way to do this?

Otherwise, I'll add the documentation on the class!

mlir/include/mlir/Dialect/IRDL/IR/IRDLTypes.td

47

In the current design, everything in IRDL is represented as an mlir::Attribute.
Types are stored in a TypeAttr. This makes the language much simpler overall, especially since dynamic types and attributes have Attribute parameters.

[math-fehr]

Address some comments

[mehdi_amini]

mlir/include/mlir/Dialect/IRDL/IR/IRDLTraits.h

68

That's fine, I forgot there is a getOps() expose by the Region class directly.

mlir/include/mlir/Dialect/IRDL/IR/IRDLTypes.td

47

That's kind of what I remembered, but I think we need to make a better effort on the documentation because we don't have a direct matching of mlir::Attribute and mlir::Type to direct concepts in IRDL.
The documentation here does not mention anything about types for example.

[math-fehr]

Document the handling of mlir::Type in IRDL.

[math-fehr]

mlir/include/mlir/Dialect/IRDL/IR/IRDLTypes.td

47

I documented it in the dialect documentation, and the irdl.type documentation, tell me what you think, and if you think I should document it in some other places.

[mehdi_amini]

This LGTM, but River may have thoughts on simplifying getChildOpIndex(), let's wait to hear back from him.

[rriddle]

mlir/include/mlir/Dialect/IRDL/IR/IRDL.h

18–25

Can you trim some of these?

mlir/include/mlir/Dialect/IRDL/IR/IRDL.td

39

The names here are missing the symbol reference marker

mlir/include/mlir/Dialect/IRDL/IR/IRDLOps.td

42–43

134–137

Can we instead define a getParentOp helper on the HasParent trait when a single parent type is given?

276

For each of these, please use "" for single line strings.

284–285

371

Why is there a space here?

mlir/include/mlir/Dialect/IRDL/IR/IRDLTraits.h

38–39

Let's avoid recursion here, this should be viable to write a somewhat simple fold expression:

template <typename... Ops>
static int getChildOpIndex(Operation *op) {
  // A short-circuit fold that increments an index until we find a match. If
  // the fold results in true, nothing matched.
  int index = 0;
  if (((isa<Ops>(op) ? false : (++index, true)) && ...))
    return -1;
  return index;
}

Would also remove the other function specialization, and this function could then just be inlined into its use (which would also remove the -1 handling).

mlir/lib/Dialect/IRDL/IR/IRDL.cpp

59

Please drop the trivial braces.

67

Drop the trivial braces here.

[math-fehr]

Address comments

[math-fehr]

Rebase to latest LLVM

[math-fehr]

Thank! Could you land this for me? I do not have commit access.

[math-fehr]

I just got an email with two buildbot failures:
https://lab.llvm.org/buildbot/#/builders/181/builds/16214
https://lab.llvm.org/buildbot/#/builders/180/builds/14593

Should we revert the commit? I believe this is this patch breaking it?

[rriddle]

@math-fehr Have you considered asking for commit access? It's not too difficult to request, and you've sent enough commits that it seems very reasonable.

[math-fehr]

Right, I'll try to ask for commit access, I wasn't sure what are the requirements for it!

[math-fehr]

Thanks for reverting it, I'm trying to reproduce it locally and find a fix!

[math-fehr]

Fix MLIRIRDL CMake requirements

[math-fehr]

It should be good now, I forgot dependencies in the CMake!

mlir/include/mlir/Dialect/CMakeLists.txt

 add_subdirectory(AMDGPU)
 add_subdirectory(AMX)
 add_subdirectory(Affine)
 add_subdirectory(Arith)
 add_subdirectory(ArmNeon)
 add_subdirectory(ArmSVE)
 add_subdirectory(Async)
 add_subdirectory(Bufferization)
 add_subdirectory(Complex)
 add_subdirectory(ControlFlow)
 add_subdirectory(DLTI)
 add_subdirectory(EmitC)
 add_subdirectory(Func)
 add_subdirectory(GPU)
 add_subdirectory(Index)
+add_subdirectory(IRDL)
 add_subdirectory(LLVMIR)
 add_subdirectory(Linalg)
 add_subdirectory(MLProgram)
 add_subdirectory(Math)
 add_subdirectory(MemRef)
 add_subdirectory(NVGPU)
 add_subdirectory(OpenACC)
 add_subdirectory(OpenMP)

mlir/include/mlir/Dialect/IRDL/CMakeLists.txt

+add_subdirectory(IR)

mlir/include/mlir/Dialect/IRDL/IR/CMakeLists.txt

+add_mlir_dialect(IRDL irdl)
+
+# Add IRDL operations
+set(LLVM_TARGET_DEFINITIONS IRDLOps.td)
+mlir_tablegen(IRDLOps.h.inc -gen-op-decls)
+mlir_tablegen(IRDLOps.cpp.inc -gen-op-defs)
+add_public_tablegen_target(MLIRIRDLOpsIncGen)
+add_dependencies(mlir-generic-headers MLIRIRDLOpsIncGen)
+
+# Add IRDL types
+set(LLVM_TARGET_DEFINITIONS IRDLTypes.td)
+mlir_tablegen(IRDLTypesGen.h.inc -gen-typedef-decls)
+mlir_tablegen(IRDLTypesGen.cpp.inc -gen-typedef-defs)
+add_public_tablegen_target(MLIRIRDLTypesIncGen)
+add_dependencies(mlir-generic-headers MLIRIRDLTypesIncGen)

mlir/include/mlir/Dialect/IRDL/IR/IRDL.h

+//===- IRDL.h - IR Definition Language dialect ------------------*- 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 declares the dialect for the IR Definition Language.
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef MLIR_DIALECT_IRDL_IR_IRDL_H_
+#define MLIR_DIALECT_IRDL_IR_IRDL_H_
+
+#include "mlir/Dialect/IRDL/IR/IRDLTraits.h"
+#include "mlir/IR/SymbolTable.h"
+#include "mlir/Interfaces/InferTypeOpInterface.h"
+#include "mlir/Interfaces/SideEffectInterfaces.h"
+#include <memory>
+
+// Forward declaration.
+namespace mlir {
+namespace irdl {
+class OpDef;
+class OpDefAttr;
+} // namespace irdl
+} // namespace mlir
+
+//===----------------------------------------------------------------------===//
+// IRDL Dialect
+//===----------------------------------------------------------------------===//
+
+#include "mlir/Dialect/IRDL/IR/IRDLDialect.h.inc"
+
+#define GET_TYPEDEF_CLASSES
+#include "mlir/Dialect/IRDL/IR/IRDLTypesGen.h.inc"
+
+#define GET_OP_CLASSES
+#include "mlir/Dialect/IRDL/IR/IRDLOps.h.inc"
+
+#endif // MLIR_DIALECT_IRDL_IR_IRDL_H_

mlir/include/mlir/Dialect/IRDL/IR/IRDL.td

+//===- IRDL.td - IR Definition Language Dialect ------------*- 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 declares the IR Definition Language dialect.
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef MLIR_DIALECT_IRDL_IR_IRDL
+#define MLIR_DIALECT_IRDL_IR_IRDL
+
+include "mlir/IR/OpBase.td"
+
+//===----------------------------------------------------------------------===//
+// IRDL Dialect
+//===----------------------------------------------------------------------===//
+
+def IRDL_Dialect : Dialect {
+  let summary = "IR Definition Language Dialect";
+  let description = [{
+    IRDL is an SSA-based declarative representation of dynamic dialects.
+    It allows the definition of dialects, operations, attributes, and types,
+    with a declarative description of their verifiers. IRDL code is meant to
+    be generated and not written by hand. As such, the design focuses on ease
+    of generation/analysis instead of ease of writing/reading.
+
+    Users can define a new dialect with `irdl.dialect`, operations with
+    `irdl.operation`, types with `irdl.type`, and attributes with
+    `irdl.attribute`.
+
+    An example dialect is shown below:
+
+    ```mlir
+    irdl.dialect @cmath {
+      irdl.type @complex {
+        %0 = irdl.is_type : f32
+        %1 = irdl.is_type : f64
+        %2 = irdl.any_of(%0, %1)
+        irdl.parameters(%2)
+      }
+
+      irdl.operation @mul {
+        %0 = irdl.is_type : f32
+        %1 = irdl.is_type : f64
+        %2 = irdl.any_of(%0, %1)
+        %3 = irdl.parametric_type : "cmath.complex"<%2>
+        irdl.operands(%3, %3)
+        irdl.results(%3)
+      }
+    }
+    ```
+
+    This program defines a `cmath` dialect that defines a `complex` type, and
+    a `mul` operation. Both express constraints over their parameters using
+    SSA constraint operations. Informally, one can see those SSA values as
+    constraint variables that evaluate to a single type at constraint
+    evaluation. For example, the result of the `irdl.any_of` stored in `%2`
+    in the `mul` operation will collapse into either `f32` or `f64` for the
+    entirety of this instance of `mul` constraint evaluation. As such,
+    both operands and the result of `mul` must be of equal type (and not just
+    satisfy the same constraint).
+
+    IRDL variables are handle over `mlir::Attribute`. In order to support
+    manipulating `mlir::Type`, IRDL wraps all types in an `mlir::TypeAttr`
+    attribute. The rationale of this is to simplify the dialect.
+  }];
+
+  let useDefaultTypePrinterParser = 1;
+
+  let name = "irdl";
+  let cppNamespace = "::mlir::irdl";
+}
+
+#endif // MLIR_DIALECT_IRDL_IR_IRDL

mlir/include/mlir/Dialect/IRDL/IR/IRDLOps.td

+//===- IRDLOps.td - IR Definition Language Dialect ---------*- 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 declares the IRDL dialect ops.
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef MLIR_DIALECT_IRDL_IR_IRDLOPS
+#define MLIR_DIALECT_IRDL_IR_IRDLOPS
+
+include "IRDL.td"
+include "IRDLTypes.td"
+include "mlir/Interfaces/SideEffectInterfaces.td"
+include "mlir/Interfaces/InferTypeOpInterface.td"
+include "mlir/IR/SymbolInterfaces.td"
+
+class IRDL_Op<string mnemonic, list<Trait> traits = []>
+    : Op<IRDL_Dialect, mnemonic, traits>;
+
+class AtMostOneChildOf<string op> : ParamNativeOpTrait<"AtMostOneChildOf", op>;
+
+//===----------------------------------------------------------------------===//
+// Dialect definition
+//===----------------------------------------------------------------------===//
+
+def IRDL_DialectOp : IRDL_Op<"dialect",
+    [IsolatedFromAbove, NoTerminator, Symbol, SymbolTable]> {
+  let summary = "Define a new dialect";
+  let description = [{
+    The `irdl.dialect` operation defines a dialect. All operations, attributes,
+    and types defined inside its region will be part of the dialect.
+
+    Example:
+
+    ```mlir
+    irdl.dialect @cmath {
+      ...
+    }
+    ```
+
+    The above program defines a `cmath` dialect.
+  }];
+
+  let arguments = (ins SymbolNameAttr:$sym_name);
+  let regions = (region SizedRegion<1>:$body);
+  let assemblyFormat =
+    "$sym_name attr-dict-with-keyword custom<SingleBlockRegion>($body)";
+  let hasVerifier = 1;
+}
+
+//===----------------------------------------------------------------------===//
+// Type and Attribute definition
+//===----------------------------------------------------------------------===//
+
+def IRDL_TypeOp : IRDL_Op<"type",
+    [HasParent<"DialectOp">, NoTerminator, NoRegionArguments,
+     AtMostOneChildOf<"ParametersOp">, Symbol]> {
+  let summary = "Define a new type";
+  let description = [{
+    `irdl.type` defines a new type belonging to the `irdl.dialect` parent.
+
+    The type parameters can be defined with an `irdl.parameters` operation in
+    the optional region.
+
+    Example:
+
+    ```mlir
+    irdl.dialect @cmath {
+      irdl.type @complex {
+        %0 = irdl.is i32
+        %1 = irdl.is i64
+        %2 = irdl.any_of(%0, %1)
+        irdl.parameters(%2)
+      }
+    }
+    ```
+
+    The above program defines a type `complex` inside the dialect `cmath`. The
+    type has a single parameter that should be either `i32` or `i64`.
+  }];
+
+  let arguments = (ins SymbolNameAttr:$sym_name);
+  let regions = (region SizedRegion<1>:$body);
+  let assemblyFormat =
+    "$sym_name attr-dict-with-keyword custom<SingleBlockRegion>($body)";
+}
+
+def IRDL_AttributeOp : IRDL_Op<"attribute",
+    [HasParent<"DialectOp">, NoTerminator, NoRegionArguments,
+     AtMostOneChildOf<"ParametersOp">, Symbol]> {
+  let summary = "Define a new attribute";
+  let description = [{
+    `irdl.attribute` defines a new attribute belonging to the `irdl.dialect`
+    parent.
+
+    The attribute parameters can be defined with an `irdl.parameters` operation
+    in the optional region.
+
+    Example:
+
+    ```mlir
+    irdl.dialect @testd {
+      irdl.attribute @enum_attr {
+        %0 = irdl.is "foo"
+        %1 = irdl.is "bar"
+        %2 = irdl.any_of(%0, %1)
+        irdl.parameters(%2)
+      }
+    }
+    ```
+
+    The above program defines an `enum_attr` attribute inside the `testd`
+    dialect. The attribute has one `StringAttr` parameter that should be
+    either a `"foo"` or a `"bar"`.
+  }];
+
+  let arguments = (ins SymbolNameAttr:$sym_name);
+  let regions = (region SizedRegion<1>:$body);
+  let assemblyFormat =
+    "$sym_name attr-dict-with-keyword custom<SingleBlockRegion>($body)";
+}
+
+def IRDL_ParametersOp : IRDL_Op<"parameters",
+    [ParentOneOf<["AttributeOp", "TypeOp"]>]> {
+  let summary =
+    "Define the constraints on parameters of a type/attribute definition";
+  let description = [{
+    `irdl.parameters` defines the constraints on parameters of a type or
+    attribute definition.
+
+    Example:
+
+    ```mlir
+    irdl.dialect @cmath {
+      irdl.type @complex {
+        %0 = irdl.is i32
+        %1 = irdl.is i64
+        %2 = irdl.any_of(%0, %1)
+        irdl.parameters(%2)
+      }
+    }
+    ```
+
+    The above program defines a type `complex` inside the dialect `cmath`. The
+    type has a single parameter that should be either `i32` or `i64`.
+  }];
+
+  let arguments = (ins Variadic<IRDL_AttributeType>:$args);
+  let assemblyFormat = " `(` $args `)` attr-dict ";
+}
+
+//===----------------------------------------------------------------------===//
+// IRDL Operation definition
+//===----------------------------------------------------------------------===//
+
+def IRDL_OperationOp : IRDL_Op<"operation",
+    [HasParent<"DialectOp">, NoTerminator, NoRegionArguments,
+    AtMostOneChildOf<"OperandsOp, ResultsOp">, Symbol]> {
+  let summary = "Define a new operation";
+  let description = [{
+    `irdl.operation` defines a new operation belonging to the `irdl.dialect`
+    parent.
+
+    Operations can define constraints on their operands and results with the
+    `irdl.results` and `irdl.operands` operations. If these operations are not
+    present in the region, the results or operands are expected to be empty.
+
+    Example:
+
+    ```mlir
+    irdl.dialect @cmath {
+
+      irdl.type @complex { /* ... */ }
+
+      irdl.operation @norm {
+        %0 = irdl.any
+        %1 = irdl.parametric @complex<%0>
+        irdl.results(%0)
+        irdl.operands(%1)
+      }
+    }
+    ```
+
+    The above program defines an operation `norm` inside the dialect `cmath`.
+    The operation expects a single operand of base type `cmath.complex`, and
+    returns a single result of the element type of the operand.
+  }];
+
+  let arguments = (ins SymbolNameAttr:$sym_name);
+  let regions = (region SizedRegion<1>:$body);
+  let assemblyFormat =
+    "$sym_name attr-dict-with-keyword custom<SingleBlockRegion>($body)";
+}
+
+def IRDL_OperandsOp : IRDL_Op<"operands", [HasParent<"OperationOp">]> {
+  let summary = "Define the operands of an operation";
+  let description = [{
+    `irdl.operands` define the operands of the `irdl.operation` parent operation
+    definition.
+
+    In the following example, `irdl.operands` defines the operands of the
+    `norm` operation:
+
+    ```mlir
+    irdl.dialect @cmath {
+
+      irdl.type @complex { /* ... */ }
+
+      irdl.operation @mul {
+        %0 = irdl.any
+        %1 = irdl.parametric @complex<%0>
+        irdl.results(%1)
+        irdl.operands(%1, %1)
+      }
+    }
+    ```
+
+    The `mul` operation will expect two operands of type `cmath.complex`, that
+    have the same type, and return a result of the same type.
+  }];
+
+  let arguments = (ins Variadic<IRDL_AttributeType>:$args);
+  let assemblyFormat = " `(` $args `)` attr-dict ";
+}
+
+def IRDL_ResultsOp : IRDL_Op<"results", [HasParent<"OperationOp">]> {
+  let summary = "Define the results of an operation";
+  let description = [{
+    `irdl.results` define the results of the `irdl.operation` parent operation
+    definition.
+
+    In the following example, `irdl.results` defines the results of the
+    `norm` operation:
+
+    ```mlir
+    irdl.dialect @cmath {
+
+      irdl.type @complex { /* ... */ }
+
+      irdl.operation @get_values {
+        %0 = irdl.any
+        %1 = irdl.parametric @complex<%0>
+        irdl.results(%0, %0)
+        irdl.operands(%1)
+      }
+    }
+    ```
+
+    The operation will expect one operand of the `cmath.complex` type, and two
+    results that have the underlying type of the `cmath.complex`.
+  }];
+
+  let arguments = (ins Variadic<IRDL_AttributeType>:$args);
+  let assemblyFormat = " `(` $args `)` attr-dict ";
+}
+
+//===----------------------------------------------------------------------===//
+// IRDL Constraint operations
+//===----------------------------------------------------------------------===//
+
+class IRDL_ConstraintOp<string mnemonic, list<Trait> traits = []>
+    : IRDL_Op<mnemonic, traits> {
+}
+
+def IRDL_Is : IRDL_ConstraintOp<"is",
+    [ParentOneOf<["TypeOp", "AttributeOp", "OperationOp"]>, Pure]> {
+  let summary = "Constraints an attribute/type to be a specific attribute instance";
+  let description = [{
+    `irdl.is` defines a constraint that only accepts a specific instance of a
+    type or attribute.
+
+    Example:
+
+    ```mlir
+    irdl.dialect @cmath {
+      irdl.type @complex_i32 {
+        %0 = irdl.is i32
+        irdl.parameters(%0)
+      }
+    }
+    ```
+
+    The above program defines a `complex_i32` type inside the dialect `cmath`
+    that can only have a `i32` as its parameter.
+  }];
+
+  let arguments = (ins AnyAttr:$expected);
+  let results = (outs IRDL_AttributeType:$output);
+  let assemblyFormat = " $expected ` ` attr-dict ";
+}
+
+def IRDL_Parametric : IRDL_ConstraintOp<"parametric",
+    [ParentOneOf<["TypeOp", "AttributeOp", "OperationOp"]>, Pure]> {
+  let summary = "Constraints an attribute/type base and its parameters";
+  let description = [{
+    `irdl.parametric` defines a constraint that accepts only a single type
+    or attribute base. The attribute base is defined by a symbolic reference
+    to the corresponding definition. It will additionally constraint the
+    parameters of the type/attribute.
+
+    Example:
+
+    ```mlir
+    irdl.dialect @cmath {
+
+      irdl.type @complex { /* ... */ }
+
+      irdl.operation @norm {
+        %0 = irdl.any
+        %1 = irdl.parametric @complex<%0>
+        irdl.operands(%1)
+        irdl.results(%0)
+      }
+    }
+    ```
+
+    The above program defines an operation `norm` inside the dialect `cmath` that
+    for any `T` takes a `cmath.complex` with parameter `T` and returns a `T`.
+  }];
+
+  let arguments = (ins SymbolRefAttr:$base_type,
+                       Variadic<IRDL_AttributeType>:$args);
+  let results = (outs IRDL_AttributeType:$output);
+  let assemblyFormat = " $base_type `<` $args `>` ` ` attr-dict ";
+}
+
+def IRDL_Any : IRDL_ConstraintOp<"any",
+    [ParentOneOf<["TypeOp", "AttributeOp", "OperationOp"]>]> {
+  let summary = "Accept any type or attribute";
+  let description = [{
+    `irdl.any` defines a constraint that accepts any type or attribute.
+
+    Example:
+
+    ```mlir
+    irdl.dialect @cmath {
+      irdl.type @complex_flexible {
+        %0 = irdl.any
+        irdl.parameters(%0)
+      }
+    }
+    ```
+
+    The above program defines a type `complex_flexible` inside the dialect
+    `cmath` that has a single parameter that can be any attribute.
+  }];
+
+  let results = (outs IRDL_AttributeType:$output);
+  let assemblyFormat = " attr-dict ";
+}
+
+
+#endif // MLIR_DIALECT_IRDL_IR_IRDLOPS

mlir/include/mlir/Dialect/IRDL/IR/IRDLTraits.h

+//===- IRDLTraits.h - IRDL traits definition ---------------------*- 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 declares the traits used by the IR Definition Language dialect.
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef MLIR_DIALECT_IRDL_IR_IRDLTRAITS_H_
+#define MLIR_DIALECT_IRDL_IR_IRDLTRAITS_H_
+
+#include "mlir/IR/OpDefinition.h"
+#include "mlir/Support/LogicalResult.h"
+#include "llvm/Support/Casting.h"
+
+namespace mlir {
+namespace OpTrait {
+
+/// Characterize operations that have at most a single operation of certain
+/// types in their region.
+/// This check is only done on the children that are immediate children of the
+/// operation, and does not recurse into the children's regions.
+/// This trait expects the Op to satisfy the `OneRegion` trait.
+template <typename... ChildOps>
+class AtMostOneChildOf {
+public:
+  template <typename ConcreteType>
+  class Impl
+      : public TraitBase<ConcreteType, AtMostOneChildOf<ChildOps...>::Impl> {
+  public:
+    static LogicalResult verifyTrait(Operation *op) {
+      static_assert(
+          ConcreteType::template hasTrait<::mlir::OpTrait::OneRegion>(),
+          "expected operation to have a single region");
+      static_assert(sizeof...(ChildOps) > 0,
+                    "expected at least one child operation type");
+
+      // Contains `true` if the corresponding child op has been seen.
+      bool satisfiedOps[sizeof...(ChildOps)] = {};
+
+      for (Operation &child : cast<ConcreteType>(op).getOps()) {
+        int childOpIndex = 0;
+        if (((isa<ChildOps>(child) ? false : (++childOpIndex, true)) && ...))
+          continue;
+
+        // Check that the operation has not been seen before.
+        if (satisfiedOps[childOpIndex])
+          return op->emitError()
+                 << "failed to verify AtMostOneChildOf trait: the operation "
+                    "contains at least two operations of type "
+                 << child.getName();
+
+        // Mark the operation as seen.
+        satisfiedOps[childOpIndex] = true;
+      }
+      return success();
+    }
+
+    /// Get the unique operation of a specific op that is in the operation
+    /// region.
+    template <typename OpT>
+    std::enable_if_t<std::disjunction<std::is_same<OpT, ChildOps>...>::value,
+                     std::optional<OpT>>
+    getOp() {
+      auto ops =
+          cast<ConcreteType>(this->getOperation()).template getOps<OpT>();
+      if (ops.empty())
+        return {};
+      return {*ops.begin()};
+    }
+  };
+};
+} // namespace OpTrait
+} // namespace mlir
+
+#endif // MLIR_DIALECT_IRDL_IR_IRDLTRAITS_H_

mlir/include/mlir/Dialect/IRDL/IR/IRDLTypes.td

+//===- IRDLTypes.td - IRDL Types ---------------------------*- 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 declares the types IRDL uses.
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef MLIR_DIALECT_IRDL_IR_IRDLTYPES
+#define MLIR_DIALECT_IRDL_IR_IRDLTYPES
+
+include "mlir/IR/AttrTypeBase.td"
+include "IRDL.td"
+
+class IRDL_Type<string name, string typeMnemonic, list<Trait> traits = []>
+    : TypeDef<IRDL_Dialect, name, traits> {
+  let mnemonic = typeMnemonic;
+}
+
+def IRDL_AttributeType : IRDL_Type<"Attribute", "attribute"> {
+  let summary = "IRDL handle to an `mlir::Attribute`";
+  let description = [{
+    This type represents a handle to an instance of an `mlir::Attribute`,
+    so it can be used in an IRDL operation, type, or attribute definition.
+    This type can also represent a handle to an instance of an `mlir::Type`,
+    by wrapping it in a `mlir::TypeAttr`. 
+
+    Example:
+
+    ```mlir
+    irdl.dialect cmath {
+
+      irdl.type @complex { /* ... */ }
+
+      irdl.operation @norm {
+        %0 = irdl.any
+        %1 = irdl.parametric @complex<%0>
+        irdl.operands(%1)
+        irdl.results(%0)
+      }
+    }
+    ```
+
+    Here, `%0` and `%1` are both of type `!irdl.attribute`. Note that in
+    particular, `%1` will be a handle to a `mlir::TypeAttr` wrapping an
+    instance of a `cmath.complex` type.
+  }];
+}
+
+#endif // MLIR_DIALECT_IRDL_IR_IRDLTYPES

mlir/include/mlir/InitAllDialects.h

 #include "mlir/Dialect/Bufferization/Transforms/FuncBufferizableOpInterfaceImpl.h"
 #include "mlir/Dialect/Complex/IR/Complex.h"
 #include "mlir/Dialect/ControlFlow/IR/ControlFlow.h"
 #include "mlir/Dialect/DLTI/DLTI.h"
 #include "mlir/Dialect/EmitC/IR/EmitC.h"
 #include "mlir/Dialect/Func/IR/FuncOps.h"
 #include "mlir/Dialect/GPU/IR/GPUDialect.h"
 #include "mlir/Dialect/GPU/TransformOps/GPUTransformOps.h"
+#include "mlir/Dialect/IRDL/IR/IRDL.h"
 #include "mlir/Dialect/Index/IR/IndexDialect.h"
 #include "mlir/Dialect/LLVMIR/LLVMDialect.h"
 #include "mlir/Dialect/LLVMIR/NVVMDialect.h"
 #include "mlir/Dialect/LLVMIR/ROCDLDialect.h"
 #include "mlir/Dialect/Linalg/IR/Linalg.h"
 #include "mlir/Dialect/Linalg/TransformOps/LinalgTransformOps.h"
 #include "mlir/Dialect/Linalg/Transforms/BufferizableOpInterfaceImpl.h"
 #include "mlir/Dialect/Linalg/Transforms/TilingInterfaceImpl.h"
registry.insert<acc::OpenACCDialect,
                   bufferization::BufferizationDialect,
                   cf::ControlFlowDialect,
                   complex::ComplexDialect,
                   DLTIDialect,
                   emitc::EmitCDialect,
                   func::FuncDialect,
                   gpu::GPUDialect,
                   index::IndexDialect,
+                  irdl::IRDLDialect,
                   LLVM::LLVMDialect,
                   linalg::LinalgDialect,
                   math::MathDialect,
                   memref::MemRefDialect,
                   ml_program::MLProgramDialect,
                   nvgpu::NVGPUDialect,
                   scf::SCFDialect,
                   omp::OpenMPDialect,

mlir/lib/Dialect/CMakeLists.txt

 add_subdirectory(Affine)
 add_subdirectory(AMDGPU)
 add_subdirectory(Arith)
 add_subdirectory(ArmNeon)
 add_subdirectory(ArmSVE)
 add_subdirectory(Async)
 add_subdirectory(AMX)
 add_subdirectory(Bufferization)
 add_subdirectory(Complex)
 add_subdirectory(ControlFlow)
 add_subdirectory(DLTI)
 add_subdirectory(EmitC)
 add_subdirectory(Func)
 add_subdirectory(GPU)
 add_subdirectory(Index)
+add_subdirectory(IRDL)
 add_subdirectory(Linalg)
 add_subdirectory(LLVMIR)
 add_subdirectory(Math)
 add_subdirectory(MemRef)
 add_subdirectory(MLProgram)
 add_subdirectory(NVGPU)
 add_subdirectory(OpenACC)
 add_subdirectory(OpenMP)

mlir/lib/Dialect/IRDL/CMakeLists.txt

+add_mlir_dialect_library(MLIRIRDL
+  IR/IRDL.cpp
+
+  DEPENDS
+  MLIRIRDLIncGen
+  MLIRIRDLOpsIncGen
+  MLIRIRDLTypesIncGen
+
+  LINK_LIBS PUBLIC
+  MLIRIR
+  )

mlir/lib/Dialect/IRDL/IR/IRDL.cpp

+//===- IRDL.cpp - IRDL dialect ----------------------------------*- C++ -*-===//
+//
+// This file is licensed 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
+//
+//===----------------------------------------------------------------------===//
+
+#include "mlir/Dialect/IRDL/IR/IRDL.h"
+#include "mlir/IR/Builders.h"
+#include "mlir/IR/BuiltinAttributes.h"
+#include "mlir/IR/DialectImplementation.h"
+#include "mlir/IR/ExtensibleDialect.h"
+#include "mlir/IR/OpDefinition.h"
+#include "mlir/IR/OpImplementation.h"
+#include "mlir/Support/LogicalResult.h"
+#include "llvm/ADT/STLExtras.h"
+#include "llvm/ADT/TypeSwitch.h"
+#include "llvm/IR/Metadata.h"
+#include "llvm/Support/Casting.h"
+
+using namespace mlir;
+using namespace mlir::irdl;
+
+//===----------------------------------------------------------------------===//
+// IRDL dialect.
+//===----------------------------------------------------------------------===//
+
+#include "mlir/Dialect/IRDL/IR/IRDL.cpp.inc"
+
+#include "mlir/Dialect/IRDL/IR/IRDLDialect.cpp.inc"
+
+void IRDLDialect::initialize() {
+  addOperations<
+#define GET_OP_LIST
+#include "mlir/Dialect/IRDL/IR/IRDLOps.cpp.inc"
+      >();
+  addTypes<
+#define GET_TYPEDEF_LIST
+#include "mlir/Dialect/IRDL/IR/IRDLTypesGen.cpp.inc"
+      >();
+}
+
+//===----------------------------------------------------------------------===//
+// Parsing/Printing
+//===----------------------------------------------------------------------===//
+
+/// Parse a region, and add a single block if the region is empty.
+/// If no region is parsed, create a new region with a single empty block.
+static ParseResult parseSingleBlockRegion(OpAsmParser &p, Region &region) {
+  auto regionParseRes = p.parseOptionalRegion(region);
+  if (regionParseRes.has_value() && failed(regionParseRes.value()))
+    return failure();
+
+  // If the region is empty, add a single empty block.
+  if (region.empty())
+    region.push_back(new Block());
+
+  return success();
+}
+
+static void printSingleBlockRegion(OpAsmPrinter &p, Operation *op,
+                                   Region &region) {
+  if (!region.getBlocks().front().empty())
+    p.printRegion(region);
+}
+
+LogicalResult DialectOp::verify() {
+  if (!Dialect::isValidNamespace(getName()))
+    return emitOpError("invalid dialect name");
+  return success();
+}
+
+#define GET_TYPEDEF_CLASSES
+#include "mlir/Dialect/IRDL/IR/IRDLTypesGen.cpp.inc"
+
+#define GET_OP_CLASSES
+#include "mlir/Dialect/IRDL/IR/IRDLOps.cpp.inc"

mlir/test/Dialect/IRDL/cmath.irdl.mlir

+// RUN: mlir-opt %s | mlir-opt | FileCheck %s
+
+module {
+  // CHECK-LABEL: irdl.dialect @cmath {
+  irdl.dialect @cmath {
+
+    // CHECK: irdl.type @complex {
+    // CHECK:   %[[v0:[^ ]*]] = irdl.is f32
+    // CHECK:   irdl.parameters(%[[v0]])
+    // CHECK: }
+    irdl.type @complex {
+      %0 = irdl.is f32
+      irdl.parameters(%0)
+    }
+
+    // CHECK: irdl.operation @norm {
+    // CHECK:   %[[v0:[^ ]*]] = irdl.any
+    // CHECK:   %[[v1:[^ ]*]] = irdl.parametric @complex<%[[v0]]>
+    // CHECK:   irdl.operands(%[[v1]])
+    // CHECK:   irdl.results(%[[v0]])
+    // CHECK: }
+    irdl.operation @norm {
+      %0 = irdl.any
+      %1 = irdl.parametric @complex<%0>
+      irdl.operands(%1)
+      irdl.results(%0)
+    }
+
+    // CHECK: irdl.operation @mul {
+    // CHECK:   %[[v0:[^ ]*]] = irdl.is f32
+    // CHECK:   %[[v3:[^ ]*]] = irdl.parametric @complex<%[[v0]]>
+    // CHECK:   irdl.operands(%[[v3]], %[[v3]])
+    // CHECK:   irdl.results(%[[v3]])
+    // CHECK: }
+    irdl.operation @mul {
+      %0 = irdl.is f32
+      %3 = irdl.parametric @complex<%0>
+      irdl.operands(%3, %3)
+      irdl.results(%3)
+    }
+
+  }
+}

mlir/test/Dialect/IRDL/testd.irdl.mlir

+// RUN: mlir-opt %s | mlir-opt | FileCheck %s
+
+// CHECK: irdl.dialect @testd {
+irdl.dialect @testd {
+  // CHECK: irdl.type @parametric {
+  // CHECK:   %[[v0:[^ ]*]] = irdl.any
+  // CHECK:   irdl.parameters(%[[v0]])
+  // CHECK: }
+  irdl.type @parametric {
+    %0 = irdl.any
+    irdl.parameters(%0)
+  }
+
+  // CHECK: irdl.type @attr_in_type_out {
+  // CHECK:   %[[v0:[^ ]*]] = irdl.any
+  // CHECK:   irdl.parameters(%[[v0]])
+  // CHECK: }
+  irdl.type @attr_in_type_out {
+    %0 = irdl.any
+    irdl.parameters(%0)
+  }
+
+  // CHECK: irdl.operation @eq {
+  // CHECK:   %[[v0:[^ ]*]] = irdl.is i32
+  // CHECK:   irdl.results(%[[v0]])
+  // CHECK: }
+  irdl.operation @eq {
+    %0 = irdl.is i32
+    irdl.results(%0)
+  }
+
+  // CHECK: irdl.operation @any {
+  // CHECK:   %[[v0:[^ ]*]] = irdl.any
+  // CHECK:   irdl.results(%[[v0]])
+  // CHECK: }
+  irdl.operation @any {
+    %0 = irdl.any
+    irdl.results(%0)
+  }
+
+  // CHECK: irdl.operation @dynbase {
+  // CHECK:   %[[v0:[^ ]*]] = irdl.any
+  // CHECK:   %[[v1:[^ ]*]] = irdl.parametric @parametric<%[[v0]]>
+  // CHECK:   irdl.results(%[[v1]])
+  // CHECK: }
+  irdl.operation @dynbase {
+    %0 = irdl.any
+    %1 = irdl.parametric @parametric<%0>
+    irdl.results(%1)
+  }
+
+  // CHECK: irdl.operation @dynparams {
+  // CHECK:   %[[v0:[^ ]*]] = irdl.is i32
+  // CHECK:   %[[v3:[^ ]*]] = irdl.parametric @parametric<%[[v0]]>
+  // CHECK:   irdl.results(%[[v3]])
+  // CHECK: }
+  irdl.operation @dynparams {
+    %0 = irdl.is i32
+    %3 = irdl.parametric @parametric<%0>
+    irdl.results(%3)
+  }
+
+  // CHECK: irdl.operation @constraint_vars {
+  // CHECK:   %[[v0:[^ ]*]] = irdl.any
+  // CHECK:   irdl.results(%[[v0]], %[[v0]])
+  // CHECK: }
+  irdl.operation @constraint_vars {
+    %0 = irdl.any
+    irdl.results(%0, %0)
+  }
+}

mlir/test/mlir-opt/commandline.mlir

 // CHECK-SAME: builtin
 // CHECK-SAME: cf
 // CHECK-SAME: complex
 // CHECK-SAME: dlti
 // CHECK-SAME: emitc
 // CHECK-SAME: func
 // CHECK-SAME: gpu
 // CHECK-SAME: index
+// CHECK-SAME: irdl
 // CHECK-SAME: linalg
 // CHECK-SAME: llvm
 // CHECK-SAME: math
 // CHECK-SAME: memref
 // CHECK-SAME: ml_program
 // CHECK-SAME: nvgpu
 // CHECK-SAME: nvvm
 // CHECK-SAME: omp