Chatting with @River707 today we figured there is a lack of doc about some of the project fundamentals, in particular
mlir-translate. The former is involved in the Toy Tutorial, but not really explained as the tutorial assumes prior knowledge of LLVM (and so LLVM’s
opt). The chapter on exporting to LLVM IR involves calling the LLVM Translation but does not talk about
mlir-translate or the registrations.
I think we should add more doc about navigating the project structure but also the basic tools we are using their role.
Before I jump in and start documenting these, it also came up that we may not all be in sync with respect
mlir-translate differences, which despite their similarities are vastly different.
mlir-opt is a testing tool intended to exercise a pass or a sequence of passes. It always load some MLIR IR input and emit some other MLIR IR as output.
When extending it downstream, an entry point is exposed so that users can inject a
DialectRegistry to make available their own dialects (and interfaces) to the parser. Passes define the dialects they produce already.
mlir-translate has a less clear contract by nature: it intends to operates at the MLIR boundary, where it’ll tests functions that are either taking MLIR IR as input and producing “something else” (export) or taking “something else” as input and producing MLIR IR (import).
Even though there is a
main entry point like for the
*-opt tools, the export and import path have different API contracts. In particular, only the export case is concerned with parsing MLIR IR and the import case requires much less setup. Right now the registration for an export entry point (like
mlir-to-llvmir) can inject a DialectRegistry pre-parsing to define the set of inputs allowed.
This lead to a subtle but quite fundamental difference between the two tools and in particular the role of the registration for each of them: mlir-opt has a very controlled interface and passes with a narrow API (IR in / IR out) are registered while mlir-translate registers translation with an interface that much “raw” (process buffers). It is almost as if every translation registration define its own “subtool”!
It almost makes sense to me conceptually:
mlir-to-llvmir has not much in common to
mlir-to-bef (for TFRT).