[llvm-dev] InstCombine, graph rewriting, Equality saturation (original) (raw)

Hongbin Zheng via llvm-dev llvm-dev at lists.llvm.org
Mon Sep 25 09:36:30 PDT 2017

Hi,

On Tue, Sep 5, 2017 at 3:57 PM, (IIIT) Siddharth Bhat via llvm-dev < llvm-dev at lists.llvm.org> wrote:

Hello all,

I've seen some discussion that InstCombine is "too general" and that llvm should implement a proper graph rewrite mechanism: Link to llvm-dev discussion about this: http://lists.llvm.org/ pipermail/llvm-dev/2017-May/113219.html, Link to review where this came up (and I first heard about it): https://reviews.llvm.org/D37195. I wanted to understand what the current issues with InstCombine are, and if a graph rewriter prototype is something people are interested in. I find the idea appealing, from what little I know it, so I'd be interested in hacking something up. What would such a framework look like? Is there past literature on the subject? From what I know, many functional compilers using combinator based compilation were graph rewriting. Is there other prior art? Also, there is the idea of Equality Saturation ( http://www.cs.cornell.edu/~ross/publications/eqsat/) that I found out about recently. Could this be used to augment the InstCombine infrastructure? In addition of augmenting InstCombine, we may also use Equality Saturation to enhance/simplify the SCEV canonicalization process in the ScalarEvolution pass, as well as the peephole optimizations in LLVM backends. So we may need a generic engine.

Thanks, ~Siddharth -- Sending this from my phone, please excuse any typos!

LLVM Developers mailing list llvm-dev at lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170925/f55b665b/attachment.html>

More information about the llvm-dev mailing list