[RFC] MLIR interpreter framework

[mehdi_amini]

@stellaraccident

My issue from the beginning with this proposal is that it conflates three things:

1. Should MLIR have a generic “SSA level interpreter” framework? [Seems to be enough pushback on this that we can say “no”]
2. Is there utility in domain/case specific reference models like the specific case behind the proposal? [Many cautionary tales but also opinions that there is value that justifies the cautions]
3. Should such a thing be upstream? [Strong arguments against, but there may be value if the people who work on these things for some of the limited domains found each other]

I was out for a few weeks and it is hard to unravel the thread. I have a hard time understanding the push back to have something like this as part of the MLIR libraries:

1. Maintenance: a long as this is decoupled from the IR and dialects, this is “free”. That is: the interpreter infrastructure does not put any weight on the rest of MLIR.
   It is another story in terms of whether a given dialect gets an implementation of a reference execution for its ops.
2. Runtime cost: again as long as it is decoupled, you don’t pay for it if you don’t use it (it should not even link into your binary)
3. Usage: providing the generic way to keep track of SSA state, liveness of values and alloc/dealloc, driving the execution, including providing traces/etc.seems like entirely reusable by clients. That means that even if we don’t have any upstream dialect providing an implementation, that does not eliminate the value of this infrastructure.

So I’m quite distress by the unreasonable barrier to entry that I perceive here: most of MLIR (I would even say MLIR itself) couldn’t exist with this kind of approach (some arguments here looks like FUD to me and very similar the kind of things people were saying when MLIR was started in the first place: both about how “impossible” things are or how not useful it will be).
This infra seems instead very much in line with how we grew the project.

That’s not to say that the implementation is perfect and I think there are challenges (using OpInterface may not be suitable, we should think more about type extensibility, having the ability to overload implementations and have the framework dispatch, etc.). But we can separate the concept from the implementation when discussing how to integrate this in MLIR.

Finally something else I would be interesting to think about is how we could revamp constant folding into a more complete “partial evaluator”, there may be some opportunities there. I would be concerned if some dialects implementors would end up duplicating the “reference implementation” between the folders and an interpreter.