[all-commits] [llvm/llvm-project] bb907b: [ValueTracking] don't recursively compute known bi...

[RotateRight via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: bb907b26e2bf2a0d5ea3fcb13ba0ccef3420a38c
      https://github.com/llvm/llvm-project/commit/bb907b26e2bf2a0d5ea3fcb13ba0ccef3420a38c
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2021-04-16 (Fri, 16 Apr 2021)

  Changed paths:
    M llvm/lib/Analysis/ValueTracking.cpp
    M llvm/test/Transforms/InstCombine/assume.ll

  Log Message:
  -----------
  [ValueTracking] don't recursively compute known bits using multiple llvm.assumes

This is an alternative to D99759 to avoid the compile-time explosion seen in:
https://llvm.org/PR49785

Another potential solution would make the exclusion logic stronger to avoid
blowing up, but note that we reduced the complexity of the exclusion mechanism
in D16204 because it was too costly.

So I'm questioning the need for recursion/exclusion entirely - what is the
optimization value vs. cost of recursively computing known bits based on
assumptions?
This was built into the implementation from the start with 60db058,
and we have kept adding code/cost to deal with that capability.

By clearing the query's AssumptionCache inside computeKnownBitsFromAssume(),
this patch retains all existing assume functionality except refining known
bits based on even more assumptions.

We have 1 regression test that shows a difference in optimization power.

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