Two engineers from Luminal, a compiler startup that recently closed its Series A, presented at an E-Graphs meetup on September 17 about how equality saturation powers their production tensor compiler. The talk by CEO Joe Fioti and founding compiler engineer Austin Glover offered a look at a real deployment of a technique that has mostly lived in academic papers until now.
Why Tensor Compilers Need a New Approach
Modern machine learning workloads are expressed as directed acyclic graphs of tensor operations. Multiply a matrix, apply an activation, reshape a tensor, chain them together. In the early days, these graphs were interpreted at runtime. That worked when models were small and inference latency was forgiving. It does not work when you need to run a large language model across eight GPUs and squeeze out every FLOP the hardware can deliver.
Production ML compilers now statically analyze these graphs and transform them into optimized implementations. The challenge is that the space of possible transformations is enormous. Fusing two operations, reordering computations, tiling for a specific GPU's memory hierarchy, choosing a kernel implementation for a matrix multiply. Each choice affects performance, and the effects are not modular. A transformation that helps in one part of the graph might hurt performance elsewhere, and the interactions are hard to predict without considering the whole program.
Traditional compilers handle this with a fixed pipeline of passes, each applying a sequence of rewrite rules. The order and selection of passes is tuned by compiler engineers, and the results depend heavily on getting that sequence right. For tensor programs, where the optimization space is large and hardware-specific, this approach becomes a maintenance burden. Every new accelerator or operator type requires hand-tuned pass orders.
Equality Saturation Separates Rules from Search
Luminal's approach uses equality saturation, a technique built on e-graphs. An e-graph is a data structure that compactly represents many equivalent versions of a program simultaneously. Instead of applying one rewrite and committing to it, the compiler applies all legal rewrites and lets them compose freely within the e-graph. The result is a single structure that contains, potentially, thousands of equivalent programs.
The key insight is that this separates two concerns. The first is defining which transformations are legal: fusing these two operations is valid, this reordering preserves semantics, that tiling factor works for this GPU. The second is finding the fastest program among all the legal alternatives. Equality saturation handles the first part through rewrite rules applied to the e-graph. The second part is handled by a cost function that evaluates candidates and selects the best one once the saturation process completes.
This separation matters for production compilers because it makes the optimization process more predictable and easier to extend. Adding a new rewrite rule does not require rethinking the entire pass schedule. The e-graph handles composition automatically. Testing whether a transformation is correct becomes a question of verifying a single rule rather than reasoning about its interaction with every other pass in a fixed pipeline.
Making Egglog Work at Scale
The tool Luminal uses is egglog, an extension of the egg equality saturation library that adds logical reasoning and datalog-style queries. egglog lets the compiler express more complex transformations than simple pattern matching, including transformations that require reasoning about types, shapes, or data dependencies across the graph.
Fioti and Glover described several practical challenges in applying this to real tensor programs. The e-graph can grow quickly as rewrites compose. Managing memory and keeping saturation tractable requires careful engineering around scheduling which rewrites to apply and when to stop. The cost model must account for hardware-specific factors like memory bandwidth, register pressure, and kernel launch overhead, not just operation count.
There is also the problem of correctness. Equality saturation guarantees that every program in the e-graph is equivalent to the original, but only if the rewrite rules themselves are correct. A buggy rule that incorrectly claims two programs are equivalent will silently produce wrong results. Building confidence in the rule set required extensive testing against reference implementations and real hardware.
What Production Results Look Like
Luminal is targeting GPU inference for large AI models, where the compiler must find implementations that maximize throughput while staying within memory constraints. The company describes its compiler as search-based: it automatically discovers high-performance implementations rather than relying on hand-written kernels.
The approach is particularly suited to the heterogeneity of modern accelerator hardware. A rewrite rule that tiles a matrix multiply differently for an NVIDIA H100 versus an AMD MI300 can coexist in the same rule set. The equality saturation process explores both paths and selects the one that fits the target hardware, without requiring separate compiler pipelines for each platform.
Fioti and Glover frame equality saturation as a natural fit for tensor compilation, but acknowledge open questions remain. The technique works well for the kinds of algebraic and structural rewrites common in tensor programs. Whether it scales to handle the full complexity of production ML workloads, including dynamic shapes, custom operators, and distributed execution, is an active area of development.
A Growing Team With Unfinished Work
Luminal recently closed its Series A and is hiring compiler engineers. The company's pitch is that ML compilation is stuck in a mode where performance requires extensive manual tuning, and that search-based compilation can make high performance more accessible across hardware platforms.
The presentation at the E-Graphs meetup signals that the company is investing in the research community around these techniques. egglog and equality saturation have been active areas of programming languages research, but production deployments remain rare. Luminal is one of the few companies putting this work into practice at scale, and the open questions they raised about cost modeling, rule correctness, and scalability reflect the gap between the theoretical elegance of e-graphs and the messy reality of shipping a compiler.