[doc] mlir-translate / mlir-opt

But this is isn’t actually great, and isn’t properly layered. To dive into a specific example, CIRCT is a collection of a bunch of different dialects with different communities (they each have/use different dialects that compose and mix in with the HW dialect). Your approach would work, but would entail registering the translation one time for each community, or one monolithic registration that links all the dialects that might be useful.

Why is this better than what I’m suggesting? The testing tools/ are implicitly monolithic already - they statically link a fixed set of stuff, by design. Their .cpp file should be the one that decides what that tool links in, it shouldn’t be the translations themselves doing it, and it shouldn’t be each of the clients of the translation redundantly registering the translation with different names.

-Chris

1 Like