[all-commits] [llvm/llvm-project] a56fd5: [mlir-translate] Add structured translation entry ...

[Anutosh Bhat via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: a56fd548f257c4fc89387ab2bb483acee7c59747
      https://github.com/llvm/llvm-project/commit/a56fd548f257c4fc89387ab2bb483acee7c59747
  Author: Anutosh Bhat <andersonbhat491 at gmail.com>
  Date:   2026-09-10 (Thu, 10 Sep 2026)

  Changed paths:
    M mlir/include/mlir/Tools/mlir-translate/MlirTranslateMain.h
    M mlir/lib/Tools/mlir-translate/MlirTranslateMain.cpp

  Log Message:
  -----------
  [mlir-translate] Add structured translation entry point (#222623)

Please read: [RFC: Embeddable LLVM tool drivers for long-lived
hosts](https://discourse.llvm.org/t/rfc-embeddable-llvm-tool-drivers-for-long-lived-hosts/91754)
and the [MLIR
section](https://discourse.llvm.org/t/rfc-embeddable-llvm-tool-drivers-for-long-lived-hosts/91754#p-367966-mlir-13).

`mlir-opt` already separates its standalone command-line frontend from
its reusable implementation:

```text
command-line parsing
        ↓
MlirOptMainConfig
        ↓
MlirOptMain(input buffer, output stream, registry, config)
```

`mlir-translate` currently combines those responsibilities inside
`mlirTranslateMain(int argc, char **argv, ...)`: it registers and parses
its command-line options, opens the input and output files, and then
performs the translations.

This patch applies the existing mlir-opt structure to mlir-translate. It
extracts the MLIR translation executor behind a structured overload
accepting an input buffer, output stream, selected Translation objects
and an MlirTranslateMainConfig. The existing command-line entry point
continues to parse the same options and delegates to the new overload,
so its command-line behaviour remains unchanged.

Separating parsing from execution is useful for any application
embedding MLIR. Such an application already has its input, output and
selected translation, and should not be required to install another
command-line frontend into the process merely to call MLIRTranslateLib.

[WasmBolt](https://github.com/anutosh491/WasmBolt)(try
[here](https://anutosh21.github.io/WasmBolt/)) is one concrete consumer.
It runs `mlir-opt`, `opt`, `llc`, Clang and LLD inside one long-lived
browser-hosted LLVM process. Calling the complete `mlir-opt` and
`mlir-translate` command-line frontends in that process causes common
options such as `-o` to be registered twice in LLVM's process-global
command-line registry.
```
mlir-translate: CommandLine Error: Option 'o' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
```

The structured entry point allows WasmBolt to invoke the actual MLIR
translation operation without registering another command-line frontend.
This is needed to continue naturally from the MLIR LLVM dialect to LLVM
IR inside the same compiler session.

Add a simple test where the test register its own `-o` option first,
then runs two translations through the new API and checks the output.
This confirms that the translation path works without touching the
command-line parser. **Can Improve it a bit if it looks too informal.**



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications