Dyn project

[math-fehr]

This is the current draft patch for IRDL. It contains a minimal version of IRDL for now. It is not meant to be merged, but meant to prepare for an official patch.

Open TODOs

• Documentation of IRDL, and how it works
• Attributes
• One last pass on the code to make it clean
• Removing the unnecessary stuff that we do not want in the patch (i.e. variable constraints)

IRDL

IRDL is the "IR Definition Language", and similar to PDL, is meant to define IRs using a dialect. IRDL was presented during a MLIR ODM The following program can define a cmath dialect, with a complex type, and two operations, norm and mul.

  irdl.dialect cmath {

    irdl.type complex {
      irdl.parameters(elementType: AnyOf<f32, f64>)
    }

    irdl.operation norm {
      irdl.constraint_vars(T: AnyOf<f32, f64>)
      irdl.operands(c: cmath.complex<?T>)
      irdl.results(res: ?T)
    }

    irdl.operation mul {
      irdl.constraint_vars(T: AnyOf<f32, f64>)
      irdl.operands(lhs: cmath.complex<?T>, rhs: cmath.complex<?T>)
      irdl.results(res: cmath.complex<?T>)
    }
  }

Contrary to TableGen, IRDL defines dialects at runtime, using dynamic dialects.

Declarative type constraints

IRDL is defined as a dialect, and has operations to define types, attributes, operations, and dialects.
Each of these operations use type constraints to represent local constraints over parameters, operands, or results. These type constraints are represented with attributes, which are pretty-printed in a readable format.

For instance, AnyOf<T, U> represents a constraint satisfied either by types satisfying either the T or U constraint. It is internally represented by a irdl.any_of attribute. The supported constraints can be found in the IRDLAttributes.td file.

Additionally, it is possible to represent equality using constraint variables. This is an upgraded version of the AllTypesMatch trait that MLIR has:

    irdl.operation norm {
      irdl.constraint_vars(T: AnyOf<f32, f64>)
      irdl.operands(c: cmath.complex<?T>)
      irdl.results(res: ?T)
    }

In this example, T is defined as a constraint variable, and ensure that each of its uses has the same type. Also, this can be nested in another type, like in the norm operand.

Registering dialects

IRDL dialects can be registered, given an MLIRContext. This registers a new DynamicDialect, and register inside it dynamic operations, types, and attributes. Each type constraint is translated to a TypeConstraint, which contains the logic to verify the TypeConstraint. In the future, it will be possible to register at runtime new additional custom type constraints.

Handling C++-defined types

Since dynamic types and attributes have a list of Attribute parameters, IRDL can easily understand them. However, C++ or Tablegen defined types and attributes does not allow any introspection.
While IRDL can express an equality constraint with a C++-defined type (e.g. checking that a type is exactly i32), it cannot express something like "Any integer type". In order to do so, users need to register TypeWrapper, which constitute wrappers around types, so they are understood by IRDL. A TypeWrapper has this interface:

  /// Check if the given type is the one wrapped.
  virtual bool isCorrectType(mlir::Type t) = 0;

  /// Get the parameters of a type as attributes.
  /// The type should be the one wrapped, which is checked with `isCorrectType`.
  virtual llvm::SmallVector<mlir::Attribute> getParameters(mlir::Type t) = 0;

  /// Returns the type name, including the dialect prefix.
  virtual llvm::StringRef getName() = 0;

  /// Instanciates the type from parameters.
  virtual Type instantiate(llvm::function_ref<InFlightDiagnostic()> emitError,
                           llvm::ArrayRef<Attribute> parameters) = 0;

  /// Returns the amount of parameters the type expects.
  virtual size_t getParameterAmount() = 0;

In particular, users need to provide a name for each type, and a way to create them using a list of attribute parameters.

Current shortcuts / problems

• To register an IRDL file, we need a MLIRContext. So, we cannot use mlir-opt directly, and needed to define mlir-irdl-opt, which directly creates a dialect. The reason we currently need a context is because we need a context to create the IRDL program in the first place. Maybe having two contexts would work?
• Currently, we separate IRDL constraints between dynamic and wrapped C++ types. This duplicates a bit of code, and hopefully we can merge this with a single TypeWrapper that wraps both.
• We do not have support for attributes yet, but most likely we will have to duplicate all our code for the attribute constraints. Maybe we could think of a way to not duplicate that?