[Mlir-commits] [mlir] [mlir] Add loaded URI attribute type (PR #67276)

[Jacques Pienaar]

jpienaar wrote:

> I have to digest the rest of your post, I don't quite grasp completely the "registry on the attribute" part right now (and also why wouldn't `file://` be just one registered handler)

It would be, I just didn't add any registry yet. Didn't want to add mechanism while there is only one supported thing. 

> I think having a URI dialect makes sense, because then extensions can be registered and managed through the dialect itself, rather than building yet another extension system.

But would the extension look any different? We don't have open attribute system here nor would we want to have everyone modify upstream for their use downstream. So wouldn't the registry on the dialect look exactly the same? It would just change where the vector/map is stored (I mean I don't mind a different dialect and this is a nicer storage place, I just don't see how its avoiding an extra registry).

Adding ops for loading of different types and making the dialect extensible is an option, that uses existing registry mechanisms, and then one defines a folder per op. But then one needs a mechanism to ensure one doesn't load it multiple times (which probably ends up being a registry again, where here that registry is attribute key :) ).

I see this as a relatively simple thing, its a constant not stored in the IR. Its one that allows you to reference to multiple external files in one flow which the existing tooling could now how to interact with (note: this is probably true for a non-loaded URI string attribute too, it just makes for a simple linkage without much innovation)., and potentially opens door for something like elide-elementsattr-if-larger to actually produce output that is exact while not obscuring human readability.

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