[all-commits] [llvm/llvm-project] 086190: [SCEV] Avoid compile time explosion in ScalarEvolu...

[Björn Pettersson via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 08619006a0c0694477f143dc1552eab35701e50b
      https://github.com/llvm/llvm-project/commit/08619006a0c0694477f143dc1552eab35701e50b
  Author: Bjorn Pettersson <bjorn.a.pettersson at ericsson.com>
  Date:   2021-10-19 (Tue, 19 Oct 2021)

  Changed paths:
    M llvm/lib/Analysis/ScalarEvolution.cpp
    A llvm/test/Analysis/ScalarEvolution/pr51869-scalar-evolution-prove-implications-via-truncation.ll

  Log Message:
  -----------
  [SCEV] Avoid compile time explosion in ScalarEvolution::isImpliedCond

As seen in PR51869 the ScalarEvolution::isImpliedCond function might
end up spending lots of time when doing the isKnownPredicate checks.

Calling isKnownPredicate for example result in isKnownViaInduction
being called, which might result in isLoopBackedgeGuardedByCond being
called, and then we might get one or more new calls to isImpliedCond.
Even if the scenario described here isn't an infinite loop, using
some random generated C programs as input indicates that those
isKnownPredicate checks quite often returns true. On the other hand,
the third condition that needs to be fulfilled in order to "prove
implications via truncation", i.e. the isImpliedCondBalancedTypes
check, is rarely fulfilled.
I also made some similar experiments to look at how often we would
get the same result when using isKnownViaNonRecursiveReasoning instead
of isKnownPredicate. So far I haven't seen a single case when codegen
is negatively impacted by using isKnownViaNonRecursiveReasoning. On
the other hand, it seems like we get rid of the compile time explosion
seen in PR51869 that way. Hence this patch.

Reviewed By: nikic

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