Hacker News new | ask | show | jobs
by LegNeato 61 days ago
Why do passes anymore when we have invented egraphs?
3 comments

Egraphs are for optimization passes, which operate on the same IR, and (without egraphs) may undo and/or prevent each other and are repeated for more optimization.

Nanopass is compiler passes, which each have their own IR, and run once in a fixed sequence.

Egraphs also require the IR to be defined a specific way, which prevents some optimizations. My understanding of https://github.com/bytecodealliance/rfcs/blob/main/accepted/... is that cranelift’s egraph optimizations are pure expression reordering/duplication/deduplication and rewrite rules.

There is no reason why compiler passes cannot be in an egraph, they are more general than optimizations. When you think about it, traditional compiler concerns like instructions selection are sort of a optimization problem if you squint.
Egraphs fundamentally require a first-order language, i.e. no lambda functions, because they do not handle scoping well. There are workarounds that work in some circumstances, but no general solution (that I'm aware of).

Additionally, egraphs express rewrites on a single language. Compilers are fundamentally translators between different languages; how do you write typechecking as an egraph rewrite rule? Or conversion to assembly?

But why? The goal of egraphs is to optimally order passes, but these passes have a single order.
It's the first I've heard of them. Looks like the research goes back to 1980, but good libraries seem fairly new?

https://blog.sigplan.org/2021/04/06/equality-saturation-with...

Recent related discussion/blog[1].

[1] The acyclic e-graph: Cranelift's mid-end optimizer https://news.ycombinator.com/item?id=47717192