I’m curious what is the rationale for tying types to a particular dialect? Or if that’s not the case are there examples floating around of dialect agnostic types?
In particular I have an example where I have a custom type, which is then used by several different dialects internal to the project I’m working on. It’s not particularly clear which of these internal dialects this type should be registered under, which implies (at least to me) that it shouldn’t be registered under any of them.
Similarly, it looks like the BuiltIn dialect contains types with broad applicability, rather than say Tensor types living in the tensor dialect, so is the consensus in these instances to spin your own BuiltIn-like dialect?
We have types that are shared among different other dialects and use cases (e.g., Quantized is easiest example that comes to mind, MLProgram is also one but we aren’t far along enough there yet). Even if you look at TF dialect, some of its types are used by TFlite and argument could be made it go either side for some of them (and conceptually it could be split to a TSL one as the TF repo has also had TSL repo split out of it).
Conceptually all of these are in namespaces, there is no global namespace that one can use (Builtin is a bit special there in using non-prefixed form). So same way as one would structure libraries in a project, so too can one structure dialects/attributes/types. E.g., in C++ you’d also have types/structs in namespaces and one can use a type from one namespace in another.
Some common organization are around domain (e.g., types related to Foo go in dialect Foo), centrality (e.g., this dialect is what is the input and models the high-level domain kind) and then one can have a “util” dialect, but I’d consider that last option as its not very descriptive. Easiest start may be to look at your project, how are the libraries and dependencies layered and how that could map over.