This is an archive of the discontinued LLVM Phabricator instance.

[PDLL] Add support for user defined constraint and rewrite functions
ClosedPublic

Authored by rriddle on Dec 15 2021, 6:28 PM.

Details

Summary

These functions allow for defining pattern fragments usable within the match and rewrite sections of a pattern. The main structure of Constraints and Rewrites functions are the same, and are similar to functions in other languages; they contain a signature (i.e. name, argument list, result list) and a body:

pdll
// Constraint that takes a value as an input, and produces a value:
Constraint Cst(arg: Value) -> Value { ... }

// Constraint that returns multiple values:
Constraint Cst() -> (result1: Value, result2: ValueRange);

When returning multiple results, each result can be optionally be named (the result of a Constraint/Rewrite in the case of multiple results is a tuple).

These body of a Constraint/Rewrite functions can be specified in several ways:

  • Externally

In this case we are importing an external function (registered by the user outside of PDLL):

pdll
Constraint Foo(op: Op);
Rewrite Bar();
  • In PDLL (using PDLL constructs)

In this case, the body is defined using PDLL constructs:

pdll
Rewrite BuildFooOp() {
  // The result type of the Rewrite is inferred from the return.
  return op<my_dialect.foo>;
}
// Constraints/Rewrites can also implement a lambda/expression
// body for simple one line bodies.
Rewrite BuildFooOp() => op<my_dialect.foo>;
  • In PDLL (using a native/C++ code block)

In this case the body is specified using a C++(or potentially other language at some point) code block. When building PDLL in AOT mode this will generate a native constraint/rewrite and register it with the PDL bytecode.

pdll
Rewrite BuildFooOp() -> Op<my_dialect.foo> [{
  return rewriter.create<my_dialect::FooOp>(...);
}];

Diff Detail

Event Timeline

rriddle created this revision.Dec 15 2021, 6:28 PM
rriddle requested review of this revision.Dec 15 2021, 6:28 PM
jpienaar accepted this revision.Jan 28 2022, 7:53 AM

Nice!

mlir/lib/Tools/PDLL/AST/NodePrinter.cpp
97

Is the ordering here (per block) useful?

181

Could we keep these sorted (per category)?

mlir/lib/Tools/PDLL/Parser/Parser.cpp
315

Mmm, "core" is a bit of an overloaded word. Is there a different word we could use & could you document what it means bove?

445

(don't we have a name uniquer thing somewhere that we could reuse here, or would that be too heavy weight?)

726

constraint

789

Left over debugging ? Or should this be an attached note on emit below?

mlir/test/mlir-pdll/Parser/constraint.pdll
75

nl

mlir/test/mlir-pdll/Parser/rewrite.pdll
59

nl

This revision is now accepted and ready to land.Jan 28 2022, 7:53 AM
rriddle updated this revision to Diff 406733.Feb 8 2022, 1:55 AM
rriddle edited the summary of this revision. (Show Details)
rriddle marked 8 inline comments as done.
rriddle added inline comments.Feb 8 2022, 1:55 AM
mlir/lib/Tools/PDLL/AST/NodePrinter.cpp
97

I had constraints grouped, and then others. (Fixed the ordering of constraints).

mlir/lib/Tools/PDLL/Parser/Parser.cpp
315

Core is the word I've been using in documentation and such to refer to the core set of constraints: Attr/Op/Type/etc., that have a correspondence to an IR construct. I can't think of anything that is as similarly overloaded (e.g. builtin?) to refer to this set of constraints, do you have anything?

445

Nothing I could find when looking, though I do remember something related to what you mention here. If you remember/find it, ping me and I'll see if we can use it here.

789

oops.