[Mlir-commits] [mlir] [mlir][canonicalize] Add filter-dialects option (PR #193041)

[Oleksandr Alex Zinenko]

ftynse wrote:

> Only if it is the same dialect though: trying to register a dialect with the same name but different TypeID isn't OK.
So if we were unifying the map, then we need to account for registering a dialect by name which would introduce an entry without a TypeID followed by a registration of a dialect with a TypeID which should override it. This is the kind of logic I was referring to, hardening things is a bit more complex when you have an "Optional" value (right now the pointer isn't "optional", we'd change it to it by allowing null).

Thanks for the clarification! Yes, I agree that the hardening may require some extra logic. But it looks conceptually the same as having a separate set for name-only. If we have a name-only entry and add an entry with TypeID, we are "overriding" the existing name-only entry. 

> I didn't follow what you mean with the getter and warning? How is this limited to canonicalization right now and not just generally applicable to any pass?

The logic reporting that some name-only dialects were not loaded is in the canonicalization pass https://github.com/llvm/llvm-project/pull/193041/changes#diff-24c439856657c21d9349ca96ddd262013984be3ac107d8d4c0c7dc998eb68162R62-R71. I'd want it in the DialectRegistry or MLIRContext, or maybe pass manager. E.g., run the same check right after we collected all dependent dialects from passes we are about to run. Otherwise, each pass will have to copy the logic that the canonicalization pass currently has.

I was thinking about having `DialectsRegistry::getDialectAllocator` error out / intentionally signal that the dialect in question is name-only and the constructor was never provided, as opposed to being missing from the mapping entirely, but we may also just have dialects be loaded directly without going through the registry, so I suppose that won't fly.

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