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

[Davide Italiano via llvm-dev]

On Sep 12, 2017 1:34 AM, "David Chisnall via llvm-dev" <
llvm-dev at lists.llvm.org> wrote:

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.


My somewhat long-winded point is instead that IC shouldn't even bother
trying to sink. I understand it may eventually expose other optimizations
but it doesn't seem to be worth the complexity added. As you say, the
heuristic is pretty simple (fold instructions to blocks with a single
predecessor, IIRC, but don't quote me on that). There are cases where it
regresses, and I'm not surprised as sinking is not done after a proper
analysis (as, e.g. the one GVNSink or LICM are doing). You could probably
catch some cases teaching IC about profile metadata when taking sink
decisions, but that sounds like adding even more madness.

--
Davide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170912/877e80dc/attachment.html>