Page MenuHomePhabricator

[mlir] Add support for "promised" interfaces
AcceptedPublic

Authored by rriddle on Feb 22 2022, 4:19 PM.

Details

Summary

Promised interfaces allow for a dialect to "promise" the implementation of an interface, i.e.
declare that it supports an interface, but have the interface defined in an extension in a library
separate from the dialect itself. A promised interface is powerful in that it alerts the user when
the interface is attempted to be used (e.g. via cast/dyn_cast/etc.) and the implementation has
not yet been provided. This makes the system much more robust against misconfiguration,
and ensures that we do not lose the benefit we currently have of defining the interface in
the dialect library.

Depends on D120367

Diff Detail

Event Timeline

rriddle created this revision.Feb 22 2022, 4:19 PM
Herald added a project: Restricted Project. · View Herald Transcript
rriddle requested review of this revision.Feb 22 2022, 4:19 PM
ormris removed a subscriber: ormris.Feb 24 2022, 10:06 AM
springerm accepted this revision.Mar 25 2023, 5:16 AM

This revision is already quite old now but I rebased the "promised interfaces" part (D146414) and it worked well. Would be great to get this landed. I'm preparing a stack of revisions for a new interface with external model impls (D145681) and it would benefit from this revision.

mlir/lib/Dialect/StandardOps/IR/Ops.cpp
24

This where the interface is defined. Based on the RFC (https://discourse.llvm.org/t/rfc-dialect-extensions-and-promised-interfaces/60451/3) I thought this dependency could be removed.

The only thing that is important is the type name of the interface (for the declarePromisedInterface API), which can be grabbed (e.g. via forward declaration) in ways such that you don’t depend on the library where the interface is defined.

But I think a forward declaration of the interface is not enough because it doesn't have the type ID of the interface. So this "promised interface" mechanism will not work for the BufferizableOpInterface which is defined in the bufferization dialect. Still, it would already improve the situation a lot for the majority of the interfaces, which are defined in mlir/Interfaces.

This revision is now accepted and ready to land.Mar 25 2023, 5:16 AM