XLA: the machine learning compiler behind PyTorch, TensorFlow and JAX
A machine learning compiler for GPUs, CPUs, and ML accelerators. XLA XLA (Accelerated Linear Algebra) is an open-source machine learning (ML) compiler for GPUs, CPUs, and ML accelerators.
At a glance
- What is it?
- XLA, Accelerated Linear Algebra, is the Apache-2.0 open source machine learning compiler for GPUs, CPUs and ML accelerators, taking models from PyTorch, TensorFlow and JAX and optimizing them for high-performance execution across hardware platforms. This repository is the compiler itself, intended for contributors and integrators rather than users, who consume XLA through their framework's own documentation.
- Who is it for?
- Use XLA indirectly, through PyTorch/XLA, TensorFlow's XLA support or JAX, if you want its compilation benefits for a model, since the framework documentation is the user surface and this repository is deliberately not it. Clone and build here only if you are contributing to the compiler or integrating a new ML frontend or hardware backend, the two audiences the README names.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 25, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A compiler with a deliberately short README
XLA, Accelerated Linear Algebra, is an open source machine learning compiler for GPUs, CPUs and ML accelerators, and its repository README is a model of scope discipline at under two hundred words. It states what the compiler takes and what it produces, models from popular ML frameworks such as PyTorch, TensorFlow and JAX, optimized for high performance execution across different hardware platforms, and then immediately tells most readers to go away, if you're not contributing code to the XLA compiler, you don't need to clone and build this repo. The two audiences it keeps are XLA contributors developing the compiler and XLA integrators debugging or adding support for ML frontends and hardware backends. That honesty is rare among infrastructure projects, and it works because the user facing documentation lives where the users already are, in the frameworks.
Users arrive through three frameworks
The get started section routes every user to their framework's own documentation, PyTorch through its XLA page, TensorFlow through its XLA guide, and JAX through its quickstart, the three frontends the compiler officially serves. This routing is the architectural statement, XLA is not a framework itself and does not want to be, it is the compilation layer underneath, and each frontend decides how models reach it, whether through explicit compilation calls, decorator annotations, or the framework's default execution path. The openxla.org website carries the project's public face, and the repository's README links it rather than duplicating content, keeping the compiler repository about the compiler.
OpenXLA governance, TensorFlow's rules
The governance section tells the project's origin compactly, while under TensorFlow governance, all community spaces for SIG OpenXLA are subject to the TensorFlow Code of Conduct, and the repository carries an AUTHORS file and Apache-2.0 license consistent with its Google lineage. The OpenXLA special interest group is the umbrella under which XLA and related projects live, with a community repository linked for resources, and maintainers reachable at maintainers at openxla.org, a plain email contact rather than a forum. For an infrastructure component this deep in the stack, the governance clarity matters to adopters, since the compiler's direction affects every framework built on it, and knowing who steers it is part of the dependency decision.
A Bazel build of serious scale
The repository's file listing shows the build system's weight, a Bazel MODULE and WORKSPACE alongside five numbered workspace bzl files, tensorflow.bazelrc and warnings.bazelrc configuration, a bazel_downloader.cfg for offline dependency control, and a configure.py script for local setup. Build tools, third party dependencies and the xla source directory itself sit as siblings, with kokoro and GitHub workflow directories handling continuous integration, and lock files for Python 3.11 and 3.12 requirements pinning the Python-facing side. The C++ primary language label and the clang-format, clang-tidy and clangd configuration files complete the picture of a large C++ codebase with enforced style, the kind of project where the build system is itself a contribution area.
Contribution paths, frontends and backends
Contribution is documented in two layers, a How to Contribute document followed by a developer guide, and the README's framing of who should read them matches the two integration surfaces. Contributors developing the compiler itself work in the xla source tree, while integrators adding support for ML frontends and hardware backends work at the boundaries, the place where new accelerators join the ecosystem and where framework teams debug how their graphs lower through the compiler. The distinction matters practically, a hardware vendor bringing up a new chip targets the backend interface, a framework team chasing a performance regression follows their models through the compilation pipeline, and both start from the same developer guide.
No releases, main is the product
There are no GitHub releases, and for this project that is the expected shape, since XLA ships to users inside framework releases, PyTorch wheels, TensorFlow builds and JAX packages, each carrying the compiler version they were built against. The main branch is the development stream, pushed as recently as 2026-09-25, and integrators track it through their own build processes rather than through tags. An AGENTS.md file sits at the root configuring coding agents for contribution work, a sign the project treats automated contributors as a normal part of its workflow, and a pre-commit configuration plus bant macros round out the contributor tooling.
Editorial conclusion
Use XLA indirectly, through PyTorch/XLA, TensorFlow's XLA support or JAX, if you want its compilation benefits for a model, since the framework documentation is the user surface and this repository is deliberately not it. Clone and build here only if you are contributing to the compiler or integrating a new ML frontend or hardware backend, the two audiences the README names. Before contributing, read the contributing document and developer guide, note the project operates under TensorFlow governance with its code of conduct, and expect a Bazel-based C++ build of substantial scale, with the working tree pushed as recently as 2026-09-25.
Frequently asked questions
What is open xla?
OpenXLA is the special interest group and project umbrella for open source ML compiler infrastructure, and XLA, Accelerated Linear Algebra, is its compiler for GPUs, CPUs and ML accelerators. It takes models from frameworks like PyTorch, TensorFlow and JAX and optimizes them for high-performance execution across hardware platforms, under Apache-2.0 with TensorFlow governance for community spaces.
What is Google XLA?
XLA, Accelerated Linear Algebra, is the machine learning compiler that originated at Google and is now developed openly in the openxla/xla repository under the Apache-2.0 license. It compiles models from PyTorch, TensorFlow and JAX for GPUs, CPUs and ML accelerators, and users typically access it through their framework's own XLA documentation rather than this repository.
Do you need to build XLA yourself?
No, and the README states it directly, if you are not contributing code to the XLA compiler you do not need to clone and build the repo. Users consume XLA through PyTorch/XLA, TensorFlow or JAX documentation, and the repository is for compiler contributors and integrators adding frontend or hardware backend support.