{"id":13811669,"url":"https://github.com/tensorflow/mlir-hlo","last_synced_at":"2025-05-15T12:03:56.979Z","repository":{"id":37969645,"uuid":"280742424","full_name":"tensorflow/mlir-hlo","owner":"tensorflow","description":null,"archived":false,"fork":false,"pushed_at":"2025-05-14T23:03:25.000Z","size":62707,"stargazers_count":413,"open_issues_count":21,"forks_count":72,"subscribers_count":23,"default_branch":"master","last_synced_at":"2025-05-15T00:14:21.700Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"MLIR","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/tensorflow.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2020-07-18T21:28:18.000Z","updated_at":"2025-05-14T23:03:28.000Z","dependencies_parsed_at":"2023-09-25T13:41:53.683Z","dependency_job_id":"61b85304-9cbb-4704-9630-7275276ca8f8","html_url":"https://github.com/tensorflow/mlir-hlo","commit_stats":{"total_commits":5397,"total_committers":174,"mean_commits":"31.017241379310345","dds":0.6412821938113766,"last_synced_commit":"b82be64852501db477c0196bd5bf7cc40be7270b"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tensorflow%2Fmlir-hlo","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tensorflow%2Fmlir-hlo/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tensorflow%2Fmlir-hlo/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/tensorflow%2Fmlir-hlo/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/tensorflow","download_url":"https://codeload.github.com/tensorflow/mlir-hlo/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254337612,"owners_count":22054253,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-04T04:00:28.043Z","updated_at":"2025-05-15T12:03:51.965Z","avatar_url":"https://github.com/tensorflow.png","language":"MLIR","readme":"# MLIR-HLO: A Standalone \"HLO\" MLIR-based Compiler\n\nThe code here exists in two places:\n\n*   https://github.com/openxla/xla/tree/main/xla/mlir_hlo:\n    this is the canonical location and where contributions should be made using\n    GitHub pull-requests.\n*   **(DEPRECATED)** https://github.com/tensorflow/mlir-hlo; this is a\n    standalone repository with a view to the same code to allow other projects\n    to use this without depending on the entire XLA monorepo. This repository is\n    [slated for deletion](https://groups.google.com/a/openxla.org/g/openxla-discuss/c/Mppuv1Edv1s).\n    All dependencies on MHLO should go through XLA. Users of MHLO should migrate\n    to [StableHLO](https://github.com/openxla/stablehlo) whenever possible.\n\nThis implements a self-contained compiler for a linear algebra set of operations\ninspired by XLA\n[HLO IR](https://www.tensorflow.org/xla/architecture#how_does_xla_work) using\nMLIR components. It is designed to provide an end-to-end flow independent of\nTensorFlow and XLA, but usable inside of these projects.\n\nCoding practice and conventions in this repository follow the\n[MLIR Developer Guide](https://mlir.llvm.org/getting_started/DeveloperGuide/) in\nthis repo as part of the intent to act as an incubator for technology to\nupstream.\n\n## QuickStart: building and testing\n\nThese instructions work on Linux, you may have to adjust for your platform.\n\nTo build the code in this repository, you need a clone of the LLVM/MLIR git\nrepository:\n\n    $ git clone https://github.com/llvm/llvm-project.git\n\n\nYou need to make sure you have the right commit checked out in the LLVM\nrepository (you need to do this every time you pull from this repo):\n\n    $ (cd llvm-project \u0026\u0026 git checkout $(cat ../build_tools/llvm_version.txt))\n\nWe provide a script to configure and build LLVM/MLIR:\n\n    $ build_tools/build_mlir.sh ${PWD}/llvm-project/ ${PWD}/llvm-build\n\nAgain this is something to do every time you pull from this repository and the\nLLVM revision changes.\n\nFinally you can build and test this repository:\n\n    $ mkdir build \u0026\u0026 cd build\n    $ cmake .. -GNinja \\\n       -DLLVM_ENABLE_LLD=ON \\\n       -DCMAKE_BUILD_TYPE=Release \\\n       -DLLVM_ENABLE_ASSERTIONS=On \\\n       -DMLIR_DIR=${PWD}/../llvm-build/lib/cmake/mlir\n    $ ninja check-mlir-hlo\n\n\n## Overview\n\nMLIR-HLO aims to provide an end-to-end compiler for CPU and GPU, as well as\nbuilding reusable blocks for other accelerators. This is heavily inspired by the\nsuccess of XLA.\n\n[XLA](https://www.tensorflow.org/xla/) (Accelerated Linear Algebra) is a\ndomain-specific compiler framework and execution environment for linear algebra,\nwhich powers code-generation for ML frameworks like TensorFlow, JAX, and others.\n\nA cornerstone of XLA is the HLO (High Level Optimizer) IR, which offers a\ncarefully fixed selected list of operations, mostly orthogonal to each other. It\nprovides an efficient optimizer for computations expressed with this set of\noperations and generate codes for hardware platforms like CPU, GPU, and TPUs.\nIts goal is to provide a uniform interface to compile and execute these\noptimized HLO programs independently of the targeted device. It is not a\nfront-end ML system like TensorFlow or JAX, rather it is a backend framework\nthat optimizes HLO and lowers to machine code.\n\nThe HLO set of operations is closed and has well defined semantics. HLO\noperations operate on immutable Tensors with static shapes (actually bounded\nshapes to be exact) and explicit broadcasts.\n\n[MLIR](https://mlir.llvm.org/) is a compiler infrastructure which intends to\ncome with \"battery included\", as such it intends to provide all the blocks\nrequired to assemble graph optimization and codegen pipelines. The longer term\nroadmap for MLIR is to provide a\n[Tensor Compute Primitive](https://llvm.discourse.group/c/mlir/MLIR-TCP-WG/36)\n(TCP) dialect, which should hopefully be general enough to model what HLO\nrepresents today (see\n[slides](https://drive.google.com/open?id=1iljcpTQ5NPaMfGpoPDFml1XkYxjK_6A4) and\n[recording](https://drive.google.com/open?id=1jSPa8TwPKUt0WuLquGc8OgSUVYJHMvWZ)\nfor a technical discussion on this topic).\n\nThe work on MLIR-HLO can be seen as a stepping stone towards building TCP, while\nintegrating intermediate components into XLA itself by relying on the\nwell-proven HLO IR and introducing more pieces from upstream MLIR\n([Linalg](https://mlir.llvm.org/docs/Dialects/Linalg/),\n[Vector](https://mlir.llvm.org/docs/Dialects/Vector/),\n[GPU](https://mlir.llvm.org/docs/Dialects/GPU/) dialect, ...).\n[This document](https://www.tensorflow.org/mlir/xla_gpu_codegen?hl=zh-cn)\nprovides more information on the current migration of the XLA GPU codegen.\n\n## MLIR Dialects for XLA-style compilation\n\nThis repository defines three dialects to support a HLO-like compilation\npipeline using MLIR:\n\n*   `chlo`: the \"client\" HLO dialect, intended to be closer to the frontend\n    (including implicit broadcast semantics).\n*   `mhlo`: \"meta\"-HLO dialect ; similar to `xla_hlo`, but with extensions for\n    dynamic shape support.\n*   `lmhlo`: \"late\"-\"meta\"-HLO, it is the IR after buffer allocation is\n    performed. In XLA the buffer allocation is a side-data structure which keeps\n    track of these informations, while this separate dialect materializes it in\n    the IR.\n\nWe describe these in more details below.\n\n### HLO Client Dialect: `chlo`.\n\n*   It was originally designed to map the\n    [XLA client APIs](https://www.tensorflow.org/xla/operation_semantics) (e.g.,\n    ops supports implicit broadcast and roughly modeled on XlaBuilder API)\n    modulo support for dynamic shapes and additional ops required to support\n    dynamic client side HLOs.\n*   Ops can be from either the XlaBuilder or XLA helper functions can be\n    converted into ops (e.g., given ambiguity in what constitutes these ops,\n    there is some freedom to decide), the goal of this dialect is to correspond\n    close to client level and enable a thin layer between client use and op\n    construction (making it cheap to construct and optimizations on the dialect\n    close to optimizations on the client ops).\n\nEntry:\n\n*   The vast majority of old \"client\" interactions are via the XlaBuilder APIs.\n    These APIs are used by TF2XLA kernels, JAX, PyTorch bridge and directly. The\n    legalization path (described below) can also reuse the XlaBuilder's APIs to\n    construct XLA Client HLO ops directly (this uses MlirXlaBuilder which is a\n    subclass of XlaBuilder).\n*   The other entry point is during legalization from TensorFlow ops in the TF\n    Graph Compiler and other tools (e.g., SavedModel lowering and TFCompile).\n\nExit:\n\n*   MHLO\n*   May be exported to xla::HloInstructionProto by invoking the XlaBuilder APIs\n    (with regular XlaBuilder)\n\nThe `chlo` dialect started originally as mapping to the XLA client Builder APIs.\nIt enables it to both be constructed and converted back to existing XLA\ninterfaces using the XlaBuilder API. Due to the way that translation into and\nout of the dialect works, there is no expectation that this dialect roundtrips\nto XLA (e.g., it is only intended to be translated to MLIR and then legalized to\nanother dialect or translated to HloInstructionProto).\n\nThe export approach of reusing the XlaBuilders enables reusing a lot of logic\nthat was already implemented in terms of computing shapes, inserting broadcasts\netc.\n\nAn important topic here is that XLA Client HLO ops are not a well defined set.\nAnd in particular what some would consider helper functions, others would\nconsider ops. It should be easy to move between these and so define a new op\nalong with the helper function or autogenerate the helper functions from the\ndescriptions of the ops. For the former, a simple approach would be to simply\nconsider the context in which the op is being constructed and if an MLIR one,\nconstruct a op in the client dialect instead of further calls into XlaBuilder.\nThe latter could be implemented by adding the op and a legalization of the op to\nother known ops, from which a helper function can get generated that could be\nused as regular.\n\nabsl::Status: Exists but need to be cleaned up.\n\n### Meta HLO Dialect `mhlo`\n\n*   Dialect is closer to current HLO server ops (e.g., no implicit broadcast)\n*   MHLO dialect where we can deviate from the requirements of the client or\n    server dialect, in particular:\n    *   Control flow ops with implicit capture to enable simpler optimizations\n        (e.g., generic LICM, unroll \u0026 jam, etc.)\n    *   Multiple results ops (e.g., no tuples)\n    *   More ops (for example, unique op or assert op), and ops that don't need\n        to be added to either client or server dialect.\n    *   Op set not constrained by implementation (e.g., hlo.add operating on say\n        i79 or !mydialect.weird_type is allowed even though no XLA backend\n        supports it). Verification on types happening at the boundaries.\n    *   It does not need to preserve some deprecated XLA constructs (e.g.\n        stateful RNG HLO).\n    *   More dynamic shape support ops without need for updating all\n        users/backends.\n*   This dialect enables evolving HLO independently from XLA in order to\n    experiment with features we'd like to upstream in MLIR TCP. In particular it\n    intends to be user-extensible through\n    [interfaces](https://mlir.llvm.org/docs/Interfaces/).\n*   It should have no TensorFlow, or proto, or other Google internal\n    dependencies.\n*   It need not be a complete superset of ops compared to XLA HLO dialect.\n\nEntry:\n\n*   Legalization from `chlo` dialect or conversion from XLA HLO.\n*   Directly emitted from TF Graph Compiler;\n*   Builder call (e.g., EDSL);\n\nExit:\n\n*   LMHLO, Linalg IREE, directly used in codegen.\n*   XLA HLO.\n\nThe MHLO dialect has no direct export format, it is only meant as an\nintermediate optimization dialect/format. It is also where we can experiment\ncheaply with new ops. This format will be where the representation would differ\nfrom existing endpoints.\n\nabsl::Status: Exists but need to be cleaned up and evolved, in particular with respect\nto supporting dynamic shapes.\n\nMHLO differs from XLA HLO op set in multiple ways, including:\n1. MHLO While accepts multiple operands and may produce multiple results\n   instead;\n\n### LMHLO\n\nLMHLO corresponds to late `mhlo` and operates on buffer domain (e.g., memref)\nwith side-effecting operations. The lowering from `mhlo` dialect proceeds by way\nof scheduling, memory and buffer allocation. The current mapping is directly on\nXLA Client HLOs but without implicit broadcast and with operation on memrefs.\nThis dialect will instead be rebased on `mhlo` dialect but operating on buffers\nstill.\n\nEntry:\n\n*   Post buffer assignment on `mhlo` dialect, or from XLA after buffer\n    assignment.\n\nExit:\n\n*   Codegen (LLVM IR in the common cases at the moment)\n\n## End-to-End pipeline\n\nTODO\n\n## Alternative build setups\n\n### Building Python API\n\nBuilding the MHLO Python API requires building as an LLVM external project.\nThe below instructions presume that you have this `mlir-hlo` repo and an\n`llvm-project` repo checked out side by side.\n\nNote that the python package produced by this procedure includes the `mlir`\npackage and is not suitable for deployment as-is (but it can be included into\na larger aggregate).\n\n```\nmkdir build \u0026\u0026 cd build\ncmake -GNinja -B. ${LLVM_SRC_DIR}/llvm \\\n    -DCMAKE_BUILD_TYPE=Release \\\n    -DLLVM_ENABLE_PROJECTS=mlir \\\n    -DLLVM_EXTERNAL_PROJECTS=mlir_hlo \\\n    -DLLVM_EXTERNAL_MLIR_HLO_SOURCE_DIR=${MLIR_HLO_SRC_DIR} \\\n    -DLLVM_TARGETS_TO_BUILD=host \\\n    -DPython3_EXECUTABLE=$(which python) \\\n    -DMLIR_ENABLE_BINDINGS_PYTHON=ON \\\n    -DMHLO_ENABLE_BINDINGS_PYTHON=ON\n\nninja MLIRHLOPythonModules\nexport PYTHONPATH=$PWD/tools/mlir_hlo/python_packages/mlir_hlo\npython -c \"import mlir.dialects.mhlo\"\n```\n\n## External projects that depend on mlir-hlo\n\nExternal projects that need to depend on `mlir-hlo` (for example via a git\nsubmodule) can use the following setting in their cmake configuration in order\nfor `find_package(MHLO)` to import all mlir-hlo cmake targets into their build\nsetup and have access to the required include and lib variables (see generated\n`MHLOConfig.cmake`).\n\n```\n...\n   -DMHLO_DIR=\u003cpath to mlir-hlo build dir\u003e/lib/cmake/mlir-hlo\n   ...\n```\n","funding_links":[],"categories":["Implements based on the underlying LLVM/MLIR compiler technology"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftensorflow%2Fmlir-hlo","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ftensorflow%2Fmlir-hlo","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftensorflow%2Fmlir-hlo/lists"}