pliron: an extensible compiler IR framework in Rust, built to avoid C++

MLIR's ideas, without tablegen or C++

The description is one line and it is worth unpacking: an extensible compiler IR framework, in Rust, inspired by MLIR.

The inspiration is explicit in the readme, which links MLIR directly. What pliron takes from that lineage is the central idea of an extensible IR, where a core framework provides the operation and region machinery and specific languages or targets are added as dialects layered on top, rather than every project inventing its own ad hoc tree walking code.

What it does differently is the definition mechanism. In MLIR, dialects and their operations are described in a tablegen-like declarative language, and the C++ implementation inherits LLVM's build system and its toolchain expectations. pliron's take is that the dialect and operation definitions are ordinary Rust code, with a derive macro crate, pliron-derive, alongside the main crate. The repository listing shows the shape: src/ for the framework, pliron-derive/ for the procedural macros, pliron-llvm/ for the LLVM dialect, pliron-llvm/llvm-opt/ for the tool, plus a lints/ directory and a kaleidoscope/ directory.

There is a talk listed with the title Rust(ing) the Future of Compilers: Pliron as the MLIR Alternative (No C/C++), which tells you the pitch in the project's own words. The intent is not to be a smaller MLIR but to be the same idea for people who would rather stay in Rust.

The name is spelled out in the Cargo.toml as Programming Languages Intermediate RepresentatiON, and the workspace version is 0.20.0 with edition 2024 and an Apache-2.0 licence.

Building it and printing a bit of IR

The build requirements are minimal, and the readme says so directly.

You install the Rust toolchain, and then cargo build and cargo test build the compiler and run the test suite. There is no C++ dependency, no LLVM build to link, and no code generation step beyond what cargo does.

To see what the framework actually produces, the readme points at the print_simple test and gives the command.

      cargo test print_simple -- --show-output

And it shows what the output should look like.

  builtin.module @bar 
  {
    ^block1v1():
      builtin.func @foo: builtin.function <()->(builtin.integer si64)> 
      {
        ^entry_block2v1():
          c0_v0 = test.constant builtin.integer <0: si64> !0;
          test.return c0_v0
      }
  }

  outlined_attributes:
  !0 = [builtin_given_names = builtin.given_names [c0]]

This is worth reading as a design statement rather than as a test fixture. The output is in an MLIR-like textual form, with a module, named blocks, a function, a constant and a return, and it is a printing of the internal IR structure rather than a textual format the framework parses. Blocks carry versioned names, so ^block1v1() and ^entry_block2v1(), and attributes are outlined into a separate section with a numbered alias, which is the same approach MLIR uses to keep the body readable when attributes carry types and names.

So the readme is showing you the internal representation by printing it, and the print is close enough to MLIR syntax that a reader familiar with MLIR can read the shape of the IR immediately.

The main crates.io package is pliron, with documentation on docs.rs, and the crate is added to a Rust project as an ordinary dependency.

The LLVM dialect is the part that does something today

The pliron-llvm/ directory holds a full LLVM dialect, and pliron-llvm/llvm-opt/ holds a tool built on it. The readme states what the tool does: it can parse LLVM-IR bitcode into the LLVM dialect and output LLVM-IR bitcode.

That is the practical entry point for anyone evaluating the project, because it is the part that exists rather than the part that is planned.

The status section is candid about how far along it is. pliron is under active development, and every effort is made to ensure the code is well tested and of production quality. The LLVM dialect, although not complete, can be useful practically, and the readme gives two concrete proofs: it can compile bzip2 and lua and run their test suites. Both are already part of the llvm-opt test suite.

Compiling bzip2 and running its test suite is a much stronger statement than parsing a file. It means the dialect can carry a real program through the IR, through optimisation, and out to working machine code, and that the result has been checked against the upstream project's own tests. Lua is the same claim for a different kind of program.

There is also a plan stated: work on supporting a cranelift dialect and backend will start soon. That is the direction of travel, and it is the one that would make pliron a target rather than only a source dialect.

For learning, the readme points to a Kaleidoscope tutorial, and the repository has a kaleidoscope/ directory alongside examples/kaleidoscope/. Kaleidoscope is the classic LLVM tutorial language, so pliron is teaching compiler construction on top of its own framework, which is a good sign for how much of the framework is documented in a form a newcomer can follow.

The dependency list shows the scope of the framework

The Cargo.toml is worth reading, because the dependencies are the design in one place.

The numeric and data structure crates dominate. awint handles arbitrary width integers, which is what a compiler IR needs for target specific widths, and rustc_apfloat does the same for floating point. rustc-hash, hashbrown, indexmap and smallvec are the standard compiler workhorses for hashing and small vector storage. slotmap and once_vec provide stable addresses and lazy values, both of which an IR that hands out references needs. hi_sparse_bitset is for sets, downcast-rs for type aware downcasting of operation payloads, dyn-clone for cloneable trait objects, and regex because the framework does text matching on things like identifiers.

The framework's own error handling is thiserror, with combine as a parser combinator library, and log for diagnostics. utf8-chars is optional and is the only dependency of the std feature, which is on by default.

The std feature is the interesting switch. The default feature set is std, and the manifest says the spin crate is only used in no_std but cannot be expressed that way. So the framework is designed to compile without the standard library, which for a compiler IR is a meaningful constraint: it means the framework can be used in contexts where the standard library is not available, and it means the no_std build has to provide its own synchronisation primitives.

There is also a WebAssembly consideration. The manifest has a target specific dependency section for cfg(target_family = "wasm"), pulling in the inventory crate, and for everything else it uses linkme. Both of those are registration mechanisms for collecting implementations at link time, and having one for wasm and one for native is the detail that tells you the framework supports a web build.

The workspace members are pliron-derive, pliron-llvm and pliron-llvm/llvm-opt, so the derive macros, the LLVM dialect and the tool are versioned with the core. The release cadence is fast: v0.20.0 on 2026-10-17, v0.19.0 on 2026-10-06 and v0.18.0 on 2026-09-16, and the last push was on 2026-10-17.

Who is actually using pliron

The readme lists two projects built on pliron, and they are the most persuasive part of the document.

The first is cuda-oxide, NVIDIA's Rust CUDA compiler, from the NVlabs organisation. The second is cubecl, a multi platform high performance compute language extension for Rust, from tracel-ai. A GPU kernel compiler and a high performance compute language extension are both projects where the IR is the product rather than an intermediate step, and where the team writing the compiler is the team that has to live with the IR's ergonomics. That is exactly the kind of user pliron is designed for.

Additional dialects and projects built on pliron are hosted under the pliron-org GitHub organisation, so the dialect ecosystem is intended to be shared rather than kept private in one tree.

The conference talks and workshop sessions are worth noting for anyone assessing how serious the project is. There is a talk at IICT'24 on pliron as an extensible IR framework in Rust, one at IICT'25 on declarative IR specification in pliron, the No C/C++ talk, and a six session Pliron Rust Workshop. A framework that gets a workshop series and two conference talks has people teaching it, and that is a different kind of evidence from a repository with commits.

The community channels are a Discord server and GitHub Discussions, and the readme asks contributors to read CONTRIBUTING.md before opening a pull request, which is a small thing that says the project has a review process.

Where pliron is the wrong tool

There are four cases where this is the wrong choice, and the common thread is that pliron is a framework, and frameworks are only worth their cost when you are building something substantial.

The first is a project that just needs to read or write LLVM IR. pliron's LLVM dialect is described as not complete, so for a tool that parses a module, hands it to LLVM, and writes it back, using LLVM directly is simpler and more predictable. The value pliron offers is a framework for defining your own dialects and operations, and if you are not defining any, that value is unused.

The second is a team that needs MLIR specifically. If the goal is compatibility with the MLIR ecosystem, with its existing dialects, its pass manager, its tooling and its LLVM integration, then pliron is a reimplementation with a different definition mechanism, not a replacement. The readme frames it as an alternative, and an alternative to MLIR is a different project rather than the same project.

The third is a team that cannot absorb a fast moving 0.x. Three releases in a month, version 0.20.0, with the readme describing the project as under active development, means the API is still settling. For a research group experimenting with IR design, that is an advantage. For a production compiler that has to be maintained, it is a cost.

The fourth is a project with no interest in Rust. The framework is Rust and the derive macros are Rust, so adopting it means writing Rust even if the compiler you are building targets something else entirely.

On the alternative, the difference in approach against MLIR is the definition layer, and it is a real philosophical difference rather than a detail. MLIR uses tablegen, a declarative DSL with its own syntax, its own build integration and its own learning curve, and it inherits LLVM's C++ heritage throughout. pliron uses Rust code and procedural macros, so a dialect is a Rust type with a derive, and you get the type checker, the borrow checker, the editor tooling and the package manager rather than a separate description language with its own tooling. The trade is that MLIR's tablegen gives you a uniform way to describe and generate many dialects, while pliron gives you the full expressiveness of Rust at the cost of a per dialect compile step and a less uniform description format.

On the licence, the framework is Apache-2.0, and the repository root carries a NOTICE file alongside LICENSE.md and a Cargo.toml with the same licence declared. Apache-2.0 is a permissive licence with an explicit patent grant, which is what you want for a framework that a commercial toolchain is expected to build on.

Editorial conclusion

pliron suits a compiler engineer who wants a typed, extensible IR without committing to a C++ toolchain or to MLIR's tablegen workflow, and it does not suit a project that only needs to consume LLVM IR today, because the LLVM dialect is described as incomplete. Before you build on it, read the CONTRIBUTING.md file as the readme asks, check the Kaleidoscope tutorial to see how much of the framework you need to learn, and decide whether the dialect model matches your planned operations, since a 0.20 version with breaking changes between minor releases is still finding its shape.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. pliron-org/pliron on GitHub
3. Project website
4. README
5. Releases