You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[mlir] Allow using non-attribute properties in declarative rewrite patterns (#143071)
This commit adds support for non-attribute properties (such as
StringProp and I64Prop) in declarative rewrite patterns. The handling
for properties follows the handling for attributes in most cases,
including in the generation of static matchers.
Constraints that are shared between multiple types are supported by
making the constraint matcher a templated function, which is the
equivalent to passing ::mlir::Attribute for an arbitrary C++ type.
Copy file name to clipboardExpand all lines: mlir/docs/DeclarativeRewrites.md
+13-2Lines changed: 13 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -380,6 +380,11 @@ template. The string can be an arbitrary C++ expression that evaluates into some
380
380
C++ object expected at the `NativeCodeCall` site (here it would be expecting an
381
381
array attribute). Typically the string should be a function call.
382
382
383
+
In the case of properties, the return value of the `NativeCodeCall` should
384
+
be in terms of the _interface_ type of a property. For example, the `NativeCodeCall`
385
+
for a `StringProp` should return a `StringRef`, which will copied into the underlying
386
+
`std::string`, just as if it were an argument to the operation's builder.
387
+
383
388
##### `NativeCodeCall` placeholders
384
389
385
390
In `NativeCodeCall`, we can use placeholders like `$_builder`, `$N` and `$N...`.
@@ -416,14 +421,20 @@ must be either passed by reference or pointer to the variable used as argument
416
421
so that the matched value can be returned. In the same example, `$val` will be
417
422
bound to a variable with `Attribute` type (as `I32Attr`) and the type of the
418
423
second argument in `Foo()` could be `Attribute&` or `Attribute*`. Names with
419
-
attribute constraints will be captured as `Attribute`s while everything else
420
-
will be treated as `Value`s.
424
+
attribute constraints will be captured as `Attribute`s, names with
425
+
property constraints (which must have a concrete interface type) will be treated
426
+
as that type, and everything else will be treated as `Value`s.
421
427
422
428
Positional placeholders will be substituted by the `dag` object parameters at
423
429
the `NativeCodeCall` use site. For example, if we define `SomeCall :
424
430
NativeCodeCall<"someFn($1, $2, $0)">` and use it like `(SomeCall $in0, $in1,
425
431
$in2)`, then this will be translated into C++ call `someFn($in1, $in2, $in0)`.
426
432
433
+
In the case of properties, the placeholder will be bound to a value of the _interface_
434
+
type of the property. For example, passing in a `StringProp` as an argument to a `NativeCodeCall` will pass a `StringRef` (as if the getter of the matched
435
+
operation were called) and not a `std::string`. See
436
+
`mlir/include/mlir/IR/Properties.td` for details on interface vs. storage type.
437
+
427
438
Positional range placeholders will be substituted by multiple `dag` object
428
439
parameters at the `NativeCodeCall` use site. For example, if we define
429
440
`SomeCall : NativeCodeCall<"someFn($1...)">` and use it like `(SomeCall $in0,
0 commit comments