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

Daniel Neilson via llvm-dev llvm-dev at lists.llvm.org
Mon Sep 11 08:14:52 PDT 2017

Just thinking out loud…. I’m really not familiar with the vast majority of what instcombine does, so please excuse me if my naiveté is too obvious. I can’t help but notice all of the uses of ‘and’ in Daniel B’s description of what instcombine is right now:

> On Sep 8, 2017, at 11:27 PM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> FWIW, Before getting to "how to do it", I think InstCombine needs an actual goal.
> Right now it's "do a bunch of instruction combination and canonicalization and random kinds of semi-local optimization with some weird analysis and other stuff in the middle.
> Iterate this as hard as we can"
> Nobody can really draw any real dividing line for what should be there or not except based on how easy or expensive it is to shove it in.
> That's a recipe for pass creep.

This makes me wonder… is it sensible to be talking about splitting up instcombine into multiple separate passes? Would such a thing even be possible? For example, split by functionality into separate passes that each do one of:
* instruction combinations
* canonicalization
* semi-local optimizations
* etc…

 Or something like that.

 As separate passes, each would probably have a natural way to be implemented effectively and those implementations might vary.


Daniel Neilson, Ph.D.
Azul Systems

More information about the llvm-dev mailing list