I worked on a solution to be able to track all IR mutations by attaching “listeners” to an Operation directly. At the moment we built some infrastructure for listeners around the Rewriter (and relevant subclasses). This allows to keep track of most IR mutations, but require the clients to ensure tha…

[image] rengolin: Listeners are in a sweat spot where the coupling isn’t mandatory, but if you have it, it’s useful, like metadata in IR. But it also has the same problems as metadata: you need to add the right stuff, keep it up-to-date with the rest of the infra consumers need to know what t…

I would expect listener not attached to any operation to be useful for “automated” analysis updates. for example every analysis could provide there updater/listener. Transformation passes could register listeners for the analysis they use in the IRRewriter used to edit the IR. This would allow sha…

[image] tyker: also it is possible to edit IR without going through a rewriter (which I dislike). is this intentional or should we get rid of that ? Well this is kind of a major part of issue: the Rewriter is not the main way of editing IR, instead Rewriter is a temporary object that is right…

[image] mehdi_amini: For example what does it mean that “some producers will be more diligent than others”? Are you talking about my proposal or referring to the “Rewriter” instead? That may have been a tangent I followed… I’m talking about the usage of your proposal, not the proposal itself…

[image] rengolin: If those frameworks (built on top of listeners) become official in MLIR, for example to have a more resistant form of metadata, then what the listener does when encountering change will directly impact the quality of such metadata. This is what I meant by being “diligent”. G…

[image] mehdi_amini: Got it I think: you used “producer” because these listeners are “producing” updated “metadata” right? (You were a step further than me: for the listener at on the “receiving” end of an IR modification). Correct! :slight_smile:

I think the concept of IR listener is needed but I don’t really like the fact that it is local to every operation. have you considered that the listener could be on every op that is IsolatedFromAbove. when an operation is modified, it would notify the listener on the closest parent that is Isolated…

No I haven’t considered this, I’m a bit worried of the cost though: now whether there is a listener or not you need to walk back to the closest isolated parent. Every op->getParentOp() is 3 pointers to chase I believe: getParentBlock()->getRegion()->getParent() and you may have to go more than one …

No I haven’t considered this, I’m a bit worried of the cost though: now whether there is a listener or not you need to walk back to the closest isolated parent. Every op->getParentOp() is 3 pointers to chase I believe: getParentBlock()->getRegion()->getParent() and you may have to go more than one…

[RFC] Introduce the concept of IR listeners in MLIR

MLIR

mehdi_amini February 15, 2023, 9:39pm 20

Related work in LLVM: [RFC] Lightweight LLVM IR Checkpointing

Topic		Replies	Views
Utility to create a list MLIR Mutations after a transform MLIR	0	393	February 25, 2023
How to track all additions/removals of operations in a robust way? MLIR	3	145	March 18, 2026
Exposing transform mutation tracking and "rollback" capabilities MLIR	2	652	March 23, 2023
[RFC] ValueDeletionListener: context-level Value deletion notifications IR & Optimizations llvm	35	972	June 10, 2026
[RFC] Lightweight LLVM IR Checkpointing IR & Optimizations	43	3164	March 8, 2023

[RFC] Introduce the concept of IR listeners in MLIR

Related topics