[Mlir-commits] [mlir] [mlir] Declare promised interfaces for all dialects (PR #78368)

[Oleksandr Alex Zinenko]

ftynse wrote:

>> I'm not sure having a promised interface for the builtin dialect even makes sense. If there is an interface that needs to be added to builtin, I suppose the place that defines the interface should immediately register it.
>
> I don't follow why?

Assuming it's not the dialect itself that declares the promise, I don't see the point of promising the interface here. It will just require two actions for it to be usable (promise and registration) instead of just one.

>> Builtin is always loaded in the context and lives in lib/IR so pretty much everything depends on it.
>
> But the logic remains the same as for the other dialects: if I don't plan to use the transformation that requires interface Foo, why would I need to have the implementation for interface Foo automatically present in my binary and loaded with the builtin dialect?

Then why would you have the interface itself to start with? Just don't have it in the binary and don't load the implementation.

> We frequently have this kind of header-only dependency forming cycles across libraries, why is this a problem?

I think we removed most of these. This is acceptable for cmake rules, less so in terms of the conceptual dependency graph. (Header-)Depending on `Tensor/TransformOps` just makes the dependency on `Transform/IR` transitive and adds a cycle without really addressing the issue of depending on the transform dialect.

https://github.com/llvm/llvm-project/pull/78368