[RFC] Dialect Fallback for OpInterface

MLIR
1

OpInterfaces are a great mechanism for MLIR extensibility, they allow for passes and analyses to query an Operation for some behaviors.
One limitation at the moment is that it requires every possible operation to be registered by a dialect ahead of time (on dialect loading).
The proposal here is to allow a dialect to act as fallback for operations that are in the dialect but not registered. It can enable implementers of a dialect to provide more extensibility (for example one could have a dialect allowing to define operations in Python and rely on the Python definition to provide metadata allowing to answer side-effects queries).
A concrete use-case for us is the TensorFlow dialect, which is open and dependent on another existing registration system for its operations. This fallback will allow to lookup this registry and still answer the queries for the OpInterfaces on behalf of all the operations in the dialect.

Here is the implementation: ⚙ D93085 Add a mechanism for Dialects to provide a fallback for OpInterface
Most of the code is in OpDefinition.h for the fallback, and Dialect.h for the new virtual method (getRegisteredInterfaceForOp) available for Dialects to override. Otherwise the rest of the patch is the TableGen support and the testing.

As an example, the TestOpEffectInterfaceFallback in TestDialect.cpp is used in the overridden TestDialect::getRegisteredInterfaceForOp to implement the interface for an unregistered operation.

2 Likes
2

+1 This looks useful for me. At times, I wanted to have all my dialect op implement a common OpInterface with a default implementation. This could save a bunch of TableGen churns.

3

But if I understand your comment correctly, this is possible via dialect interfaces:

4

I don’t think Dialect Interface solves my issue because it is not compatible with OpInterface. What I want is that I have OpInterface A, and some dialect B ops implements it while all the dialect C ops implement it in a common way. I think the Dialect Fallback can help implement the dialect C ops in one shot. Do I get it right?

5

Ah I should have clarified this in the initial description: yes the author of an interface can already achieve the same thing with DialectInterface. However, the situation is frequently that you are not the interface author and you need to provide an implementation for an existing interface, for example for SideEffects. These interfaces exists in-tree and are defined as OpInterface. The Dialect can’t use a DialectInterface to override these. So this kind of what this fallback bridges: some kind of DialectInterface that can acts as fallback implementation for existing OpInterface.

1 Like