Yage Hu (Aug 31 2026 at 17:57): Yage Hu (Aug 31 2026 at 17:57):LLVM pivoted away from the original Alive to Alive2 for their peephole optimizations. My understanding is they chose the semantic richness that Alive2 can accept over the convenience of the original Alive DSL with C++ codegen.
I would love to hear some thoughts from the Cranelift developers about the limitations of ISLE, for example about what kind of optimization opportunities can be captured by ISLE. How do you view the tradeoff and how do you want ISLE + aegraph to evolve in the future?
Chris Fallin (Aug 31 2026 at 18:14):We have gotten a lot of traction with expressing rewrites in ISLE; both in its originally intended domain of value-equivalent rewrites (either for lowering, in the backend, or CLIF-to-CLIF in the mid-end), and also more recently in using it to express "actions"/"commands" to perform other kinds of transforms, e.g. folding branches.
I think it's important to note the "category" that ISLE fits into: it is a pattern-matching rule language, not an optimization strategy. We can use pattern-matching rules to do rewrites; we can use them to trigger other kinds of optimizations. So the question reads to me a little bit like "how is using match statements for optimizations": useful tool, used in many ways, also below the most relevant abstraction level in the design. Or said another way, we can use it in many ways with different environment bindings, so it doesn't really impose the limits one might initially assume if one just saw the expression-to-expression rewrites (for example).
I think the main ways we want to evolve are along the control-flow dimension: we've talked for years about how we want to make our mid-end framework more general wrt seeing through branches, seeing through blockparams, reasoning about effects, etc. We have some ideas here and they involve the framework and the encoding of the problem (e.g. explicit effects in IR), not the language (ISLE) in which we write the rules.
Last updated: Sep 20 2026 at 19:05 UTC