[all-commits] [llvm/llvm-project] 5a2265: Reapply [InstSimplify] Remove known bits constant ...

Nikita Popov via All-commits all-commits at lists.llvm.org
Fri May 8 01:25:14 PDT 2020


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 5a2265647ed3f449e9e8e970e27f5e964db851af
      https://github.com/llvm/llvm-project/commit/5a2265647ed3f449e9e8e970e27f5e964db851af
  Author: Nikita Popov <nikita.ppv at gmail.com>
  Date:   2020-05-08 (Fri, 08 May 2020)

  Changed paths:
    M llvm/lib/Analysis/InstructionSimplify.cpp
    M llvm/test/Analysis/ValueTracking/knownzero-shift.ll
    M llvm/test/Transforms/GVN/PRE/volatile.ll
    R llvm/test/Transforms/InstSimplify/assume.ll
    M llvm/test/Transforms/InstSimplify/call.ll
    M llvm/test/Transforms/InstSimplify/or.ll
    M llvm/test/Transforms/InstSimplify/shift-knownbits.ll

  Log Message:
  -----------
  Reapply [InstSimplify] Remove known bits constant folding

No changes relative to last time, but after a mitigation for
an AMDGPU regression landed.

---

If SimplifyInstruction() does not succeed in simplifying the
instruction, it will compute the known bits of the instruction
in the hope that all bits are known and the instruction can be
folded to a constant. I have removed a similar optimization
from InstCombine in D75801, and would like to drop this one as well.

On average, we spend ~1% of total compile-time performing this
known bits calculation. However, if we introduce some additional
statistics for known bits computations and how many of them succeed
in simplifying the instruction we get (on test-suite):

    instsimplify.NumKnownBits: 216
    instsimplify.NumKnownBitsComputed: 13828375
    valuetracking.NumKnownBitsComputed: 45860806

Out of ~14M known bits calculations (accounting for approximately
one third of all known bits calculations), only 0.0015% succeed in
producing a constant. Those cases where we do succeed to compute
all known bits will get folded by other passes like InstCombine
later. On test-suite, only lencod.test and GCC-C-execute-pr44858.test
show a hash difference after this change. On lencod we see an
improvement (a loop phi is optimized away), on the GCC torture
test a regression (a function return value is determined only
after IPSCCP, preventing propagation from a noinline function.)

There are various regressions in InstSimplify tests. However, all
of these cases are already handled by InstCombine, and corresponding
tests have already been added there.

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




More information about the All-commits mailing list