[RFC] Composition-based Listener for RewriterBase

MLIR
1

Users can currently listen to IR modifications (op created, block created) through OpBuilder::Listener. There is no corresponding listener for RewriterBase. Instead users must derive from RewriterBase and override notify... functions to listen for notifications.

Proposal: Add a RewriterBase::Listener class (⚙ D143339 [mlir][WIP] RewriterBase: Use composition instead of inheritance for Listener).

  OpBuilder           OpBuilder::Listener
      ^                        ^
      |                        |
RewriterBase        RewriterBase::Listener

Benefits:

  • Simpler API and class structure: RewriterBase no longer inherits from OpBuilder::Listener. It now uses single inheritance instead of multiple inheritance. The listener is registered through composition instead of inheritance.
  • Consistent API: To listen for notifications on OpBuilders, a listener is used. With this change, RewriterBase follows the same design/API.
  • Prevent incorrect API usage: Since RewriterBase inherits from OpBuilder, a listener can be attached to RewriterBase, but that would bring the object into an inconsistent state where notifications are no longer delivered via RewriterBase::notifyOperationInserted etc. (This can also be fixed in other ways.)
  • Tracking IR changes in other components becomes easier. E.g., the GreedyPatternRewriteDriver can now broadcast IR modifications to an optional listener (⚙ D143340 [mlir][WIP] GreedyPatternRewriteDriver: Support optional Listener). There are use cases for this when using the transform dialect.

Related RFC: IR listeners ([RFC] Introduce the concept of IR listeners in MLIR) go one step further. They provide additional notifications independent of builders and rewrites, maybe making OpBuilder::Listener and RewriteBuilder::Listener obsolete. The present RFC can be seen more of a code refactoring; it does not add new notifications and is a first small improvement until we get to full IR listeners (or some other design).

3 Likes