[all-commits] [llvm/llvm-project] 2b52e4: [InstCombine] Remove known bits constant folding

[Nikita Popov via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 2b52e4e629e6793f832caef5e47f9d84607740f3
      https://github.com/llvm/llvm-project/commit/2b52e4e629e6793f832caef5e47f9d84607740f3
  Author: Nikita Popov <nikita.ppv at gmail.com>
  Date:   2020-03-20 (Fri, 20 Mar 2020)

  Changed paths:
    M llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
    M llvm/test/Transforms/InstCombine/assume.ll
    M llvm/test/Transforms/InstCombine/known-signbit-shift.ll
    M llvm/test/Transforms/InstCombine/out-of-bounds-indexes.ll
    M llvm/test/Transforms/InstCombine/phi-shifts.ll

  Log Message:
  -----------
  [InstCombine] Remove known bits constant folding

If ExpensiveCombines is enabled (which is the case with -O3 on the
legacy PM and always on the new PM), InstCombine tries to compute
the known bits of all instructions in the hope that all bits end up
being known, which is fairly expensive.

How effective is it? If we add some statistics on how often the
constant folding succeeds and how many KnownBits calculations are
performed and run test-suite we get:

    "instcombine.NumConstPropKnownBits": 642,
    "instcombine.NumConstPropKnownBitsComputed": 18744965,

In other words, we get one fold for every 30000 KnownBits calculations.
However, the truth is actually much worse: Currently, known bits are
computed before performing other folds, so there is a high chance
that cases that get folded by known bits would also have been
handled by other folds.

What happens if we compute known bits after all other folds
(hacky implementation: https://gist.github.com/nikic/751f25b3b9d9e0860db5dde934f70f46)?

    "instcombine.NumConstPropKnownBits": 0,
    "instcombine.NumConstPropKnownBitsComputed": 18105547,

So it turns out despite doing 18 million known bits calculations,
the known bits fold does not do anything useful on test-suite.
I was originally planning to move this into AggressiveInstCombine
so it only runs once in the pipeline, but seeing this, I think
we're better off removing it entirely.

As this is the only use of the "expensive combines" mechanism,
it may be removed afterwards, but I'll leave that to a separate patch.

Differential Revision: https://reviews.llvm.org/D75801