Sunsetting the MLIR-HLO repository

Hi everyone,

We wanted to post an update about the future of the MLIR-HLO repository. We understand that MLIR-HLO is not an officially supported MLIR project but it has been around long enough that we’d like to increase visibility as to its status.

The MLIR-HLO repository was created in July 2020 to “provide an end-to-end compiler for CPU and GPU, as well as building reusable blocks for other accelerators […] heavily inspired by the success of XLA”. It had a rich history, and these days it serves as a community hub, upstream from IREE, ONNX-MLIR, Torch-MLIR and other repositories.

In our experience, the primary usefulness of MLIR-HLO lies in providing direct access to: 1) the MHLO dialect that can serve as a portability layer between ML frameworks and ML compilers, 2) MHLO passes, e.g. hlo-legalize-to-linalg, which connect MHLO to the larger ecosystem. We have seen both used successfully in multiple projects.

The MLIR-HLO repository was useful as a scrappy way of bootstrapping shared infrastructure, but making it robust required quite a bit of work. To address this, we have created StableHLO to provide a solid portability layer, and started the OpenXLA project to provide a home for a community-driven, open source ML compiler ecosystem, with the goal of having a great story for development workflow, continuous integration, etc.

With StableHLO hitting v0.9 in March, and IREE recently moving to OpenXLA, we are now at a stage where Google would like to wind down the development effort and support of the separate MLIR-HLO repository. Recent migrations of JAX and Torch-MLIR show that StableHLO can easily fill the role of MHLO as a portability layer.

With that in mind, we wanted to reach out to you all. MLIR-HLO has been around for so long that we aren’t clear on who is using it. Please let us know what you think and how we can make this transition easier for you.

Cheers,
Eugene & Jacques

3 Likes

As far as I can see, stablehlo is missing a cmake configuration for external projects, which mlir-hlo has had (mlir-hlo/cmake/modules at master · tensorflow/mlir-hlo · GitHub). Otherwise, it looks like projects could just easily switch to stablehlo.

1 Like

“As far as I can see, stablehlo is missing a cmake configuration for external projects”. That’s a good point! Direct dependencies on the StableHLO repository already work through Bazel, but CMake support is indeed missing at the moment. I’ve just opened a ticket to get this done: Add a CMake configuration for external projects · Issue #1549 · openxla/stablehlo · GitHub.

Another question that has come up lately during discussions of the future of the MLIR-HLO repository is what is going to happen to MHLO => Linalg passes. These passes are available through the XLA repository, but some folks have been looking for something more lightweight.

In a recent OpenXLA RFC, we’re discussing migrating these passes to use StableHLO and upstreaming them to the StableHLO repository. The actual migration has been prototyped in the IREE repository and is almost done, so we know that it is feasible, and this functionality will soon be readily available. Please chime in if you have an opinion on this!

1 Like

As a heavy user of mlir-hlo, as far as I can see, your post has covered everything. Thanks very much! It’s definitely important to ensure the paths from mhlo into MLIR official repo dialects are now subsumed by functionally equivalent conversions from stablehlo to MLIR dialects.