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

[David Chisnall via llvm-dev]

On 11 Sep 2017, at 21:32, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> As a data point for this, I did a quick walkthrough of the top-level of instcombine, and one thing that stuck out to me is that it tries to sink instructions in certain "easy" scenarios. That doesn't fit a graph rewriting system.

The sinking in instcombine is not always a win.  We hit a case recently where instcombine made a hot loop in a benchmark significantly slower by moving an address-space cast instruction into a loop as part of its gep of addrspacecast to addrspacecast of gep transformation.  On our architecture, this translates to an extra instruction in a hot loop for the address-space cast *and* means that we then can’t use the complex addressing modes for the loads and stores because we have an address space cast in between the GEP and the memory op.  We end up increasing the number of instruction in the loop by around 20%, with a corresponding decrease in performance.

My somewhat long-winded point is that I’m not convinced that InstCombine is doing sufficient reasoning when it moves instructions between basic blocks to determine that the moves actually make sense.  In this benchmark, this one misoptimisation offset all of the other gains from InstCombine and simply disabling it gave us better code.

I don’t know how many other examples of this there are, but it would probably be good to have an InstCombine that ran on single basic blocks (or sequences with trivial flow control) and did folding that was always a win and something separate that’s more path-aware (and probably doesn’t run at O1).

David