[llvm-dev] InstCombine, graph rewriting, Equality saturation

[Hongbin Zheng via llvm-dev]

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>