{"title":"cfallin.org","link":[{"@attributes":{"rel":"self","type":"application\/atom+xml","href":"https:\/\/cfallin.org\/feed.xml"}},{"@attributes":{"rel":"alternate","type":"text\/html","href":"https:\/\/cfallin.org"}}],"generator":"Zola","updated":"2026-05-06T11:47:46.790056103-07:00","id":"https:\/\/cfallin.org\/feed.xml","entry":[{"title":"The acyclic e-graph: Cranelift's mid-end optimizer","published":"2026-04-09T00:00:00+00:00","updated":"2026-04-09T00:00:00+00:00","author":{"name":{}},"link":{"@attributes":{"rel":"alternate","type":"text\/html","href":"https:\/\/cfallin.org\/blog\/2026\/04\/09\/aegraph\/"}},"id":"https:\/\/cfallin.org\/blog\/2026\/04\/09\/aegraph\/","content":"

Today, I'll be writing about the aegraph<\/em>, or acyclic egraph<\/em>, the\ndata structure at the heart of Cranelift's mid-end optimizer. I\nintroduced this approach in\n2022<\/a>\nand, after a somewhat circuitous path involving one full rewrite, a\nnumber of interesting realizations and \"patches\" to the initial idea,\nvarious discussions with the wider e-graph community (including a\ntalk<\/a>\n(slides<\/a>)\nat the EGRAPHS workshop at PLDI\n2023<\/a> and a recent talk\nand discussions at the e-graphs Dagstuhl\nseminar<\/a>),\nand a whole bunch of contributed rewrite rules over the past three\nyears<\/a>,\nit is time that I describe the why<\/em> (why an e-graph? what benefits\ndoes it bring?), the how<\/em> (how did we escape the pitfalls of full\nequality saturation? how did we make this efficient enough to\nproductionize in Cranelift?), and the how much<\/em> (does it help? how\ncan we evaluate it against alternatives?).<\/p>\n

For those who are already familiar with Cranelift's mid-end and its\naegraph, note that I'm taking a slightly different approach in this\npost. I've come to the viewpoint that the \"sea-of-nodes\" aspect of our\naegraph, and the translation passes we've designed to translate into\nand out of it (with optimizations fused in along the way), are\nactually more fundamental than the \"multi-representation\" part of the\naegraph, or in other words, the \"equivalence class\" part itself. I'm\nchoosing to introduce the ideas from sea-of-nodes-first in this post,\nso we will see a \"trivial eclass of one enode\" version of the aegraph\nfirst (no union nodes), then motivate unions later. In actuality, when\nI was experimenting then building this functionality in Cranelift in\n2022, the desire to integrate e-graphs came first, and aegraphs were\ncreated to make them practical; the pedagogy and design taxonomy have\nonly become clear to me over time. With that, let's jump in!<\/p>\n

Initial context: Fixpoint Loops and the Pass-Ordering Problem<\/h2>\n

Around May of 2022, I had introduced a simple alias analysis and\nrelated\noptimizations<\/a>\n(removing redundant loads, and doing store-to-load forwarding). It\nworked fine on all of the expected test cases, and we saw real speedup\non a few benchmarks (e.g. 5% on meshoptimizer<\/code>\nhere<\/a>)\nbut led to a new question as well: how should we integrate this pass\nwith our other optimization passes, which at the time included GVN\n(global value numbering), LICM (loop-invariant code motion), constant\npropagation and some algebraic rewrites?<\/p>\n

To see why this is an interesting question, consider how GVN, which\ncanonicalizes values, and redundant load elimination interact, on the\nfollowing IR snippet:<\/p>\n

v2 = load.i64 v0+8<\/span><\/span>\nv3 = iadd v2, v1   ;; e.g., array indexing<\/span><\/span>\nv4 = load.i8 v3<\/span><\/span>\n<\/span>\n;; ... (no stores or other side effects here) ...<\/span><\/span>\n<\/span>\nv10 = load.i64 v0+8<\/span><\/span>\nv11 = iadd v10, v1<\/span><\/span>\nv12 = load.i8 v11<\/span><\/span><\/code><\/pre>\n
Redundant load elimination (RLE) will be able to see that the load\ndefining v10<\/code> can be removed, and v10<\/code> can be made an alias of\nv2<\/code>, in a single pass. In a perfect world, we should then be able to\nsee that v11<\/code> becomes the same as v3<\/code> by means of GVN's\ncanonicalization, and subsequently, v12<\/code> becomes an alias of\nv4<\/code>. But those last two steps imply a tight cooperation between two\ndifferent optimization passes: we need to run one full pass of RLE\n(result: v10<\/code> rewritten), then one full pass of GVN (result: v11<\/code>\nrewritten), then one additional full pass of RLE (result: v12<\/code>\nrewritten). One can see that an arbitrarily long chain of such\nreasoning steps, bouncing through different passes, might require an\narbitrarily long sequence of pass invocations to fully simplify. Not\ngood!<\/p>\n
But this is clearly arbitrary, wastes compilation effort in the common\ncase, and we should be able to do better. In general, the solution\nshould reason about all passes' possible rewrites in a unified\nframework, and interleave them in a fine-grained way: so, for example,\nif we can apply RLE then GVN five times in a row just for one\nlocalized expression, we should be able to do that, without running\neach of these passes on the whole function body. In other words, we\nwant a \"single fixpoint loop\" that iterates until optimization is done\nat a fine granularity.<\/p>\n
Three Building Blocks: Rewrites, Code Motion, and Canonicalization<\/h2>\n
Let's review the optimizations we had at this point:<\/p>\n
This is known as the pass-ordering problem<\/em> in the study of compilers\nand is a classical heuristic question with no easy answers as long as\nthe passes remain separate, coarse-grained algorithms (i.e., not\ninterwoven). To permit some interesting cases to work in the initial\nCranelift integration of alias analysis-based rewrites, I made a\nsomewhat ad-hoc\nchoice<\/a>\nto invoke GVN once after the alias-analysis rewrite pass.<\/p>\n